Software got cheaper to make. A prototype that would have taken a month in 2015 can take an afternoon now, and the difference is mostly tooling, not talent. What did not get cheaper is building the wrong thing: the engineering, the launch, the training, the migration, and the long quiet year afterwards in which everyone keeps using the spreadsheet anyway.
Product discovery is the part of the job that decides which thing is worth building. It is not a workshop, a slide deck, or a phase you can rename and skip. It is a short loop: talk to the people who will use the thing, build the cheapest version that can prove you wrong, put it in front of them, then make a decision you can still defend when someone asks why.
That loop is cheap. Skipping it is not.
What is product discovery?
Product discovery is the work of choosing what to build - and gathering enough evidence to be confident about that choice - before a team commits serious engineering time. It answers four questions: who has the problem, how they handle it today, what would have to change for them to switch, and what the smallest version worth shipping looks like.
Everything else is equipment: interviews, sketches, clickable prototypes, assumption maps. The output is not a document. It is a decision made early, while it is still cheap to be wrong.
Why is building the wrong thing more expensive than building it right?
If a good team builds the wrong thing well, you end up with a working product nobody needed, and you pay for it twice: once to build it, once to admit it. Engineers have a shorthand for this. Every decision gets more expensive the later you make it - an hour to change in a sketch, a week in development, a quarter in production once people have built their habits around it.
Cheap code changes the arithmetic in an uncomfortable way. When writing software costs less, you can produce more wrong things faster. The bottleneck moves from the keyboard to the judgement about what deserves to exist at all. That is a harder skill to hire for, and a much cheaper one to practise.
“There is nothing so useless as doing efficiently that which should not be done at all.”
Peter Drucker
Image edited with AI
What does discovery actually produce?
A good discovery loop leaves behind a short, boring artefact: one page that says what you are building, what you are deliberately not building, which assumptions have to hold, and what would make you stop. Boring is the point - a one-page decision survives contact with a steering committee.
- A written decision: build this, narrow it, or leave it alone.
- Evidence from behaviour: what people did with the prototype, not what they said about it.
- A prototype you can throw away: paper, a design file, or a code spike nobody is allowed to call the product.
- A non-goal list: the features you are not building, written down so they stop coming back.
- A price tag on being wrong: what it costs if the main assumption breaks, and who notices first.
If a round of discovery does not end in one of those, it was a meeting with better catering.
How does a four-week discovery loop work?
Four weeks is usually enough to reach a defensible decision, and short enough that nobody has time to turn discovery into a programme with its own steering group. The shape stays the same from project to project.
- Week one - talk to six to eight people. Not a survey: conversations with the people who do the work. Listen for the workaround, because that is where the money is. The spreadsheet, the group chat, the colleague who re-keys data every Friday - someone is already paying for the problem in hours.
- Week two - sketch three options and choose one. Three forces a real choice; two becomes a coin toss. Then build the cheapest prototype that shows the flow. No polish, no branding, no edge cases.
- Week three - put it in front of five or six users. Watch hands and hesitation. Compliments are not data; a pause before a click is.
- Week four - decide on one page. What we build, what we do not, what must be true, and what would stop us. Give the page a date and the decision an owner.
If four weeks genuinely is not available, run the same loop in four days: two conversations, one sketch, one test. Smaller, still honest, still better than a guess dressed up as a roadmap.
What does discovery look like on a real project?
On a national e-learning platform, the discovery question was not about screens. It was about order: do you build the loop where students practise, or the loop where teachers grade and give feedback? Both were necessary. Only one could go first.
The question looks small and it settles almost everything downstream - the data model, the notifications, the reports schools ask for, the way a lesson is put together. Get the order right and every release makes the next one lighter. Get it wrong and every release adds weight.
Today that e-learning platform serves more than 200,000 students across the Netherlands, and everything built since rests on that first ordering decision. You only get to make that call once, quietly, before the code exists. Building it is one discipline; growing it without losing quality is the next one.
When should you skip discovery?
Skip it when being wrong is cheap and reversible. A button, one sentence of copy, an internal tool used by four colleagues - ship it, watch what happens, change it next week. Discovery there would cost more than the mistake.
It earns its keep when the decision is hard to reverse: a new platform, a migration, a product line, anything that changes how other people do their jobs. The test is blunt. If undoing the wrong choice would take more than a month, spend a week deciding instead.
Build notes, not press releases
Nothing we write is meant to live on one page only. Each article here gets a second life: it becomes a Build Notes post - the shorter, blunter version with the actual trade-off still visible - or a Monday repost built around the one paragraph worth arguing about. Written once, used twice, read by the people it was written for.
Your week-four decision record deserves the same treatment. Cut it to a paragraph and put it back where the team will meet it again: the sprint board, the kickoff, the retro. A decision you can repeat from memory is a decision that holds.
At Lynx Solutions this is the part of twenty years of delivery that still shows up every week - not a longer feature list, but an earlier, calmer decision about what is worth building at all. Complexity made simple usually starts with a shorter list.