Welcome back to The Lens, my newsletter on Product Management. If you like what you read, please forward it to someone you think may get value. Thank you.
Risk Reduction:
One of the key lessons from either MVP (minimum viable product) or Lean Startup is to launch early/soon and use learning in the field to improve the product. It can extend beyond MVP. In fact, the ability to learn also influences the prioritization of features. The prioritization framework of SAFe, for example, includes ‘risk reduction-opportunity enablement’ which should ideally either account for prioritizing a solution that provides information so that, it can either reduce future risk or build a foundation to further develop.
While testing, it is useful to test a hypothesis that provides the most information. Validating what is true just helps gloat ourselves, but doesn’t provide the information of “what if”. Not always, but sometimes, ‘what if’ could provide additional user value or business value. For example, in one of the recent implementations we launched with an experience we knew had minimum risk but may not be “maximum” benefit. It was successful, and there is little incentive to push the boundary now.
Below is a fun video, that really drives home that point.
I came across the above video through a recent post that lays out a methodology to accelerate projects by calculating a ‘risk reduction rate’ metric. You start by listing ways your project or product can fail, and performing tasks that would reduce the risks faster.
Working with the technology team
It is imperative that technology teams are to be engaged early in the process to socialize the product, features, and solutions, and especially business problems. Often the alternative approaches offered by technology teams can result in a totally different solution. The purpose of the product team is to deliver better value to customers, faster than the competition. Rich Mironov’s article offers some pointers to make the teams more productive both from the process and the people view. Many of the suggestions in the process view are no-brainers and are usually taken care of by a properly implemented Agile process (or the SAFe, that he dismisses!).
However, the following two quotes resonate with me.
Clearly, frequently communicating goals and strategy. When our team understands the context of a problem and how users operate our software, they are empowered to imagine alternate solutions.
Carefully connecting developers and designers directly to actual user experiences clarifies their thinking and also boosts their enthusiasm. Emotionally committed teams can deliver twice the real value.
Similarly, Arthur Mor’s post includes some useful questions to help collaborate with technology.
I leave you with these thoughts. Let me know if you have any feedback. And do share with whoever is in the early stages of their PM career or is interested in getting into Product Management.