The final dimension in this series on digital product management concerns roles and responsibility. Surprisingly, in many traditional organizations, product managers have significant responsibility but surprisingly little authority. Instead, they need to align all the relevant stakeholders and reach decisions based on consensus.
Traditionally, this challenge is addressed by building a product management function where a hierarchy of product managers matches the system architecture. Within the function, the product managers align. Presenting one front to the rest of the company, they use their combined weight to ensure that their prioritizations are realized.
We can identify a trend in some companies, like Airbnb, where the product management function is disbanded. Instead, product management becomes a part of everyone’s role. Each individual is expected to spend time aligning the why and what with their peers, team and the rest of the organization.
The roles and responsibility dimension seeks to answer the question of who takes care of the various product management activities, for what scopes and from what viewpoints. And, of course, what alignment mechanisms are used to accomplish this. We’re going to explore three main responsibilities of product management: focusing on the vital few rather than the worthwhile many, organizing product management and balancing qualitative and quantitative data and insights.
Although we’ve discussed the topic before, it bears repeating: product managers often need to manage multiple stakeholders and there’s a very strong tendency to look for ways in which each stakeholder is offered a slice of what they want so that everyone is somewhat happy. We can often come up with great justifications for why the selected content delivers value for customers and other stakeholders. So, for a product manager, it’s extremely tempting to take this approach.
However, by peanut-buttering the available resources over so many different things, we’re making only small, if not negligible, progress in each of the areas prioritized by the stakeholders. This leads to the “worthwhile many versus the vital few” challenge: it’s not that each of the prioritized actions is bad in and of itself – each of the items in the prioritized backlog is valuable in some way; the problem is just that it won’t deliver as much value as a highly limited, focused set of prioritized actions, ie the vital few, would have had.
As every industry is in a digitalization journey, we now need to add all kinds of software, data, AI, cloud and other solutions to our offerings. In addition, we seek to adopt continuous delivery of value through DevOps, DataOps and AI/MLOps. However, that doesn’t mean that the requests for the older parts of the offering will disappear. Of course, stakeholders and customers still want improvements there as well. However, the return on investment on these improvements often is very low as compared to exploiting the novel opportunities.
One of the tactics I frequently use to start a conversation about delivering value is to calculate the amount of business value a single agile team has to deliver every sprint. With 8 persons in a 3-week sprint, for example, the team spends 24 person weeks or 0.5 FTE per sprint. A fully loaded FTE in many companies is well over 100,000 euros, but let’s use that for now. That means that one sprint for one team costs 50,000 euros.
The question is how much value this team has to deliver. That depends on the percentage of revenue that the company spends on R&D. For a typical company in the embedded-systems space, it’s around 5 percent. That means that every euro invested in R&D has to deliver 20x in terms of value, meaning that every agile team in the company, every sprint has to deliver 1 million euros of business value.
I’m sure that everyone has stories where a team delivered a feature that was a run-away success, producing outsized value. However, I’m talking about consistently and continuously generating 1 million euros of value for every agile team and every sprint. This can typically not be achieved by peanut-buttering effort over a gazillion initiatives and focusing on traditional, often commoditized functionality. It has to come from growing the business by delivering new customer value that wasn’t present before.
Focusing the entire organization on one or a very small number of large initiatives is scary as it brings a significant amount of risk. If you’re wrong and customers don’t care about it, you’ve wasted a significant amount of effort. It’s much safer to have many small initiatives of which some are wins, some are draws and some are losses. It’s easier to defend against criticism from the rest of the organization.
To reduce the risk of large initiatives failing, we rely on our exploration and “imaginate” activities. By running small-scale, low-cost and fast experiments with customers, we can de-risk large, focused efforts and increase the success rate of these initiatives. This is yet another reason why exploration and ensuring that we adopt the right mindset during exploration is so important.
Product management is highly susceptible to the “worthwhile many” syndrome where we divide our effort over numerous small initiatives and make small progress in each. Instead, we need to identify the vital few that will really move the needle for the company when successful. These initiatives are high-risk, high-reward, but we can de-risk them by focusing on small, low-cost experiments as part of our exploration activities. Not all will be successful, but even the ones that don’t pan out will give us incredibly valuable learnings. To close with a quote by Mark Pincus: “I like to bet on people, especially those who have taken risk and failed in some way, because they have more real-world experience. And they’re humble.”
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
