Two of the products I've worked on started with almost nothing. Mark Andrews Creative came with one sentence: "a platform to sell my courses, books and products with an e-learning system like Coursera and Udemy." There was no documentation and no plan. Varsee started from an idea with no documentation either.
In my experience that's common for a startup. The work of turning a sentence into something a team can build is product discovery. This is the process I use, with what it produced on real projects.
What is product discovery, and when do you need it?
Product discovery is the work of finding out what to build before you build it: who it's for, what they need, how they'll pay, what the rules are, and how you'll know it worked.
You need it whenever the brief is shorter than the questions developers will ask. A one-sentence brief leaves almost everything to be decided, and anything nobody decides gets guessed during the build.
How do you turn a one‑sentence brief into goals?
Write a few goals down with the client, before any feature list. Goals are what every later decision gets checked against.
For Mark Andrews Creative, the sentence became three goals, set before building:
- Time to launch: live in about 12 weeks.
- One platform: every sale (subscriptions, courses and physical goods) on one platform.
- Revenue engine: recurring subscription revenue as the main engine.
Goals don't need to be formal metrics. On LeanDeck we didn't set formal metrics, but we built against three clear goals: a beta with real agencies in eight weeks, a first proposal in about ten minutes, and AI output usable as-is, needing only light edits before it's sent. The beta launched with 6 agencies, 8 weeks after kickoff.
On Mark Andrews Creative, the three goals made the big decisions easy to judge. Three ways to buy on one platform fit goal two. Subscription rules that keep members subscribed fit goal three. The platform went live in 12 weeks, and the business now makes over $1M a year on it.
How do you find out what users actually do?
Two ways, and I use both whenever I can.
Talk to them. On LeanDeck, an AI proposal tool, I ran the product research and user interviews. I interviewed design and dev agencies about how they win work. A proposal took them 6–10 hours, mostly written by hand from scratch. The interviews also showed the real job: a proposal is only the start, because once it's approved it becomes an agreement and then an invoice. That shaped the whole product.
Measure what they do today. On Find Your Calm, a booking platform for wellness operators, I added Microsoft Clarity and Mixpanel from the start, on the old system first. Clarity's heatmaps and session recordings showed where customers dropped out, and the biggest drop was in the booking flow. Research also showed the old system was only a booking tool: it had none of the features a wellness business runs on, such as memberships, packs, gift cards, add-ons and waitlists.
On KpiClock, before the first wireframes, I collected reference flows for onboarding, project detail and sidebar navigation, then mapped 12 user flows. Mapping the flows early is how you find the questions nobody has answered yet.
What should discovery produce?
These are the questions I make sure discovery answers, how I answer them, and what each one produces.
| Discovery question | Method | Output |
|---|---|---|
| What is the product for? | Write goals with the client | A few written goals (three, for Mark Andrews Creative) |
| Who uses it, and for what? | User interviews, a list of user types | One line per type of user and what they come to do |
| What do people do today? | Measure any current system; watch sessions | Where people drop out, and what's missing |
| What's the real job, end to end? | Follow the work past the first step | The whole flow (on LeanDeck: proposal, agreement, invoice) |
| What are the rules? | Write every rule in one shape | A rulebook developers can build from |
| What's riskiest? | Test that part first | Evidence before the build commits to it |
| How will we know it worked? | Agree metrics with the client | Success metrics and launch targets, agreed upfront |
Two rows come from lessons. On Mark Andrews Creative, I'd put the business rules into one written, signed-off rulebook in week one. On Varsee, I designed every phase so investors could see the whole product, and next time I'd test the AI layer first, on real recorded sales calls, because that's where Varsee succeeds or fails.
How do you know discovery is done?
When three things are true.
The rules are written down. If a developer could build each rule without asking what you meant, the rules are ready. That's what a PRD is for, and I've shared mine in How to write a PRD developers can build from.
Success is agreed before the build. On AidNetwork, a healthcare staffing platform, I set success metrics and launch targets with the client before launch, so results are tracked against targets agreed upfront. On Find Your Calm, the delivery metrics were set upfront too, but booking completion only became a tracked metric after launch; agreeing it and its measurement window earlier would have made the before-and-after comparison cleaner.
The riskiest part has been tested. On AidNetwork I tested the candidate journey with users before it was built. If the riskiest assumption is still a guess, discovery isn't finished.
Discovery doesn't have to stop when the build starts. On Find Your Calm, we met the client every week and researched each sprint's requirements before starting it, so nothing had to be rebuilt late. For the checks I run before a launch, see A launch-readiness checklist for SaaS products.
Frequently asked questions
What is product discovery?
Product discovery is the work of finding out what to build before the build starts. It turns an idea into goals, users, rules and a scope, using interviews, data from any current system and early prototypes.
How long should product discovery take?
Long enough to answer the questions that would otherwise be guessed during the build. It doesn't have to stop the build: on Find Your Calm, we researched each sprint's requirements before starting it, so discovery kept going alongside delivery.
What are the outputs of product discovery?
Written goals, a list of user types, how people buy and use the product, the business rules, the riskiest assumptions and how they'll be tested, and agreed success metrics. Together they're enough to write a PRD a team can build from.
Do you need user interviews for discovery?
When the product serves people you can talk to, yes. On LeanDeck I interviewed design and dev agencies about how they win work, which showed a proposal took them 6–10 hours, mostly written by hand from scratch.
