Joy Foroughi
Executive Assistant
App Market Research: How to Test Demand Before Building Your MVP
To test demand before building your MVP, follow five steps. Define the problem and the person who has it. Study what people use today. Interview those people about their past behavior. Then run a cheap experiment, such as a landing page, a manual service, or a pre-sale, that asks for a real commitment. Score the results and decide whether to build, revise, or stop. A focused round can take a few weeks and help you identify weak assumptions before committing to development.
To test demand before building your MVP, follow five steps. Define the problem and the person who has it. Study what people use today. Interview those people about their past behavior. Then run a cheap experiment, such as a landing page, a manual service, or a pre-sale, that asks for a real commitment. Score the results and decide whether to build, revise, or stop. A focused round can take a few weeks and help you identify weak assumptions before committing to development.
This guide walks through each step with the sample sizes, questions, and decision rules you need. It is written for founders and product managers who plan to hire a team and want to hand that team a validated brief instead of a hunch.
TL;DR
Demand is better assessed through behavior and meaningful commitments. Confirm that people recognize the problem, rank it as a priority, and have a budget to fix it.
Start with competitors and workarounds. A crowded market is often a good sign, and the gaps in existing products are where you position.
Start with 3–5 discovery interviews and continue as needed; 15–20 may be needed before few new insights emerge. Treat these as guidelines and focus questions on past behavior.
Test with a landing page, a manual (concierge) service, or a pre-sale before you write code.
Score every signal, then proceed, pivot, or stop. Carry the findings straight into your MVP feature list and user journey.
What "testing demand" actually means
Market research for an app is not a report about market size. It answers one narrow question: will a specific group of people change their behavior, and pay, to solve a specific problem with your product?
Harvard Innovation Labs frames this as three conditions to confirm before building: customers recognize the problem, they regard it as a priority, and they are actively looking for a solution with budget to invest. Interest alone fails the test. Many startups fail by building something people like but never rank high enough to act on.
That gives you a working definition. Demand exists when you can point to people who:
Describe the problem unprompted.
Already spend time or money on a workaround or an alternative.
Make a measurable commitment, such as attending a pilot session, using a manual service repeatedly, or paying a deposit. An email signup is an early interest signal, not equivalent to payment.
Everything below is a way to collect those three kinds of evidence in order, from cheapest to most convincing.
Step 1: Define the problem and the person
Write one paragraph before you talk to anyone: who has the problem, when it occurs, and what they do about it today. The Harvard Business School Rock Center guide says idea validation should begin with customer discovery: interviewing, surveying, and observing potential customers to confirm the problem and define the target customer.
A useful problem statement is narrow enough to find 20 real people who fit it. "Busy professionals" is not a segment. "Independent physical therapists who schedule patients by text message" is.
List your riskiest assumptions, too. Which of these, if wrong, kills the idea? Usually it is one of three: the problem is not painful, people already have a good-enough fix, or they will not pay. Every test below targets one of those assumptions.
Pro Tip: Put a skeptic on the team. Y Combinator's Peter Reinhardt has said that a skeptical co-founder helps a team avoid groupthink and design the fastest, most reasonable test for each hypothesis. If everyone in the room loves the idea, nobody is stress-testing it.
Step 2: Research the market and the alternatives
Desk research comes before interviews because it makes your interviews sharper. According to the Rock Center guide, it should establish how target customers solve the problem now, what frustrates them, which solutions exist and where they fall short, the competitive landscape, and the customer's decision process.
Stripe's startup guide adds the same logic from a practical angle: identify customer segments, needs, pain points, triggers, competitors, and the products customers currently favor before you position anything.
Look beyond direct competitors
Boston University's Innovate@BU guide tells founders to include direct competitors, indirect alternatives, and workarounds. For an app, workarounds are spreadsheets, group chats, paper forms, and a stack of three tools stitched together. Its guide also points out that the real opportunity often sits in the gaps among existing products and cumbersome workarounds, not in a market with zero competitors.
If you find no competitors or workarounds, investigate further. You may have missed an alternative, identified an emerging need, or found a problem people do not prioritize.
Mine reviews for demand signals
App store reviews of existing products are free interviews. The same BU guide notes that reviews can reveal missing features, reasons people delete an app, and recurring dissatisfaction. Read the one-star and three-star reviews of the top five apps in your category and tag each complaint: pricing, bugs, missing feature, confusing onboarding, privacy.
Also record the praise. Appfox advises that a gap is useful only when you understand the strengths users might give up by switching. If everyone loves a rival's simple checkout, a more feature-rich alternative may lose.
We cover a repeatable version of this exercise in our guides on mobile app competitor analysis and running it in under a week.
Check search and trend data
Search behavior shows whether people go looking for a fix. Ahrefs recommends using search demand and trend data to see whether people actively seek solutions and whether interest is growing, seasonal, or declining. Query volume for the problem ("how to split rent with roommates") is more telling than volume for your product category. Search data is one supporting signal. Low search volume alone does not rule out demand, especially for specialized B2B products or unfamiliar solutions.
Step 3: Interview people about the past, not your idea
Interviews tell you why; surveys tell you how many. Tom Eisenmann’s Harvard Business School material, Early Customer Research, hosted on Stanford’s website, advises using interviews to explore why and surveys to assess how many or how often, and it says to ask about past or present behavior, current solutions, costs, and prior spending.
The same material warns against leading questions and against hypothetical purchase-intent answers, which are especially unreliable for radically new products. People are polite. "Yes, I'd definitely use that" costs them nothing.
Questions that work
Anchor each question in the last time the problem happened:
"Tell me about the last time you [had this problem]. What happened?"
"What did you use to deal with it? What did that cost you in time or money?"
"What have you already tried and dropped? Why?"
"Have you ever paid for something to solve this? What and how much?"
"Who else was involved in that decision?"
Questions that fail
"Would you use an app that does X?"
"How much would you pay for this?"
"Do you think this is a good idea?"
Eisenmann’s material centers on what people did during the last relevant incident, which tools they used, and what it cost. Rob Fitzpatrick's book The Mom Test argues the same: stop pitching and ask about specific past behavior.
How many interviews
Tom Eisenmann’s Early Customer Research material summarizes guidance to start with 3–5 discovery interviews and continue as needed. If findings remain scattered after 10 or more interviews, revisit your segment and research questions. Reaching a point where few new insights emerge may take 15–20 interviews; these are guidelines, not fixed requirements. Watch for small samples, convenience sampling (only friends), and self-selection (only people who reply enthusiastically).
Follow with a short survey
Once interviews show a pattern, a survey can size it. Typeform's validation guide says surveys quantify how widespread a problem is, while interviews provide the deeper explanation, and both should ask about current behavior and pain points because stated future intent is easier to give than actual use. Keep it under ten questions and include one open-ended "what is the hardest part?" item.
Step 4: Run an experiment that asks for commitment
After research, test behavior. CRV's MVP guide separates two ideas worth keeping apart: a prototype demonstrates what can be built, while an MVP is an experiment that measures real user responses to decide whether to build. Your demand test is the cheapest version of that experiment.
Landing page with a signup or waitlist
Build a one-page site that states the problem, the promise, and a single call to action. CRV lists a landing page or video with a signup form or waitlist as a way to measure interest before an app exists. HubSpot adds variations: email signups, explainer content, fake-door calls to action, and prototypes, then tracking engagement, acquisition cost, retention, and whether customer spending could cover development costs.
A fake-door test is a button such as "Start free trial" that leads to a "coming soon" screen. The click is the data point. Be honest on the follow-up page and tell people the product is not ready yet.
Send paid or organic traffic from the channels you would really use after launch. A signup rate from your friends tells you about your friends.
Concierge and Wizard-of-Oz tests
Deliver the service by hand. In a concierge MVP, you do the work manually for a few customers, so you learn whether the outcome matters before you automate it. Harvard Innovation Labs recommends the concierge approach, and Appy Pie describes the Wizard-of-Oz variant, where the user sees an interface but a person does the work behind it, as a way to test whether customers truly want the outcome before investing in technology.
Example: before building a scheduling app for independent physical therapists, manually coordinate appointments for a small group over four weeks. Track repeat use, time saved, and willingness to pay for continued help.
Pre-sales and deposits
The strongest signal is money. Asking for a paid pilot, a deposit, or an annual pre-order turns a polite "maybe" into a yes or no. Treat a payment as stronger evidence than a signup or a like. For B2B apps, a letter of intent can document interest, but a paid pilot provides stronger evidence of willingness to pay. Record the buyer, agreed price, scope, and expected start date.
For deposits and pre-orders, clearly explain what is available now, expected delivery timing, and refund terms.
Clickable prototype
A design prototype tests whether people understand the flow, not whether they want it. Use it after the problem is confirmed. Our UX/UI design work usually starts here: five to eight users tapping through screens tells you where the journey breaks long before an engineer writes code.
Step 5: Read the results with a scorecard
Gather every signal in one table. Record your target, actual result, and whether it meets the threshold you set before testing. A simple version:
Signal | What you measured | Strong looks like |
|---|---|---|
Problem recognition | Interviewees who describe the problem unprompted | Most of them, with specific recent stories |
Priority | Is it in their top few problems? | They already spend time or money on it |
Existing spend | Money or effort on alternatives and workarounds | Paid tools, hired help, manual routines |
Search and forum evidence | Query trends, complaints in communities | Steady or growing interest, explicit complaints |
Landing page conversion | Signups from targeted traffic | Above your own baseline target, set in advance |
Commitment | Deposits, pre-orders, paid pilots | Payments from target customers at the intended pilot price, measured against your predefined target |
Set your pass thresholds before you see the data. Otherwise, you will rationalize whatever comes in.
Appy Pie's framework gives the decision logic: proceed with strong signals, pivot with mixed signals, and stop when demand or willingness to pay is weak. Add a fourth rule from Harvard Innovation Labs: test problem priority and budget, not mere expressed interest, because building a low-priority solution is a common way startups fail.
How to read the outcomes:
Strong across the board: define a limited MVP scope and test acquisition costs, delivery costs, and repeat use before expanding investment.
Strong problem, weak response to your solution: change the solution, the segment, or the price, then retest.
Weak problem signals: stop or switch to a different problem you uncovered during interviews. This is a cheap result, not a failure.
We lay out a 30-day version of this decision in Founders: Validate Your App Idea and Decide in 30 Days, and a broader checklist in How to Validate Your Mobile App Idea Before Writing a Single Line of Code.
Turn research into MVP features and a user journey
Research earns its keep when it shapes the first release. Here is a way to translate findings into scope:
Pick one job. From your interviews, choose the single problem that came up most often and cost people the most. The MVP does that job end to end.
Map the current journey. Sketch the steps people take today with their workaround: the trigger, the tools, the handoffs, the point where they get frustrated. Your app's journey should remove steps from that path, not add them.
Cut by evidence. Every feature needs a quote, a review, or a test result behind it. Features backed by nobody go on the "later" list.
Keep what people praise. If users love a rival's speed or simplicity, match that baseline before adding anything new.
Define success up front. Choose the behavior that proves the MVP works, such as completing the core task twice in the first week, and instrument it from day one.
The output is a short roadmap, not a wish list. Our guide to mobile app product roadmap essentials shows how to sequence it, and the walkthrough on launching a first mobile app in 90 days covers what happens after the go decision.
Mistakes that distort demand tests
Asking friends and family. They want you to succeed, so their answers lean positive.
Counting signups as demand. Free is easy to say yes to. Weigh deposits and repeat use more.
Testing too many ideas at once. You cannot read the result if three variables moved together.
Ignoring price. An app people love at zero may not survive at $9.99 a month. Test a price in your landing page or pilot.
Waiting for certainty. The goal is enough evidence to make a sound bet, not a guarantee.
Our perspective
Most founders who come to us have already decided to build. The ones who ship well did something before that: they could name ten people with the problem and tell us what those people do today.
That is why we start projects with market research, competitive analysis, and MVP definition, and why our senior designers and developers sit in those conversations themselves instead of receiving a summary from someone junior. When the person who will design the flow hears the interview findings directly, features get cut for the right reasons and the scope fits the evidence.
We have launched over 75 apps across industries, and the pattern we see is consistent: the teams that treat validation as part of the build, not a hurdle before it, spend less time reworking screens after launch. Direct access to senior people also shortens decision latency. A question about whether a feature is needed gets answered in a day, not after a ticket moves through three layers.
Test demand hard, then build only what the evidence supports.
Bring a validated idea to a senior team
If your research says go, the next risk is execution: a vague scope, a handoff to junior staff, or a team that disappears after launch. At TouchZen, senior developers and designers work with you directly from kickoff to launch, and we stay on for support and growth afterward.
We can help you define the MVP from your findings through MVP development for startups, shape the strategy with product strategy and consulting, or take the whole build through our complete design and development service. Budgeting first? See three MVP budget tiers and the cost levers.
FAQ
How long does it take to test demand for an app?
A focused round often takes three to six weeks: about a week of desk research, two weeks of interviews, and one to two weeks of landing page or concierge testing. Your timeline depends on how fast you can reach your target users. Set a stop date at the start so testing does not drift.
How many people do I need to interview?
Tom Eisenmann’s Early Customer Research material summarizes guidance to start with 3–5 discovery interviews and continue as needed. If findings remain scattered after 10 or more interviews, revisit your segment and research questions. Reaching a point where few new insights emerge may take 15–20 interviews; these are guidelines, not fixed requirements.
Is a landing page enough to prove demand?
It is a useful first signal, not proof. Signups show interest, while deposits, pre-orders, and repeat use of a manual service show commitment. Combine the page with interviews so you understand why people signed up.
What if my app has a lot of competitors?
Competition usually means the problem is real and people spend money on it. Study what users praise and what they complain about, then look for a gap among direct competitors, indirect alternatives, and workarounds you can serve better.
Should I build a prototype before testing demand?
Not first. Confirm the problem and willingness to pay with interviews and a simple experiment. Use a clickable prototype afterward to test whether people understand your solution.
Sources
Stage 2.0: Idea Validation, Rock Center Startup Guide, Harvard Business School
Early Customer Research, Tom Eisenmann, Harvard Business School (hosted by Stanford)
Market validation: how to test demand before you build, Typeform
MVP Methodology: A Complete Guide to Building and Testing, CRV
Startup Idea Validation: A Step-by-Step Guide Before Launch, HubSpot
Peter Reinhardt on Finding Product Market Fit at Segment, Y Combinator
