When you work as an engineer regardless of whether it is startup or a big company (in consulting services or products) you are always given guidance on what you should build. Even the most autonomous programmers when working independently has someone tell him what to do. However when you become the founder of a startup the most stressful thing you immediately encounter is ‘What should be built?’.
This decision is guided by what-if scenarios or even based on what is cool to build and show off to others. If you are somewhat disciplined then you document these thought somewhere before you start writing code. In software engineering language this is also referred to as requirements analysis document. Little thought is given to how does one know that this is indeed something needed by someone. To address this one of the best techniques known to engineers is applied – abstract it away. You decide to assume that whatever conjured up is indeed correct to help make further progress as sitting idle without any doing any coding is a waste of time.
When you were just an engineer working elsewhere the impact of such assumption is someone else’s problem but now the impact is on you. Also given that you have limited runway the stake for making mistakes about that question is very high.
You thus face two scenarios which as engineers you may have never faced.
- To make a decision in the face of unknown
- To own the decision you make
Product entrepreneurs realize this situation and resist the urge to make any assumption and proceed with a learning mindset. They make decision to the extent to which they can learn. Infact the really great entrepreneurs mentally sequence their unknowns (assumptions) in the order of most negative impact and move forward to uncover them.
These are in fact the two key skills that a startup product manager should become excellent at – owning the decisions & discovery (learning) before making decisions.
In the next post we will look at “How to debug a product startup idea?”
