The Jerry Maguire quote, “Show me the money,” has become synonymous with the relationship between choice and money. Ultimately, as my Grandmother often said, “The golden rule is the guy with the gold sets the rules.” And for many organizations, portfolio planning is where investment choices are made. That process sets the scene for how teams are organized, what work is being done, and the ownership of the work. This planning process is enormous for many large organizations, requiring large groups of people to prepare and execute the process. There are many meetings and much politicking. Ultimately, planning is where power and authority are distributed and status is reinforced.
So, any product-led transformation must change how work is funded, team goals are set, and investments are made. That means the portfolio planning process needs to change.
Changing the approach is not easy. Many organizations wrestle with portfolio management. Approaches like the Scaled Agile Framework's Lean Portfolio management approach have become popular due to the challenges organizations face when managing the need for plans while dealing with uncertainty and complexity.
If you want more details about Agile Product Operating Model (APOM) and product portfolio planning, I suggest you look here.
Here is a summary of some of the key ideas.
Fund the products (teams), not the work.
This seems obvious, as moving to a product model empowers teams to take ownership of their product, allowing a stronger connection between delivery, users, and stakeholders. By funding the product based on a simple value, strategy, and cost model, organizations can then empower the product teams to do the work that provides the most value. As the situation changes and learning happens, teams can change their work. This approach changes portfolio planning from a work-driven approach to something more like VCs funding their portfolio companies. They fund the teams based on value and how it fits into a strategic landscape.
The reality for most organizations is that when they review a product's value and put that into the context of their existing investments (people in existing teams with existing skills), there might be an uncomfortable disconnect. This is also when decisions on build vs. buy can be made, allowing leaders to focus on their portfolio on capabilities that will provide a competitive advantage. Of course, this does not happen on day one, and most organizations slowly evolve their product portfolio, considering existing investments and legacy. But those hard conversations are good for a shared understanding of value and investment. Being transparent about the ultimate value of one product versus another can drive change within the organization.
Minimize cross-product initiatives that require portfolio management.
Even when organizations move to a product model, cross-product work, such as GDPR or new company sales initiatives, will be needed. How are those initiatives dealt with?
Other than that, the need for this type of work can ultimately undermine product work by creating a bottomless list of cross-product work that removes any strategic choices from the product teams.
A straightforward approach to counter this problem is to allow Product Owners to prioritize the work themselves and ultimately decide if and when to support the initiative. This encourages initiative owners to sell the initiative in value terms, allowing product teams to make the final decision. The problem with that approach is that most initiatives would likely become MUST-HAVE, and then the organization forces the Product Team to work on them. For example, can a team really turn down doing GDPR work?
Instead, a more balanced approach is for senior leaders to decide on which cross-product initiatives are large enough to warrant a focus, allowing for smaller cross-product initiatives to be owned by the product teams as part of business as usual. One small list is defined for them to work with the affected product teams, deciding if additional investment is needed or even creating new product teams, etc. But these initiatives must be minimal; otherwise, cross-product work will take up all the time of the product teams, leaving no room for innovation.
Discovery, delivery, and validation happen within the product teams.
One of the biggest challenges that development teams face is when they are given a project where someone else has undertaken discovery. Another team or individual deemed that these features were possible and valid. Discovery is a key process for any product, and for maximum success, it should be done by the same team that is going to finally do the work. Discovery, delivery, and validation happen within the product teams.
I am sure many of you are saying “of course,” and I applaud that sentiment, but imagine a team in an organization using something like Lean Portfolio Planning. The process takes ideas through the funnel into reviewing and analyzing, where those ideas are refined and first-level estimation is undertaken. The management will likely call on product team members to help, but that work will be managed separately. After all, it has not moved through the portfolio backlog yet. Suddenly, work is either being pulled from somewhere else, or a different group is working on it. It gets complex, and insights may or may not be shared with the delivery team if that work is feasible.
Instead, discovery work is treated like all work. It is prioritized alongside other work and then taken by the product teams in a transparent and normal way. There is one Product Backlog, and the work on it is planned one Sprint at a time. If Stakeholders need a longer-range forecast, then work is done, but the norm is continuous discovery and delivery!
Work is defined in terms of outcomes and measures.
This sounds very simple, but even at Scrum.org, I can view our roadmap and still see items that do not clearly describe the outcome we are seeking or how we measure it. If the Scrum.org backlog is representative, these tend to be things that when I am asked about them, I say ‘we have to do this’, but even in those situations, spending a moment reframing the initiative regarding outcomes can help. And at the portfolio level, this is even more important. How many times have you been presented with a new work initiative only to discover that there is little alignment about impact or value? Introducing an outcome-based approach for all work provides a uniform approach to describing outcomes and the measures to assess them. Objectives and Key Results (OKRs) can be a nice mechanism for this approach. OKRS provide a standard format and structure to prepare both the goal and measures and encourage a level of transparency and transparency.
Incentives, structure, and governance align with business and product strategy.
Imagine an organization that has implemented a product model, aligned teams, and has an effective planning process that balances cross-product work with product-driven needs, but still has problems. That can happen if other operating model elements are aligned with different objectives. For example, incentives are aligned to individual success based on annual KPIs, which differ from the product objectives, or governance processes that slow down work and are not transparent. Looking holistically at the operating model and how plans once made will be executed, are often the final pieces to success.
Transparency, cadence, and clear ownership are required
I remember a conversation with Ken Schwaber the co-creator of Scrum, about a realization one of the early adopters of Scrum had and how it reframed their use of Scrum. As told by Ken, the conversation went something like this.
Client ‘ok, so we iterate until we get it right, but what happens if the Product Vision is wrong’
Ken ‘ We change the vision and see if that one works’
Client ‘What do you mean by change the vision. But I thought that Scrum worked.’
Ken ‘It does. It shows you what is wrong’
Scrum is not a silver bullet and can not work magic. However, Scrum and APOM can highlight what is wrong and provide space for teams and executives to fix those problems. However, doing that requires transparency and a process that provides visibility and space to fix the problems. From experience, that also means clear product, cross-product, and portfolio ownership. Combining the elements of clear goals, good measures, transparency, regular cadence, and clear ownership, you have all the ingredients to build a sustainable product organization. One example of a cadence that can help is product reviews every two weeks, cross-product reviews every month, and portfolio reviews every 3 months. This allows organizations to build in a regular cadence around planning based on transparency.
But do we need portfolios?
In an ideal world, I can imagine that organizations are comprised of many product organizations all operating under their own roadmap, funded by some centralized, almost VC-like funding council. Shared assets such as data and knowledge are tokenized and shared via a capitalized blockchain. But for most organizations, this micro-organization approach would be so far from their current reality it would be impossible to implement. Instead, we will be stuck with a compromise that enables large, complex organizations to adopt a product model while still operating within the constraints of existing systems and processes. Change will need to be gradual. Organizations can incrementally adopt a more product-oriented approach by focusing on the six simple principles listed above.
This was part three of a four-part blog series. The last blog will focus on organizing for the Agile Product Operating Model.
Read Part 1 - Fundamentals
Read Part 2 - Product Definition