Six Practices to deal with assumptions, risks and priorities
In the making of a new product, you have some very few proven assumptions (realities) and a lot of not proven ones. That’s good because those assumptions gives an interpretation of reality, a set of axioms that serve as a starting point to build that product that will change the world, as you are assuming it is.
Failure appears when something you assumed proved to be false. That’s the time to review our axioms, with the honest willingness to change them if necessary.
For a Product Management perspective, the longer you wait to realize an assumption is false, the more expensive it is to change what you built over that assumption.
The “cost of changing what was built” as time passes and the probability of the happening that in fact it was a bad assumption is what I understand as risk.
Here my six practices to embrace and live comfortably with assumptions, risks and priorities:
- Associate a risk numeric value to each assumption.
- Associate a risk description and the correspondent assumption to each User Story.
- Before starting the product development, be sure to have cleared all the higher market, platform, technology risks.
- Refine your persona.
- Talk A LOT with users fitting your persona.
- Continue refining your persona in the process of talking.
- Review market penetration of the platform and technology used by your product.
- Review market trends.
- Review the Business Strategy of your company.
- Star developing those User Stories with higher Business Value and those with the higher risk associated. Answer the tougher questions first.
- Pay consulting services to a Subject Matter Expert to review the iterations increments. This is a review process independent, not related to the Team Review Meeting. Remember the team presents the increments to the Product Owner, not to the SME, at least of course the PO is the SME.
- Start a customer base, even when you have only the concept of the product.
Further Reading
Brutal Prioritization in Agile: cut costs by NOT building the fluff




