PandA
A framework for product stategy
Product teams are expected to deliver on time and innovate, to stay aligned and be autonomous, to be accountable for outcomes while being rewarded for output.
How do you navigate these contradictory demands?
Spinning plates
If you work in Product, chances are that you are struggling with any number of the following problems:
too many simultaneous demands
little value placed on discovery (product or technical)
inadequate prioritisation
not enough planned work, resulting in reactive development instead of proactive problem solving
feedback from customers never reaching the development team
no link between the work and the team’s or organisation’s strategic goals
feature delivery being incentivised at the cost of innovation
Over 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
create waterfall-style product roadmaps, giving the illusion of certainty, or
get so caught up in the immediate demands being placed on them that everything becomes urgent.
All too often they end up doing both.
Muddled thinking
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 that had been in development for months. I had been there two days when the CEO walked into standup and announced a pivot to a different product, and we were effectively starting from scratch.
Other times, the organisation doesn’t listen to feedback, internal or external. I've seen teams micromanaged to within an inch of their lives. I've heard of stakeholders designing solutions and presenting them to teams with dates for implementation that cannot move, but have no data behind them. I once worked for a company that refused to pivot in the face of customer feedback, wasting millions of dollars building a product absolutely nobody wanted.
A bad system will beat a good person every time. - W. Edwards Deming
Product teams often reach for a framework to try to protect themselves. It rarely works. The frameworks are often too abstract and business demands too immediate, resulting in work management isolated from strategy, or worse, planning theatre. This gap between tactics and purpose needs to be addressed.
The illusion of certainty
The unintended consequences of this gap 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 blindly execute against an output-based roadmap.
Due north?
Where teams have a North Star, there's often not enough structure in place to ensure that the work that they are doing supports achieving that goal. Many teams, whether they have one or not, would struggle to tell you how the work they are doing is moving the organisation towards achieving it.
Organisations that adopt goal-based tools such as Objectives and Key Results (OKRs), 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 how 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.
So, what can we do?
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:
understand the possible ways to achieve our mission.
research potential hypotheses and solutions, learning what wouldn't work as cheaply as possible.
prioritise learning based on the testing of these potential hypotheses as well as the evolving needs of the business.
promise delivery against those priorities with a reasonable amount of certainty.
understand the customer's problem so completely that we have an objective appraisal of the success of our deliveries in solving that problem.
consistently check for alignment with the organisation's evolving needs and priorities.
This is my attempt to create that framework - welcome to PandA.
The PandA Framework
How is it different?
The framework takes inspiration from ideas such as Janna Bastow’s Now-Next-Later and
’s 12 month roadmap. Those frameworks diagnose similar problems with traditional roadmaps. However, where those frameworks focus on discovery and future work, PandA emphasises more structured approaches to learning from delivered work and whether outcomes match expectations.The framework splits the Cone of Uncertainty into a number of discrete phases, enabling teams to consider the future prospects for their product, inspect the company strategy, and recognise how their product contributes to it.
These phases can be developed into an evolving roadmap that measures the outcomes of delivered work so that they can learn and pivot accordingly.
Why PandA?
What's in a name? As I was sketching out the framework, it hit me that every forward-looking stage could start with 'P', while the need for alignment and to inspect existing work (or 'appraising' it) gave me the opportunity to name it after my favourite animal. Who could resist?
Structuring uncertainty
PandA looks at what is happening today and then looks to the future, acknowledging that uncertainty grows the further forward the team looks. A PandA roadmap has distinct phases and activities to be completed with an eye to what is already live with customers, and a focus on the future.
The further along the cone of uncertainty the team looks, the more they should be thinking in broad terms about the problems they could solve. Coming closer in time, choices are made about the priorities the team will actually take on before measuring their impact.
The team uses regular progress reviews with stakeholders to clarify that their work is aligned with the long-term vision and that it is co-ordinated with the organisation's broader strategy as it evolves in response to events.
Let’s step through the framework phases, starting with the present and moving into how to address growing uncertainty the further into the future you gaze.
Appraise - where are you now?
For software that has been released, the team appraises its impact, and compares it with their original hypotheses. They observe the results of customer interaction with the software, gathering usage data and/or completing user interviews.
These data generate insights into further potential and possibilities for the product as per the cycle in Figure 2.
Timeline to delivery
Software is already in production
Sample artefacts
Hypotheses being tested
User feedback
ROI
Usage data supporting/disproving hypotheses
Sample activities
User interviews
Usage data inspection
Market feedback
Monitoring competitor responses
Sample ceremonies
User research and feedback reviews
Promised - what’s being delivered now and next?
The team should constantly be pulling prioritised work into their backlog as they deliver and appraise. The team effectively promises to create a solution to the next most important problem they have defined. This promised work is based on the choices made and dependencies resolved during the prioritise phase. Teams may follow Kanban, Scrum, or any other delivery methodology. PandA is agnostic of these approaches.
Timeline to delivery
Coming weeks
Sample artefacts
User stories and acceptance criteria
UI and system designs
Description of the data that will be used to measure success
Sample activities
Design workshops
Working software
Testing marketing messages for new or improved functionality
Sample ceremonies
Standups
Distillation sessions
Progress reviews
Prioritise - making choices
Prioritisation decisions are shaped by the explorations of the potential phase, using frameworks such as RICE and MoSCoW. Experiments are prioritised alongside product development work.
Prioritisation should be driven by:
the best fit with organisational strategy and current positioning
understanding the riskiest assumptions
experiments that can de-risk hypotheses
user research on customer problems
the size of the bets being made versus the potential payoff
Product marketing can start to inform customers with confidence of what will be included in upcoming releases.
User stories are created, and designs begin to take their final shape through workshops involving the whole product team. Any dependencies or preconditions for delivery should be noted, and managed with other teams.
For example, if the team intends 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.
Timeline to delivery
Coming months
Sample artefacts
User stories
UI and system design outlines or wireframes
Sample activities
Dependency mapping workshops
Documenting use cases
User testing against prototype functionality
Go-to-market planning
Sample ceremonies
Workahead
Potential - inspecting possible futures
Since the team can't be definitive about what it should work on past a certain time horizon, they hold regular strategy meetings to discuss:
what metrics tell them about the software it has released
feedback from customer, market and product research
hypotheses about how to move the needle for the product
experiments and further research that can test these hypotheses
results from these experiments and how they inform priorities or the need for further tests
the team's focus and how it connects into the wider product and corporate strategy
any pivots the team should make due to organisational factors
The entire product team participates in these discussions, reviewing the four big risks (Value, Viability, Feasibility and Usability) and which of the possible things to investigate further.
Customer interviews and experiments can guide teams in addressing risk. While the cone of uncertainty is narrower here than in the possible phase, there are still large amounts of uncertainty. Reviewing where the business is and the outcomes achieved by released software will also inform potential next best actions.
Timeline to delivery
6 - 12 months
Sample artefacts
Hypotheses to be tested in appraise phase
Experiments to de-risk assumptions
Sample activities
User segmentation and testing
Product research
Sample ceremonies
Strategy reviews
Progress reviews focused on experiment results
Possible - starting at the end
Looking into the far future, say more than 12 months away, the cone of uncertainty widens to the extent that planning work in detail is worthless. Teams should think about ideas and supporting conditions. The funnel for ideas should be wide, taking in market and sales feedback, strategy discussions, customer interviews, and anywhere else that may hold valuable information.
This far out, the team ask broad 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.
The strongest candidates 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.
Timeline to delivery
12-months-plus
Sample artefacts
Documented ideas and assumptions
‘How might we’ problem statements
Risk analysis associated with ideas
Sales feedback
Sample activities
Ideation
Testing assumptions
Market research
Sample ceremonies
Brainstorming on potential problem statements
Each set of artefacts creates a systematic way of looking at the problem space and ensuring that the team are working on the right things. Let’s step through a worked example of the framework to demonstrate how a PandA roadmap is created and looks.
A worked example
For the purposes of this example, we’ll follow a piece of work as it moves through each phase from the widest point of the cone of uncertainty through to appraising the impact of the software delivered.
Possible
The Product Team at P&A Utilities have a successful energy management B2B SaaS product. In order to stay ahead of the competition, they carry out market research, analysing industry trends and customer feedback. They keep abreast of technical and software developments, with an eye for opportunities to improve and pay down technical debt. They take all of this data into regular brainstorming sessions, where members and stakeholders present their 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 agree that integration with social media applications in use by their customers, such as Slack, could give them a competitive advantage.
Potential
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 choose 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.
Prioritised
As the team at P&A Utilities looks to define its next set of priorities, it looks at the results of the testing on the Slack integration and pulls that work into its backlog. They realise that they will need some infrastructure changes and co-ordinates this with the responsible team. They run design workshops to step through the required functionality, and create the user stories that will enable the developers to complete the work required.
Promised
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.
Appraised
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. They inspect this data and form a new hypothesis that the algorithm generating the alerts requires improvement so that it will generate more high-value alerts. This hypothesis will be reviewed as further potential work.
What about OKRs?
OKRs have become an increasingly popular way for teams and organisations to plan work. Too often, these plans disappear once they make contact with reality. The PandA framework can be used with OKRs. Objectives are potential outcomes or possibilities, and key results are foundational to the hypotheses created in the potential phase. In many ways, PandA supercharges OKRs because it gives teams the language and the structure to appraise their achievement of key results, which is often a massive gap in their current approaches.
In summary
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. 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
focus on immediate work
think in outcomes
measure their impact against those planned outcomes
define their upcoming work pragmatically
ensure their work is in harmony with the business strategy.
PandA helps teams to create and own a roadmap that invites experimentation and discovery, 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. I encourage you to try mapping the work you’re doing on to the phases of the framework, and I’d love to hear how it helps to address your product development challenges.