Build, Test and Refine What Wins

Build the product. Test it where it will sell. Refine what wins.

Insight and innovation tools for moving from concept to validated product. Prototype development, real-world testing and structured refinement, all run in the conditions the product will actually live in.

Where the idea becomes the product

Build, test and refine work is the bridge between a concept that won the room and a product that survives the market. The ideation work delivered a defended shortlist. The launch work will commercialise it. This is the work in between: turning the concept into a real product, putting that product in front of real consumers in the conditions they will actually buy and use it, and refining the work until it is ready to commit to manufacturing, listing or launch.

Most build and test briefs land when one of three pressures is on the team. A shortlist has been signed off and the development clock is ticking. A finished product needs to be benchmarked against the competition before a category review. A new menu, recipe or application has to land in the conditions of a real restaurant or kitchen, not in a sterile test environment. In every case, the question is the same: does this product actually work for the consumer who will eat it, where they will eat it?

What lands at the end of the work is a validated, refined product. Not a deck of preference scores. Not a topline that says “test passed.” A product that has been through the right testing in the right conditions, with the evidence behind why it works (or why the version we have refined now does) and a clear point of view on the next move.

Two toolkits. One loop. Build, test, refine, repeat.

Innovation tools sit inside our Innovation and Optimisation capability and are the building side of the work: R&D sprints that compress prototype development into weeks, menu development for QSR and high street operators, and application showcases that bring a product to life across multiple uses. Insight tools sit inside our Strategic Insight and Product Insight capabilities and are the validation side: in-home, central location and in-restaurant product testing, qualitative product testing, and menu testing in real foodservice conditions. The two run as a single iterative loop, not as separate phases.

Innovation tools

The building side. Used when the brief needs to move from concept to prototype, to develop a menu for a foodservice operator, or to showcase the product in the applications and contexts that will matter at launch.

Insight tools

The validation side. Used when the prototype, product or menu needs to be tested in the conditions it will actually be sold in, with the audiences who will actually buy it.

How we run build, test and refine work

  • We scope around the gate review

    Twenty minutes on a scoping call. You tell us where the product is in the development cycle and what the next gate review needs to look like. We tell you which combination of build and test tools will get you to a defendable position, and whether the work is best run as a single integrated programme or as sequenced phases tied to specific commercial milestones.

  • Build with operational reality in mind

    Prototype work that ignores the operation it has to live in produces ideas that win the development meeting and die at the production gate. R&D sprints, menu development and application work all run with operational reality built in: what the kitchen can deliver, what the factory can scale, what the retailer will list. The senior team has worked client-side inside retailers, manufacturers and operators, which means the gate questions are anticipated rather than discovered.

  • Test where it will sell, not where it is convenient

    Retail products tested in homes. Foodservice products tested in restaurants. Comparison work run in central locations where the head-to-head is the point. The format is chosen around the product and the decision behind it, not around what is easiest to run. Sensory and qualitative layers added where the quant alone will not get to the answer.

  • A validated product, not a test report

    We close with a refined product and the evidence behind why it works in the conditions it will be sold in. What the consumer said. What the operation revealed. What we recommend changing before launch (or why we do not recommend changing anything). Built for the team that will commercialise the product, not for the meeting that signed off the test.

If your brief sounds like one of these, you are in the right place

  • We have a shortlist of concepts signed off and the development clock is ticking.
  • We have a prototype and we need to know whether it works for the consumer who will actually buy it.
  • We need to benchmark a finished product against the competition before the next category review.
  • We are launching a new menu, a refreshed range or a seasonal proposition and we need to validate it in real foodservice conditions.
  • Our R&D team is at capacity and we need an expert-led sprint to compress development into weeks.
  • We need to bring a product to life in a tasting format for a buyer pitch or internal sign-off.

If your brief is closer to “we need ideas before we can prototype,” you are probably looking at Challenge 03 (Create and Refine Ideas) first. If it is closer to “the product is validated, now we need the route to market,” Challenge 05 (Launch and Scale Innovation Successfully) is the better fit.

Explore Create and Refine Ideas

Products that work in market, not just in the lab.

Most product testing earns a clean score and then watches the product underperform on shelf or on the menu. The number was true. The conditions were not. Sterile testing environments produce sterile results, and the products that scored well in those conditions struggle in the real ones because the test never asked them to.

