Sevginur Ak Parlak
Mar 18, 2024
12 min read
Product discovery for startups: decide what to build in 1 to 2 weeks
Most founders who write to us do not have a product. They have an idea for an app or a website, a deck, and 3 versions of the same feature list, each 30 to 40 items long. When I ask which 1 thing the product must do on day 1, the answer takes 20 minutes.
Product discovery for startups is the work that happens before anyone opens Figma for real screens. It turns an idea into a problem statement, 1 user role, 1 core job, a scope cut, a user flow, and a clickable low fidelity prototype. The output is a build recommendation a founder can hand to a designer or a developer and say: this, not the rest.
In this post I explain what our discovery sprint is, what comes out of it, how we run it in 1 to 2 weeks day by day, how we decide what not to build, and when the answer is to not build at all.
What a product discovery sprint is
A discovery sprint is a fixed time box, 5 or 10 working days, where we answer 1 question: what should this product do first, for whom, on which platform, and is it worth building. We call it idea direction.
The founder brings the idea and access to 3 to 5 people who have the problem. We bring the process, the wireframes, and the discipline to cut. Nothing in the output is polished. It is the cheapest version of being wrong.
The product design discovery phase gets skipped because it looks like delay. In our experience a 1 week discovery removes 2 to 4 weeks of design and build on features that would have been cut later anyway. Discovery is step 1 of the product design process for an early stage startup I described before.
What comes out of a product discovery for startups
The problem statement is 3 to 5 sentences. Who has the problem, when, what they do today, and why that is not good enough.
User roles are the people who touch the product in the first 3 months. Most ideas arrive with 4 or 5 roles. We keep 1. Every extra role doubles the states and empty states you need to design.
The core job is the 1 task the primary role does repeatedly. For a consumer habit app it is "log today and see the streak". For a web product for freelancers it is "send an invoice and see when it is paid". For a tutor booking website it is "find a tutor and book the first lesson". Everything that does not serve that job goes to the scope cut.
The scope cut is a list in 3 columns: build now, build after the first 20 users, do not build. It is the most read page of the document.
The user flow of the core loop is 1 diagram: entry, the 5 to 9 steps of the core job, the moment of value, and the reason to come back. It includes the empty state and the first error state, because that is where activation is won or lost.
The clickable low fidelity prototype covers the core loop only, 6 to 12 greyscale screens in Figma. It is good enough to put in front of 5 people and watch where they hesitate, and not good enough to show investors.
The build recommendation is 1 page. Build now, build a smaller version, or do not build. With the reasons, the risks we did not remove, and the scope of the MVP design that follows.
The recommendation also names the platform: native mobile app, web app, or a website with the product inside it. Founders often arrive with a native app in mind because that is what they use every day. We recommend web first in most cases, because a web app reaches every device from 1 codebase, needs no app store review, and can change every week while the core loop is still moving. Native first makes sense only when the core job needs the camera, location, offline use, or a 10 second action done 5 times a day.
How we run a 1 week discovery, day by day
Day 1 is intake. A 90 minute call with the founder, then I read the deck, the notes, and any spreadsheet or chat group the founder uses to do the job by hand today. That is usually the real product. In the evening I send a first draft of the problem statement in Loom.
Day 2 is roles and jobs. We list every person who could touch the product and cut until 1 role remains. We write the core job in 1 sentence and I draw the first user flow on paper.
Day 3 is the scope cut. I place each of the 30 to 40 features in build now, build later, or do not build. The founder has 1 night to argue. Most items move once, then stay.
Day 4 is the prototype. I wireframe the core loop in greyscale, 6 to 12 screens, in a phone frame or a browser frame depending on the platform, and connect them in Figma. I design the empty state first, because that is what a new user sees. Then the happy path, then 1 error state. Copy is real, not placeholder text, because the words are half of the flow.
Day 5 is the recommendation. We walk through the prototype together and I write the build recommendation, platform included, with the risks we could not remove in 5 days.
How the 2 week version adds 5 user interviews
The 2 week version keeps the same structure and adds 5 user interviews, 30 to 45 minutes each, with the prototype in hand. The founder recruits the 5 people during week 1. If the founder cannot find 5 people with the problem in 3 days, that is already a finding.
Days 6 to 8 are the interviews. The first 15 minutes cover the current workaround. The last 20 minutes are a usability test: here is the task, show me how you would do it. I watch for hesitation, wrong taps, and the moment they say "oh, so it does this".
Day 9 is revision. Usually 2 of the 12 screens change completely. Day 10 is the recommendation, now with quotes and a count: 4 of 5 completed the task, 2 of 5 would pay.
Both versions are run by 1 senior designer, so the founder talks to the same person from day 1 to day 10.
How to decide what not to build
Each feature gets 3 questions:
Can the core job be completed without it?
Does the founder do it by hand today?
Would the first 20 users notice if it was missing?
If the answer to the first question is yes, the feature is not build now. That alone removes 60 to 70 percent of the list. Settings, profiles, notifications, integrations, and reporting almost always fall here. They feel essential because every app has them. The first 20 users will not care.
The second question catches features that exist to impress. If nobody does it by hand today, we do not know if it is wanted. It goes to build later.
The third question is about activation. A feature the first 20 users would notice missing is part of the core loop. Search in a habit app with 3 habits is not needed. Search on a booking website with 400 tutors is the core loop.
A first pass you can do yourself in 1 evening
It takes 2 hours and works for an app, a web product, or a website.
Write the problem in 5 sentences. Who, when, what they do today, why that fails, what changes if it works.
Write the core job as 1 sentence starting with a verb.
List every feature you have imagined, 30 or more. Sort into build now, build later, do not build. Build now should hold 5 to 8 items.
Draw the core loop on paper in 5 to 9 boxes, from entry to the moment of value. Box 1 is the empty state.
Find 5 people who have the problem and ask for 30 minutes. Count how many say yes.
If step 5 returns 0 or 1, fix that before you spend money on design.
When to stop and not build at all
In roughly 1 of 5 discoveries the recommendation is: do not build this, or not now.
The signals are consistent:
The founder cannot find 5 people with the problem.
The current workaround is a chat group and the people using it are fine with it.
The core job takes 9 steps and cannot be shortened.
Or the person who feels the problem is not the person who pays.
When we see this we say it in writing, with the evidence, and offer 2 options: a smaller version, often a landing page or a manual service that tests demand for 4 weeks without code, or a different core job that came up in the interviews. Saying stop means we lose the MVP project. We say it anyway, because a founder who builds the wrong product does not come back.
Where AI tools help in discovery and where they do not
AI tools help with volume. Turning 5 hours of interview recordings into transcripts and a first pass of themes takes 20 minutes instead of a day. Summarising 40 competitor apps into a table is fast.
They do not help with the decision. An AI tool will not notice that 4 of 5 people paused at the same button, because a pause does not appear in a transcript. And it will produce a plausible scope cut for a product that should not exist. The cut, the stop, and the platform call are judgement.
FAQ
What is product discovery for startups?
It is a fixed time process, usually 1 to 2 weeks, that turns an idea for an app, a web product, or a website into a problem statement, 1 user role, a core job, a scope cut, a user flow, and a low fidelity prototype. The output is a build recommendation, including which platform to build first.
How do I validate a product idea before building?
Write the problem in 5 sentences, define 1 core job, wireframe only that job in greyscale, and put it in front of 5 strangers who have the problem. If 4 of 5 complete the task and 2 say they would pay, build the small version. If you cannot find 5 people, do not build yet.
How long does a product design discovery phase take?
For an early stage startup, 5 to 10 working days. The 2 week version adds 5 user interviews and a usability test on the prototype. Anything past 10 days usually means the idea needs to change, not the research.
What is the difference between a 1 week and a 2 week discovery?
The 1 week version relies on the founder's knowledge and our process, and ends with a prototype and a recommendation based on judgement. The 2 week version adds 5 user interviews with a usability test on the prototype, so the recommendation carries evidence. If you have never watched a stranger use your idea, take the 2 week version.
What is the difference between discovery and MVP design?
Discovery decides what to build and produces a greyscale prototype of the core loop, 6 to 12 screens. MVP design produces 15 to 25 dev ready Figma screens with states and handoff in 3 to 6 weeks. Discovery often cuts the MVP scope by half.
Working with us
We run product discovery for startups as a 1 week or 2 week sprint. In 1 week you get the problem statement, 1 user role, the core job, the scope cut, the user flow, a clickable low fidelity prototype, and a build recommendation. In 2 weeks we add 5 user interviews and revise the prototype with what we saw. We do this for mobile apps, web products, and websites with a product inside, and we wrote separate posts on how to validate a mobile app idea and on marketplace product design. We work in Figma, Slack, and Loom, async across timezones, with founders in America, England, Ireland, and China. If the recommendation is build, MVP design can start the following Monday.
We also say when you do not need us. If you have talked to 10 people with the problem, can name the core job in 1 sentence, and your build now list has 8 items or fewer, skip discovery and go to MVP design. If your product already exists and the question is why activation is low, you need a UX audit, not discovery.
If you have an idea and 3 versions of the feature list, send us the longest 1. Book a free 15 minute intro call
