Why do we build unnecessary products?
Why do we deliver poor quality?
Why are we most often too late?
Why are most products more expensive than expected?
From a bigger perspective these are all different risks. Technical risks or business risks or risks in general.
What I’ve found interesting is how we deal with risks. Do we try to analyze more? Or should we try to communicate better?
In our experience most often it’s an awareness problem and a know how problem. Lets dive into these 2 topics. But before, make sure to watch the video
Awareness
Are we aware of all potential risks that we face in our journey? Some ideas from https://www.digicomp.ch/blog/2019/12/02/der-richtige-einsatz-von-scrum-lean-startup-design-thinking
What is the user’s problem?
Can we build it technically?
Does it fit into the product portfolio?
Can the user use it?
How do we earn money with it?
More things to think about come from Marty Cagan’s “Inspired” book. The tool: Product Opportunity Assessment (POA):
What problem will this solve?
Who are we solving a problem for and how big is that market?
What alternatives do competitors provide and why are we the ones who can succeed in this?
What factors are critical to success (e.g. partnerships with distributors)?
What metrics will we use to measure our success?
Why is this the right time to enter the market and what is our go-to-market strategy (i.e. how will we sell the product)?
Based on the above questions, is this an opportunity we should pursue?
The Business Model Canvas gives you additional things to think about https://www.strategyzer.com/canvas/business-model-canvas
In order to be successful, a product must be:
Feasible: your engineers must be capable of building it.
Usable: customers must be able to use it.
Valuable: the product itself must deliver value to customers, so they want to buy it.
Marty has an updated version of these 3 criteria to be 4 here https://svpg.com/four-big-risks/
We try to address these risks with different strategies. Lets dive into the Know How topic:
Know How
Once you are aware of the potential risks you face, you can decide to deal with them. Here it gets interesting because most people tend to jump to the conclusion that
more planning
more analyzing
more risk management meetings
will solve these problems.
Here is the 🤔 counter intuitive thinking: “The above things don’t solve any risks”.
In order to tackle risks what worked in our experience is:
Get creative to learn about others (end users, development teams, partners, service providers, …)
How can you validate if the users have really the problem that you think they have?
Sounds like you should start the 1st Sprint with focus on a Integrated Done Increment
Not like others spending 600’000 CHF on Not Done Software.
Build a prototype
Build a pretotype
Build a walking skeleton
Build quality into the product
Work on empathy and trust in your organization
🔨 Get in touch to learn how to do these.