Ten discovery questions we ask before writing any code
The uncomfortable questions that save months of building the wrong thing.
Every project we take on starts with a discovery phase, and every discovery phase starts with the same ten questions. They’re uncomfortable on purpose. The projects that struggle to answer them are exactly the projects that would have burned six months building the wrong thing.
The questions
1. What business outcome, in numbers, makes this project a success a year from now? 2. Who uses this on a Tuesday afternoon, and what are they doing right now instead? 3. What happens if you build nothing? 4. Which single workflow, if improved, would users pay for or fight to keep? 5. Who inside your organization can kill this project, and what do they need to see?
6. What’s the smallest version that would genuinely change someone’s workday? 7. What existing systems must this coexist with - technically and politically? 8. What did the last attempt at this look like, and why did it stall? 9. Which assumptions, if wrong, are most expensive? 10. When this succeeds, what changes about your business model?
The goal of discovery isn’t requirements. It’s finding the assumption that kills the project - before it’s expensive.
Why this works
Notice that none of these questions mention features. Features are the output of discovery, not the input. When stakeholders answer these ten questions together, feature debates mostly resolve themselves - because everyone finally shares the same picture of what winning looks like.
We’d rather lose a week to hard questions than lose a quarter to confident guesses.