Discovery has a reputation problem. To engineers it sounds like delay; to founders it sounds like consultants billing for meetings. We understand both objections, because we have skipped discovery to please a client and paid for it with a rebuild. What follows is the short version we now run on every product engagement: the questions, why each one is there, and what happens when one goes unanswered.
Why a week, and why questions
Discovery for us is a fixed week, not an open-ended phase. The output is a one-page product brief that engineering can build from and the client can hold us to. We use questions rather than workshops because questions produce specific answers, and a specific answer that turns out wrong is far more useful than a vague answer that stays comfortable.
The users
Who uses this on a Tuesday afternoon? Not the persona, the actual person. What is their job title, what tools are open on their screen, what are they trying to finish? If the answer is "everyone," the product has no user yet.
Who pays, and is that the same person? For internal tools the buyer is a manager and the user is their team; for SaaS the buyer is often a different department. When they diverge, the product must satisfy both, and the roadmap must say which comes first.
Who is harmed if this works? Every automation and most products change someone's role. Finding that person in discovery turns an adoption blocker into a stakeholder.
The problem
What do they do today instead? The current workaround is the competition, and it is free. If the answer is a spreadsheet and the spreadsheet works, the product needs to be much better, not slightly better.
What does it cost when it goes wrong? This sets the bar for reliability and review. A product that drafts marketing copy and a product that drafts contract terms can use the same technology and need entirely different controls.
What have you already tried? Previous attempts tell us where the difficulty really is, and which vendors or tools are now unwelcome in the building.
The project that skipped these
A founder came to us with a clear vision for a marketplace platform and a deadline. We started building in week one. Two months in, the first real users, who were suppliers rather than buyers, told us the onboarding flow asked for information they did not have and the pricing model did not match how they sold. Both would have surfaced in an hour of discovery with two suppliers. We rebuilt onboarding, which cost more than the discovery week would have.
A conversation with a real user costs an afternoon. Learning the same thing from the product costs a release.
Success and priorities
What number will be different in six months? One number, one that someone already reports on. "Engagement" is not a number. "Quotes issued per week per person" is.
What would you cut first if you had half the budget? This question produces the real priority order faster than any ranking exercise, because it asks people to lose something.
What must be true at launch that is not true now? Data access, integrations, a decision from legal, a hire. These are the dependencies that quietly define the schedule.
Security and compliance questions belong here too
We ask them in discovery because the answers change the architecture. Which data is personal, regulated or contractual? Where must it stay geographically? Who needs audit trails, and for what? Will any content go to a third-party AI provider, and has anyone checked the terms? A product that learns these in discovery designs them in. A product that learns them in a security review two weeks before launch designs them around.
What the brief contains
One page: the user by name of role, the problem in their words, the current workaround, the cost of failure, the single success number, the first release scope with what was deliberately cut, the launch dependencies with owners, and the data and security constraints. Engineering starts from this page. When something changes later, we change the page first.
The questions, as a list
- Who uses this on a Tuesday afternoon, and who pays for it?
- What do they do today instead, and what does it cost when it goes wrong?
- What have you already tried?
- What one number will be different in six months?
- What would you cut first with half the budget?
- What must be true at launch that is not true now?
- Which data is sensitive, where must it live, and who audits it?
Seven questions, one week, one page. It is the cheapest engineering we do.