Three things keep our build and test work honest. First, specialism. Food and drink is the only sector we serve, which means the team can read a product, a menu and a kitchen in ways a generalist agency cannot. Second, operational bias. Our senior team has worked client-side inside retailers, manufacturers and operators, so the work anticipates the gate questions a buyer or operator will ask rather than discovering them at the readout. Third, the testing environment. We run the test in the place the product will actually live: in the home for retail, in the restaurant for foodservice, in central locations only when controlled comparison is the explicit point of the brief.

We are not a research agency that runs a generic IHUT against a script. We are not an R&D house that develops a prototype without consumer pressure-testing. We are the team that runs the build and the test as one continuous loop, with senior food and drink specialists who have lived in the operational reality the work is being run for.

Meet the Team

Product validated. What comes next?

Build, test and refine closes with a validated product. Most clients move into one of three places from here, depending on what the testing has surfaced and where the brief sits in the broader programme.

Products tested where they live

Three projects across different channels and different testing formats.

FAQs

What is the difference between IHUT, CLT and in-restaurant testing?

IHUT (in-home usage testing) puts the product in the consumer’s own home, where they prepare it, eat it and live with it across multiple usage occasions. CLT (central location testing) brings consumers into a controlled environment where direct head-to-head comparison or repeat-exposure testing is the priority. In-restaurant testing places the product in a real or simulated foodservice environment, capturing the kitchen, the service moment and the eating context together. We choose the format around the product and the decision behind it, not as a default.

Do you test in real foodservice environments or only in test kitchens?

Both, depending on the brief. Real foodservice environments give the most authentic read on how the product performs in service, but are harder to control. Test kitchens give a cleaner read on the product itself, with controlled variables. Many menu and foodservice projects use both: kitchen-based development and refinement first, then a real-environment test before commitment.

What is the difference between menu testing and menu development?

Menu development is the building side: we design the menu, the dishes and the operational specification. It sits inside our Innovation and Optimisation capability. Menu testing is the validation side: we test a menu that exists (whether built by us or by your internal team) in real or controlled conditions to confirm what works and what needs refining before roll-out. The two often run together but they are distinct tools.

When do I need qualitative product testing on top of quant?

When the quant has surfaced a question the numbers cannot answer. Common moments: a product is over-delivering on one occasion and under-delivering on another, the preference score is strong but the verbatim is hesitant, or two products are scoring similarly but you need to know which one to take forward and why. Qualitative product testing reads the why behind the preference and gives the basis for refinement rather than just reporting.

Can you benchmark our product against competitors directly?

Yes. Central location testing is the most direct format for head-to-head benchmarking because it controls for variables (preparation, temperature, presentation, order of evaluation). In-home and in-restaurant formats can also include competitor benchmarking, with the trade-off being more authentic conditions versus more controlled comparison. We will recommend the right format on the scoping call.

How quickly can you turn around product testing?

A CLT can run in three to five weeks from brief to readout. A standard IHUT typically runs in five to eight weeks including recruitment, in-home placement and consumer feedback. In-restaurant testing depends on the operator and the live testing window, but typically runs four to eight weeks. R&D Sprints compress prototype development into a focused three to six week window. We will give you a realistic timeline at proposal stage.

Do I need to provide finished products or can you test prototypes?

Either. Prototype testing is common at early stages and is often paired with R&D Sprints, where the prototype is iterated based on the test result and tested again. Finished product testing is the right format for pre-launch validation, claims testing and competitive benchmarking. We will scope around the maturity of what is being tested rather than against a template.

How do you make sure the testing reflects real market conditions?

Three ways. The testing environment is chosen to match the product (in-home for retail, in-restaurant for foodservice, controlled location for comparison). The audience is recruited to match the actual consumer profile, not a generic panel. And the methodology is built around real usage occasions, not abstract scenarios. The senior team has worked client-side, which means we already know what gate review questions a retailer or operator will ask and we build the test to answer them.

Need to prove the product works before you commit?

Tell us where the product is in the development cycle and what the next gate review needs to look like. We will tell you which combination of build and test tools will get you to a defendable position, what the timeline looks like, what it will cost, and who will run it. Twenty minutes on a scoping call with a senior product specialist.