You might hear advice that sounds contradictory:
- Build software earlier: Don’t spend a long time specifying and designing, because working software1 will give you much better feedback.
- Build software later: Prototype and test your assumptions first so that you don’t waste time and money building software that nobody wants.
Which is right?
The sentiments behind both are true:
- If you spend too much time planning or designing and not testing anything real, you are delaying valuable learning.
- But if you spend weeks or months building software, then you might be taking the slowest and most expensive route to get critical feedback.
A better way of looking at it, is that you should get real as soon as possible. Real doesn’t necessarily mean production-grade software. It means real feedback from real potential customers.
How to get real
There are lots of ways to get real feedback:
- a conversation - ask people when they last had this problem and how they solved it. If you can’t find any examples, it’s not a real problem
- a sales meeting or marketing page - ask people to pre-order something. If they won’t, then the solution you have in mind isn’t appealing
- a prototype (e.g. paper or spreadsheet) - ask people to test your solution to see if they understand it
- concierge service - see if you can solve someone’s problem by hand without automating it, to learn what it takes to satisfy them
- throwaway software - real software but not with production quality, to help you assess feasibility or test an algorithm
- working software - put a feature in a real product and see whether, and how, people use it
Whatever you’re working on, figure out the riskiest assumptions. Then figure out how you can test those assumptions, with a real-enough result. Sometimes the best way really is with software. In which case, build just enough. But often, you can learn what you need another way. See Pretotyping by Alberto Savoia for how to validate ideas quickly and accurately.
As your confidence increases, you can invest more in building and get more detailed and reliable feedback in return. Check out Giff Constable’s article on The Truth Curve and The Build Curve for more on this topic.
So the answer is both: don't spend too long in thoughtland before building something to test. But that thing that you build might not need to be software.
The agile manifesto principles say that “Working software is the primary measure of progress”, which is reasonable when you're in pure delivery mode, but it's not great for discovery where we're not even sure about the nature of the problem yet. And even in delivery, working software is not enough: 'validated learning' or 'solved user problems' would be better. ↩