Product Discovery Before You Write Code

A useful problem statement names the user, the painful moment, and the cost of doing nothing, without jumping to features.

Replace 'we need an app' with 'front-desk staff spend forty minutes daily reconciling bookings from three channels.'

Discovery outputs should be testable: you should know what evidence would prove you wrong before sprint one.

Five to ten structured interviews beat a hundred survey responses when you are still learning vocabulary and workflows.

Shadow users for an hour if you can; gaps between what people say and what they do are where great products hide.

Prototype in Figma or even paper before committing to production code for flows you have never watched in the wild.

Pick one measurable outcome for the first release: completed bookings, submitted claims, or activated team accounts, not 'launch.'

Scope user stories by risk: validate the riskiest assumption first, even if that story is uglier than a polished settings page.

Discovery ends with a prioritized backlog and explicit 'not now' list so sales and investors do not reopen cut scope every week.

We combine short workshops with founders, review of existing tools, and technical spikes only where feasibility is uncertain.

Deliverables are concise: journey sketch, milestone plan, and acceptance criteria engineers can implement without guesswork.

Discovery is not endless consulting, it should converge on a buildable slice within days, not months.