Research methods
Market research for a new product: what to test, in what order
How an existing business should research a new product: reframe the idea as a problem, use internal data, interview buyers, test the concept and commitment, then size it.
Market research for a new product should answer four questions, in this order: does a specific group of people have the problem the product solves, does your idea make sense to them, will they act when asked to pay or commit, and are there enough of them. Most wasted effort comes from answering the last question first, with a large market-size figure, before checking the first three. The same order applies whether you call it new product research, product market research or concept validation.
This page is for a business that already has customers and is considering a new product. If you are starting a company with no customers yet, market research to start a business covers that situation. Existing businesses have an advantage: customers you can talk to, sales and support records, and a team that hears objections every week.
A worked example: an ordering add-on for restaurants
Suppose your company sells point-of-sale software to independent restaurants. Several customers have asked whether you could help with ordering supplies, and the team is excited about an inventory and ordering add-on. This example is hypothetical and used throughout the page.
The request is a good lead. It is also a solution the team has already pictured, which makes it easy to research the wrong thing: whether customers like the idea, rather than how ordering works today and what it costs them.
Turn the product idea back into a problem
The UK government's guidance on the discovery phase makes this step explicit. When a team is handed a predefined solution, it should reframe it as a problem to be solved, and consider how much the problem currently costs. Its example: "we need to build an interactive map" becomes "how can we make it easier for people to find their nearest contact centre?"
For the restaurant example, "build inventory ordering" becomes: "How do restaurant managers decide what to order each week, who does it, and what does getting it wrong cost them in waste, stockouts and time?" That question can be answered with evidence. It also leaves room for an answer that is not your add-on.
The same guidance says it is not a failure to stop at the end of discovery if research shows that is the best choice. Decide before you start what finding would make you stop.
Start with what your company already knows
Before recruiting anyone, collect what you have:
- Requests and support tickets. Who asked for ordering help, and what were they trying to do when they asked? How to test a feature request covers how to read these without taking the requested feature literally.
- Sales notes and lost deals. Did any prospect choose a competitor because it handled ordering?
- Usage data. Do customers already export sales data to a spreadsheet at the end of the week? That can point to a workaround.
Remember that existing customers are a biased sample. They chose your current product, and people with the problem who never became customers are missing from these records.
Interview buyers and users, including non-customers
Talk to people who do the ordering and people who would approve paying for a tool. In a small restaurant these may be the same person; in a group of restaurants they often are not. How to interview B2B buyers, users and champions covers the difference.
Ask about the last order, not about your idea:
Walk me through last week's produce order. Who decided the quantities, what did they look at, and what went wrong?
Include a few restaurants that do not use your software, and at least one person from the supply side, such as a restaurant procurement lead, who can tell you how suppliers take orders and what they expect. Keep problem conversations separate from any conversation where you show the concept; problem interviews vs. solution interviews explains why mixing them muddies both.
Test whether the concept makes sense
Once you understand the problem, show people a short description or rough prototype. Nielsen Norman Group describes concept testing as sharing an approximation of a product that captures its core value, to see whether it meets the target audience's needs. The same article separates what people say from what they do, and notes the two are often quite different.
So in a concept test, look for understanding and fit rather than enthusiasm. Can the manager explain back what the add-on does? Where would it fit in their week? What would they stop doing if they used it? Polite interest is common and tells you little.
Test whether people will act
Stated interest is weak evidence of demand. Ask for something closer to a commitment:
- Offer a paid pilot to a few customers at a real price.
- Have your sales team mention the add-on in renewal conversations and record who asks for a quote.
- Put a clearly labelled "coming soon, join the pilot" option in your product and count sign-ups from the people who fit.
How to research willingness to pay covers how to set up these tests and read the results.
Size the opportunity last
Once you have evidence of a real problem and of people willing to act, estimate size from the bottom up. For an existing business, start with your own customers: how many fit the profile, what share of those in the pilot converted, and what they would pay. Then, if you plan to sell beyond your base, use public business counts to estimate how many similar restaurants exist in the markets you serve.
Write each step of the estimate next to its evidence, and label guesses as guesses.
Record the decision
End with a short memo: the problem you found, how common it seems, what the concept and commitment tests showed, and the decision. Turning customer interviews into a testable product decision has a format.
If you need to hear from people outside your customer base, such as restaurants on a competitor's software or suppliers, Instant Expert can find people who match a description you write. You review them, it sends your invitations and you pay only for calls that get booked. The directory pages for restaurant procurement professionals and restaurant finance professionals are one place to start for this example.
The working model
Research a new product in this order
- 1
Reframe as a problem
Turn the product idea into a question about what people do today and what it costs them.
- 2
Use internal evidence
Review requests, support tickets, lost deals and usage data you already have.
- 3
Interview the right people
Talk to users, approvers, non-customers and the supply side about recent events.
- 4
Test the concept
Check that people understand the idea and can say where it fits in their work.
- 5
Ask for commitment
Offer a paid pilot or quote and record who acts, then estimate size from the bottom up.