If you work in Product, chances are that you are struggling with any number of the following problems:
Twenty years since the publication of the Agile Manifesto, we seem as far away as ever from actual agile software delivery.
Given the pressures they face, Product Managers often either
All too often they end up doing both.
Most of the time, it's not the Product Manager's fault. Sometimes the organisation just can't decide what it wants. I was once hired by an organisation to work on a particular product. I had been there two days when the CEO walked into standup and announced he wanted to pivot to a different product, and we were effectively starting from scratch.
Other times, the organisation just won't listen. I've seen teams micromanaged to within an inch of their lives. I've heard of stakeholders design solutions and present them to teams for implementation with a date for delivery already promised. I once worked for a company that refused to pivot in the face of customer feedback, wasting millions building a product absolutely nobody wanted.
Product teams often reach for a framework to try to protect themselves. It rarely works. The frameworks are usually too abstract and business demands are too immediate for teams to successfully adopt them. Even where the team can embed them, the frameworks are either too focused on tactics or on a high-level strategy. There is not enough focus on linking the two.
Organisations consistently struggle with the trade-offs between commitments that teams are expected to make, and the fact that we don't have a perfect view of what will happen over time. When stakeholders focus on when something will be delivered, teams often react by producing monolithic roadmaps that pretend absolute certainty about the future, listing features to be delivered rather than problems to be solved. Using these roadmaps leave teams with no measure of success other than feature delivery. There's no concept of customer or user value.
The unintended consequences are that teams don't learn from the outcome of their work, or know when external circumstances have drifted from their assumptions. They just continue to execute against the roadmap, regardless of the value delivered, or what the organisation has learned.
Where teams have a North Star, there's often not enough structure in place to ensure that the work that they are doing is aligned with achieving that goal. A lot of teams either don't have a North Star, or it's poorly defined. Many teams, whether they have one or not, would struggle to tell you how the work they are doing is moving the organisation towards accomplishing it.
Even where organisations adopt goal-based tools such as Objectives and Key Results (OKRs), they often just put the same monolithic roadmap in a different format. Lip service is paid to learning, but the guiding principle of how to most cheaply learn the next most important thing is absent. It's usually not even clear that teams could identify the next most important thing.
Because of this disconnect, when the organisation pivots due to missing its numbers or a change in strategy, teams often don't adapt. They just keep executing against a plan that's no longer fit for purpose. It's waterfall without change control.
If we agree that all of this is bad, and it is, how do we find our way out of it? How do we get ourselves into a healthier situation?
We need to take a step back and think about what we're trying to achieve. We need a framework or a way of working that will enable us to:
This is my attempt to create that framework - welcome to PandA
Work flows from right to left in the graph below. Teams make more deliberate choices based on experimentation and evidence before delivering and then appraising the impact of their work.
It's all about alignment. We need to line up strategy with outcomes by giving product teams the tools to:
Teams need to be able to consider the future prospects for their product, inspect the company strategy, and recognise how their product contributes to it. They need an evolving roadmap where they can continue to align their efforts with the wider organisation and address any technical debt they carry. They must measure the outcomes of delivered work so that they can learn and pivot accordingly.
The PandA framework enables this by splitting the Cone of Uncertainty into a number of discrete phases.
The further along the cone of uncertainty we look, the more we should be thinking about what we might do, rather than what we are doing or will do. Moving right-to-left through the framework, we start with what's possible. What are the problems you might solve with your product? Create some what-if scenarios. Embrace the breadth of places you can go.
In the medium term, which of these possibilities are most aligned with the company strategy and the team's goals? What can you learn that will help you identify the best opportunities? What assumptions are you making? Where are the biggest risks? The answer to these questions should help you to form hypotheses about potential areas to invest effort while you design and complete experiments to de-risk your assumptions. Even if you're unlucky enough to work in an organisation without a clear product strategy, you should be able to ask yourself these questions to formulate hypotheses worth testing.
As you learn from your experiments and refine your hypotheses, you can start to identify priorities for the team to work on. Teams take the next-highest priority and deliver against it. The team promises to deliver work based on its priorities.
For software that has been released, the team appraises its impact, and measures it against their original hypotheses.
As well as ensuring its work is aligned with the long-term vision, the team ensures that it is co-ordinated with the organisation's broader strategy as it evolves in response to events.
Click on the sections below to learn more about each phase. There's a short fictional example for each phase to help illustrate the activities the team undertakes.Looking into the far future, say more than 9 - 12 months away, the cone of uncertainty widens to the extent that planning work in detail is worthless. This far out, the team should be asking very general questions about where they might take their application. 'How might we...' is a great framing tool for thinking of all the ways that the product could serve customers in new and interesting ways.
As the team thinks about the possibilities for its product, the strongest ones, or those most aligned with its goals, form the basis of hypotheses and are pulled into the 'Potential' phase for further investigation. Not all possibilities will become potential ideas for the application, just like not all the potential ideas will necessarily be prioritised.
As the team is looking into the distant future, they shouldn't feel constrained in how to consider the possibilities for the product. Any feedback from customers, stakeholders. or ideas based on where the organisation might be going should be recorded as possibilities.
Teams should meet regularly to brainstorm ideas for the product. Any ideas that are not instantly dismissed, wherever they come from, should be saved and reviewed. The strongest possibilities should form the basis of the hypotheses that are created and tested in the Potential stage.
The Product Team at P&A Utilities have a successful energy management B2B SaaS product. In order to stay ahead of the competition, the team carries out market research, analysing industry trends and customer feedback. It also keeps abreast of technical and software developments, keeping an open eye for opportunities to improve and pay down its technical debt. It takes this data into regular brainstorming sessions, where the team present their own views and synthesise this data into possibilities for their product. All possibilities are maintained in a Miro board and reviewed regularly.
Among the possibilities identified, they decide that integration with social media applications in use by their customers, such as Slack, could give them a competitive advantage.
While the cone of uncertainty is narrower here than in the 'Possible' phase, there are still large amounts of uncertainty and risk.
Rather than rigidly planning and ignoring the environment, the team takes the opportunity to formulate and test hypotheses for problems they can solve. The team meets regularly to discuss hypotheses, understand how best to test them and review product and market research. Customer interviews and experiments guide teams in de-risking their assumptions. Reviewing where the business is and the outcomes achieved by released software should also inform potential next best actions.
Since the team can't be definitive about what it should work on past a certain time horizon, it holds regular strategy meetings to discuss:
The entire product team participates in these discussions, reviewing the four big risks (Value, Viability, Feasibility and Usability) and how to tackle them collaboratively.
As there are many things the team can potentially do, there should be quite a few hypotheses generated and tested. Hypotheses and test results are recorded somewhere the team can easily review and learn from them.
As the team at P&A Utilities continue to deliver value, they start to consider upcoming work for prioritisation. Examining the possibilities they have listed, they decide to look into the Slack integration further.
The team confirms that the organisation strategy is aligned with more integrations into customers' business. They run a Wizard-of-Oz experiment, where they manually send push notifications to a customer. They carry out customer interviews and offer a sign-up list for Slack notifications. The interest shown by customers and the experiment results tell them that this idea is worth pursuing.
They form a hypothesis that alerting customers on Slack will result in a 10% uplift in users taking recommended actions, resulting in a bottom line impact of $10 million cost savings for their customers on their energy bills.
The work that is to be prioritised is pulled from the potential phase, based on strategic alignment and the confidence of the team.
User stories are created, and designs begin to take their final shape through workshops involving the whole product team. Any dependencies the team has (or preconditions for delivery) should be noted, and managed with other teams. For example, if the team is expected to deliver new data-driven functionality that requires a new service from a platform team, both teams need to agree when the work will be prioritised and what can be promised.
Prioritisation should be driven by:
Teams may use frameworks such as RICE or MoSCoW to help define their priorities. Experiments should be prioritised alongside product work. Product marketing can start to inform customers with confidence of what will be included in upcoming releases.
As the team at P&A Utilities looks to define its next set of priorities, it looks at the results of the testing done on the Slack integration and decides to pull that into its backlog. The team realises it will need some infrastructure changes and co-ordinates this with the responsible team. The team runs some design workshops to step through the required functionality, and creates the user stories it believes will enable the developers to complete the work required.
In the current period (sprint/quarter/slice, etc.), the team has agreed what problem they are currently trying to solve. They promise to deliver certain functionality based on the user stories created in the prioritised phase. Everyone is aligned and working toward a well-defined user outcome.
Tasks are defined, allocated to the team and executed within its favoured working method (usually Scrum or Kanban or a mix of the two). The team meets daily to track progress. Work is visualised and moved across a board as it proceeds from Ready for Development to Done.
Where PandA adds value is in ensuring continued strategic alignment of this work with organisational goals, and in embedding the measurement of outcomes in the appraised phase.
The team at P&A Utilities break down the user stories for the Slack integration into tasks. They continue to co-ordinate efforts with other teams as required. At daily standup, they track progress and release the software as it is completed.
Once an increment of software has been released, the team appraises whether it has had the desired impact. In the PandA framework, teams value outcomes over inputs. It is vital that the team confirms and measures the value of released work to the customer.
Because the framework is driven by hypotheses, the team knows what it expected its released software to achieve. They observe the results of customer interaction with the software, gathering usage data and/or completing user interviews. They then measure whether they achieved the objectives they set out when creating their hypotheses.
Whatever is learned from this data is then applied to devising further potential work and possibilities for the product. Thus, we can see the framework operates as a cycle based on information and workflow.
Once the Slack integration is delivered, the team measures its impact. Their hypothesis was that this would result in a 10% uplift in users taking action in response to alerts, and that customers would see $10 million cost savings in the following six months.
Observing user behaviour, the team sees that there is a 15% uplift in users taking action. However, this results in a cost saving of only $2 million for their customers. The team inspects this data and forms a new hypothesis that the algorithm generating the alerts requires improvement as it is not creating enough high-value alerts. This hypothesis will be reviewed and work completed as the team considers further potential work.
The PandA framework offers a way to balance the short-term objectives of the organisation with longer-term goals and the uncertainties inherent in software development. The goal of the framework is to ensure alignment of outcomes with strategy. It's a lightweight framework, bridging the tactical and strategic gaps that often exist between execution and business strategy.
Using the framework will enable teams to
The framework enables teams to create and own a roadmap that invites experimentation and discovery while providing direction without being overly prescriptive. It's a less painful way of thinking about and managing software development. My hope is it can add some value to your organisation and improve your outcomes. Give it a try. Let me know how it goes.
Click here to read about how the framework interacts with Sales and Marketing, aligning your whole business with the customer's interests.
First published 4 Apr 2023