#010: Product Risk And Feasibility
Points to think through deeply prior to building a product.
Building a product is extremely hard and even if you get a lot of things right you might fail.
That’s why it is indispensable to estimate certain risks upfront as part of the process of product discovery.
Those risks are not to be confused with what is commonly referred to as risk management which is a different topic that we are going to discuss in the next post.
At this point, it is important to understand the difference between estimating and minimizing a risk.
For instance, you minimize your risk of losing your money when buying a lottery ticket if only 1,000,000 people participate compared to a lottery with 2,000,000 participants.
However, only based on this observation you cannot make an informed decision about whether it is worth taking the risk or not because you have not properly estimated the risk yet.
As Marty Cagan - the person who institutionalized the term “product management“ - says, there exist the four big risks when building a product which should all be assessed during product discovery:
value risk (whether customers will buy it or users will choose to use it)
usability risk (whether users can figure out how to use it)
feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
business viability risk (whether this solution also works for the various aspects of our business)
The Product Manager is responsible for the value and viability risks, and overall accountable for the product’s outcomes.
The Product Designer is responsible for the usability risk, and overall accountable for the product’s experience – every interaction our users and customers have with our product.
The Product Lead Engineer is responsible for the feasibility risk, and overall accountable for the product’s delivery.
Above risks are described in a generic way and not taking time to deeply think about them could backfire massively (often not immediately but potentially years later which can make the damage even more substantial).
Besides product and technology risks there are also other risks which have to be assessed if not only a product is to be built but an entire team or even an entirely new (startup) company.
Those risks consist in - essentially - the remaining items listed in Marc Andreessen’s Onion Theory of Risk, which I have described in detail in this post, i.e.,
Distribution risk: How will you distribute the product and how are the assumptions validated?
Marketing risk: Will you be able to cut through the noise, how much will it cost and what are the economics of customer acquisition?
Market risk: Is there a market for the product?
Competition risk: Are there too many startups or incumbents already doing this?
Timing risk: Is it too early or too late to launch such a product?
Financing risk: After securing initial financing, how many more rounds or iterations are necessary to become profitable and what amount of $$ will be required?
Founder or team leading risk: Do you have the right leadership or founding team?
Hiring risk: What positions does the team need to hire to execute the plan?
It is fine not having final answers to all questions above when starting to build a product.
But the important point is that you have deeply thought about all questions above in order to estimate the related risks.
If you did not, take at least a day, a week, a month or whatever it takes to think about them before building anything.
Your future self will deeply thank you!
If you’d like to learn more, there are 3 ways I can help you:
Subscribe to this newsletter if you want to get actionable tips on software product management.
Email me at danielschmitter@substack.com to provide suggestions about blog topics.
Follow or connect with me on LinkedIn here.