We’ve talked about how transitioning to a product-led organisation requires empowered product teams.
So, how do you get there?
Focus on these 5 pillars:
- A compelling vision, principles and focused strategy
- Theme / outcome based roadmaps
- Team topology aligned to customer value
- Clear roles and responsibilities
- Shared success metrics and flywheel
Let’s dive deeper into each pillar.
Pillar 1. A compelling vision, principles and focused strategy
Working on a product without a compelling product vision is like flying a plane with your eyes closed. Who knows where you might end up?
The first thing you need to do is set a clear product vision that anchors the organisation to the future state.
What is a Product Vision?
The Product Vision should articulate WHO the customer group is, the current solution, WHY the current solution is unacceptable and HOW the desirable outcome will be achieved.
Why is Product Vision so important?
-
Focuses on the customer: A good product vision keeps the team focused on the customer.
-
It’s the North Star: A good product vision ensures the whole organisation has a common understanding of what they are hoping to accomplish together.
-
Provides people with meaningful work: A list of features on a roadmap is not meaningful. A good product vision shows people why this work is meaningful – how you can positively impact the lives of users and customers is meaningful.
-
Leverages relevant industry trends: A good product vision illustrates how you plan to leverage relevant industry trends and technologies that you believe can help you solve problems for your customers in ways that are just now possible.
-
Leads to improved team topology: A good product vision provides the engineering organisation with enough clarity about what’s coming in the next several years so they can ensure they have in place an architecture that can serve the need (more on this later).
What does a Product Vision look like?
Don’t worry – your product vision needn’t be a full blown prototype or 50-page slide deck. You can use a simple vision statement, like this template from Radical Product Thinking.
The product example here is Likelii, a wine recommendation engine:
Today when [amateur wine drinkers], want to [find wines they like], they have to [pick wines based on attractive labels or try what’s on sale]. This is unacceptable because [it’s hard to learn about wine this way and leads to many disappointments]. We envision a world where [finding wines you like is as simple as renting movies on Netflix]. We are bringing this world about through [our recommendations engine that helps you find wines you’re likely to like, and our operational setup that quickly delivers those wines to your table].
Let’s break it down:
-
Centre your vision on the problem
A good vision is not about your goals or your aspirations for your company. It’s centred on the core problem that you believe is worth solving – an innate problem in the market.
-
Test your vision with customers
Like Steve Jobs said, “Your vision should be such that it pulls both your employees and customers.” When you share your vision with customers, they should be nodding along with you.
-
Visualise the end state
What does the world look like when you’ve solved the problem you set out to?
A good vision should help you and your team visualise the end state that you want to bring about. Think big, think long.
“An inspiring and compelling product vision serves so many critical purposes that it is hard to think of a more important or higher-leverage product artefact” – Marty Cagan
What a Product Vision is NOT
A product vision is not a tagline or mission statement.
“We're here to organise the world's information and make it universally accessible and useful.”
That's Google’s mission statement, not their product vision.
Take a look at Asana’s product vision:
“In the future, anyone can prioritise their day across all of their apps with Asana. Imagine a virtual assistant that harmonises your to-dos with your calendar based on top priorities for your organisation and your career.”
Product Principles
Product principles are the next piece of the puzzle. The principles complement the product vision by “speaking to the nature of the products that your organisation believes it needs to produce”. (Marty Cagan, SVPG)
The principles reflect the values and ethics of the organisation, and also help guide strategic decisions such as when a team is faced with difficult trade-offs.
Product Strategy
Where the product vision describes the future state of the product, the product strategy answers the question of which problems should be solved.
So a great product strategy will clearly set out HOW the product vision will be achieved and WHAT problems to solve.
Creating a product strategy takes a lot of work. You need insights about your customers, enabling technology, and where the industry's going.
Your strategy is where you get specific with outcomes. It should highlight as few as possible (no more than five) focus areas to achieve the product vision, and articulate what outcome you want within each area of focus.
As Melissa Perri says, “There has to be outcomes at the highest level for the business that are connected to what the teams are actually doing, how they’re talking to customers, how are we incorporating that feedback and is that forming our strategy?”
Now you have the product vision and strategy, what next?
“Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create.” – Marty Cagan, INSPIRED: How to Create Tech Products Customers Love
Rather than being given exact deliverables, teams should be given problems to solve. This means they are empowered to figure out the best way to solve the problems, and should be held accountable for the results.
To become outcome driven, companies need to provide a clear link between the product vision, the problems being solved and the features being delivered.
That’s where the next pillar comes in.
Pillar 2. Theme / outcome-based roadmaps
The biggest leap for companies transitioning to be product-led is moving to outcome-based roadmaps.
The term ‘product roadmap’ has a poor reputation and for good reason:
“For many product people, product roadmaps have become a painful exercise in futility. The pace of change; lack of clear vision, goals and internal alignment; and an excessive focus on feature and date specifics quickly make obsolete their painstaking work, and this leaves product managers asking why they should invest time in a roadmap at all” – Product Roadmaps Relaunched, Todd Lombardo, Bruce McCarthy, Evan Rayn, Michael Connors
But outcome-based roadmaps change the game entirely.
What is an outcome-based roadmap?
An outcome-based roadmap focuses on delivering value, is based around a set of customer needs, problems or jobs to be done, and is organised in themes.
Here’s the important part: the outcomes are goal and benefit oriented.
This means everything on your product team’s roadmap should be clearly there to support your company product vision and strategic intent.
In other words, the roadmap should be focused on the problem to solve rather than a list of features.
Why you need an outcome-based roadmap
-
It puts the customer at the centre – it focuses on the value to be delivered to customers, not just a list of features.
-
It gives a shared view of all the work, organised around value, which enables better discussions to prioritise work.
-
It empowers teams with shared ownership – teams are likely to feel a greater sense of shared ownership and autonomy because they understand the ultimate goal and strategic context of the work.
-
It’s flexible and can withstand change – teams have the ability to pivot rather than being forced to stick to a plan and timeline they know is destined to fail. If there is a sudden change in market conditions, the whole re-planning process to meet that demand doesn’t need to take six months, which means executives can get major initiatives to market faster and ditch outdated products sooner.
Wait – what’s the problem with a feature-driven roadmap?
We’ve all seen feature or milestone driven roadmaps – they often look like project plans and are represented as Gantt charts. They usually set deadlines many months or even years in advance.
The problem is exactly that – they are attempting to predict the future too far in advance, giving too little information and leaving no room for learning.
We get it – humans like certainty. So it’s natural for stakeholders to want everything locked in well in advance. But unfortunately, this doesn’t reflect the complex systems required for knowledge work, which is essential to product development.
At the other end is the agile and lean approach. They focus on working software over documentation, with everything calibrated around short term ‘sprints’. This doesn’t give executives enough ability to think and communicate long-term objectives.
Often a company is using feature-driven roadmaps because they have made the transition to Agile and Lean delivery methods, but the mindset shift hasn’t yet reached the executive or leadership level. They are still operating their teams as feature factories. Because there are low levels of trust, they need to tell teams what to build – there’s no product thinking maturity.
The hidden benefit of outcome-based roadmaps
The important thing to realise about outcome-based roadmaps is that the real benefits are in the learnings from the process of creating the roadmap – not just in giving the team a finished roadmap to follow.
Simply asking questions to derive an outcome-based view can expose how nobody really knows why they are ‘building the thing’.
For the business, the ultimate benefit of an outcome-based roadmap is that everything on the roadmap has to be clearly able to be connected with value, as defined in the product vision and strategy.
So, the outcome based conversation can quickly shine a light on vanity projects or unnecessary refactoring. You need to ask: how is this getting us closer to our ultimate end goal?
How to create your outcome-based roadmap
Rule #1: Never start with the roadmap itself
Do not pass GO if you do not have at least a basic and documented version of your vision, business objectives, understanding of your unique value proposition and key areas of value your product delivers for customers.
Rule #2: Do not create roadmaps for the whole product organisation simultaneously
You don't have to start with the whole organisation. Choose one area of the product and customer value and outcome, and start from there.
Rule #3: Take an outside in and inside out perspective on your product
Invite people into the process from both the business and customer perspective. The roadmap, as a strategic artefact, is a layer cake, so you will need to come armed with your key business objectives, metrics, etc.
You will also need to be able to map your key customer journeys and triggers, which means holding a series of workshops with people from your business who know the customer, the product and the technology. It helps if you can bring in a service designer or someone with experience mapping customer journeys, whether it’s a UX designer or a customer focused business analyst.
Be mindful that this whole process might feel too slow and detailed for many executives – but it is essential.
Just remember Rule #2 – only focus on one area at a time.
What should your outcome-based roadmap look like?
Your roadmap should be able to clearly and succinctly communicate what outcomes your teams are working towards now, next, and what they may work towards in the future. If this isn't clear at a glance, you need to rethink your roadmap.
Here are some things to avoid:
-
Too much detail: A roadmap is not a release plan or a specification. Keep it brief and to the point.
-
Shiny things and ‘big bang’ releases: Creeping back to features or shopping lists that keep an executive or sales team happy today, but won’t ever really be delivered, means lots of pain down the track.
-
Inflexible dates for delivery: Focus on providing guardrails, articulating “now, next, later” and aligning to your overall delivery cadence and planning ceremonies. As teams learn, they may choose to bring forward a release of value to get something tested in market sooner – but there is no incentive to do this with a fixed project plan.
Keep it flexible
Remember: the roadmap is a living document and a communication device between the product manager, the team and the wider organisation.
The product manager needs to be constantly talking to customers and if insight from this means a change is needed, then the roadmap should reflect this. It’s unlikely the major outcomes will shift more than quarterly, unless your organisation is in a big state of flux. But you should be open to the possibility of changes in priority as teams learn and adapt to both internal and external circumstances.
Where does release planning come into play?
The business may initially feel lost without lots of ‘green’ and ‘red’ status indicators on a chart to indicate progress. But an outcome-based roadmap still needs to be supported by the relevant delivery management practices, risk tracking and reporting.
Let your agile or lean software delivery practices inform your release cadence. Public facing releases will still need to be planned and coordinated across your organisation, but you should have a clearer sense of common direction when you next sit down with the product marketing manager based on the roadmap.
Pillar 3. Team topology aligned to customer value
How are your teams organised?
Team topology is how you organise your people into teams and how you break up the work among different teams to best enable them to do great work and deliver better value for customers, sooner.
It includes the structure and scope of teams, their relationship to one another, and how they are aligned.
Sound simple?
It’s actually one of the hardest and most important decisions product leaders will face.
Companies tend to organise teams in three main ways as they mature in their technical and product offerings. Teams are organised around either:
- Technical components
- Features
- Value streams
Being product-led starts by organising your teams around customer value.
This gives a clear sense of purpose to teams, enabling a better focus on customer value delivery, which leads to product success.
The most successful product-led organisations rally around simple but clearly articulated customer centric value streams.
A value stream encompasses all the end-to-end activities needed to deliver tangible value to the customer. This includes processes from discovery of the problem, through to ideation and delivery.
Because value stream-aligned teams work on the full spectrum of delivery, they are closer to the customer and incorporate customer feedback in development cycles.
One Key Principle of Effective Team Topology
Teams have clear ownership and are accountable for the value they create
Your goal with the team topology is always to maximise empowerment. As explained by Marty Cagan in EMPOWERED, “when teams are unclear on which work applies to them, their empowerment is undermined”.
Done well, your product teams will be empowered with a high degree of autonomy and feel a real sense of ownership over their work, and how it contributes to the greater whole – the product vision.
These teams can tackle tough problems, move fast and see the results.
Pillar 4. Clear roles and responsibilities
Do you have the right people in the right roles? And do they have clear responsibilities?
This is the next key element to create empowered product teams.
If there’s overlap and confusion in role responsibility, it can lead to low levels of autonomy and accountability.
But don’t go overboard.
Rather, provide guardrails for the team that set a tone of collaboration.
While a particular role might be primarily accountable for something, the team is jointly accountable for the outcome. Therefore, at times, team members need to help cover responsibilities outside their primary area of accountability.
The Product Manager
As Melissa Perri explains in the Escaping The Built Trap, product managers have one very important job:
“They keep the team focused on the why – why are we building this product, and what outcomes will it produce? The chief product officer is the cornerstone of the product team in companies, helping to tie together the business outcomes to the roadmap and to represent its impact to the board.”
Product managers provide the much needed context for team members. That context forms the basis for thousands of micro-decisions made by a diverse mix of team members as they work to deliver product-market fit.
There are thousands of articles and books out there explaining what product managers do, but our favourite is Melissa Perri’s explanation using the common archetypes of bad product managers:
-
The Mini-CEO – They are the CEO of the product. They own it and tell everyone what to build. This is not true – they only own the Why of what they are building.
-
The Waiter – They are the order taker, asking what people want and turning it into a list of items to be developed. No goal, no vision.
-
The Former Project Manager – They are responsible for the “when”. When will a project finish? Is everyone on track? Will we hit our deadline? Whereas great product managers are responsible for the why? Why are we building this? How does it deliver value to our customers? How does it help meet the goals of the business?
What makes a great product manager
-
Deep knowledge of customers and business
Remember, a product manager on an empowered product team is a very different job than a so-called product manager on a feature team. Product owners don't generally bring any of that, and project managers certainly don't bring any of that. On an empowered product team, they are there for value and viability – they bring to the team deep knowledge of the customers, the data, how the business works, and the industry. They have deep empathy for the customers and understand their needs.
-
Focus on the “why”
“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing.” – Melissa Perri, Escaping The Build Trap
-
Prioritise against outcome-oriented goals
A great product manager will prioritise work against clear, outcome-oriented goals, because they know that’s the only way to define and discover real customer and business value.
So if you're gonna push decisions down to a team, the designers don't have that information and the engineers don't have it. So somebody has to be on the team that provides that knowledge.
Pillar 5. Shared success metrics and flywheel
We have talked about product-led growth, empowered teams, product vision and strategy, so how do we measure the success of our product teams?
How do you know it's working?
Traditionally, product teams are focussed on outputs. For example, a Product Manager will provide the team with a feature to deliver and the team will implement features and projects, and as such are not empowered or held accountable to results.
But what you really need for empowered product teams is shared success metrics.
Shared metrics mean that regardless of a person's role or job function within an organisation, they are part of a team running in the right direction.
For many years, the product manager role was referred to as “the CEO of the product”, because they tracked and set the key performance metrics for the product.
But viewing products in isolation from the rest of the business sets product teams up to fail.
After all, achieving all your product metrics doesn’t necessarily mean overall business success or even happy customers, unless the linkages are clearly articulated by your product vision and strategy.
Shared success metrics should be measured by outcomes that are aligned to business goals, not outputs such as features delivered by a specific time. They cover the critical work the team needs to do in order to meet the goals of the company.
When establishing shared metrics, start by focusing on the key business functions. So, in a sales driven organisation this may be the customer call centre, the digital service channels, as well as the marketing team, the operational team metrics and the customer service team metrics.
What could all these different departments possibly have in common?
Well, they all want the business to succeed right? They want customers to be satisfied, and for the company to see more sales, and possibly growth and expansion.
The language of these teams might be different. Often it falls to the product leaders to facilitate a common understanding of the shared outcomes and purpose, and translate these into metrics the rest of the organisation can understand, measure and deliver on.
Leading metrics vs Lagging metrics
Companies and executives often find it difficult to move to measuring success using leading metrics because business goals are generally defined using lagging metrics. That’s why businesses tend to revert to delivery metrics, not outcome metrics.
-
Leading metrics predict how well the organisation will perform in the future. Examples include the number of nights booked (Airbnb), time spent listening (Spotify), or daily active users (Facebook).
-
Lagging metrics usually follow an event (time) and are the direct result or output of the organisation’s activity. Examples include revenue, churn rate, and customer acquisition costs.
Moving from lagging metrics to leading metrics requires a change in mindset.
First, you need an understanding that it may take months for the predictors to result in real, successful business outcomes. So you need to use leading metrics to help you know you are on track.
It also means thinking more deeply about user insights and taking a deep dive into the product.
Take a look at Facebook’s key leading metric:
Users who reached 7 friends in 10 days were far more likely to remain engaged with the product than those who didn’t.
Success metrics need to align
There will still need to be both company wide metrics and department specific metrics – the key is that they need to align.
For example, your engineering team will work towards the company objective of increasing the number of customer transactions per quarter by delivering valuable new products and services online.
In doing so, they are striving to deliver reliable, efficient and bug-free software. So they will have their own set of metrics around measuring and reaching these quality assurance metrics.
At the same time, the marketing team may share the company objective around increasing overall sales from a new market segment for the quarter. But in execution they are likely measuring more granular engagement metrics like campaign open rates, clicks, and conversions.
How to implement shared success metrics
We’re talking about more than setting some metrics for your goals – this is about shifting the mindset across the organisation. To achieve this, leaders need to leverage the right metrics and ladder down across the organisation.
Anticipate that this may require dismantling some existing incentive schemes or structures, which could put some noses out of joint in the short term.
The reality is that the genuine adoption of shared metrics and the associated behavioural changes is often one of the biggest stumbling blocks for organisations.
Here are two red flags that you should look out for if you’re going to get it right:
-
Executive and leadership talk the talk initially, but then continue to focus only on ‘blunt’ metrics like revenue without genuinely integrating more customer centric team metrics into the way teams are incentivised and measured.
-
Rewarding teams for the wrong reasons – for example, sales to the call centre may attract commission, but they pull the organisation away from its overall business objectives and digital self service strategy.
Success Metrics and the Flywheel Effect
The flywheel is a business concept developed by executive coach Jim Collins in his book Good to Great.
Picture a huge, heavy flywheel. A massive metal disk weighing 2000kg mounted horizontally on an axle.
Now imagine that your task is to get the flywheel turning as fast and long as possible. Pushing with great effort, you get the flywheel to inch forward, moving almost imperceptibly at first.
Then, you keep pushing.
After hours of effort, you get the flywheel to complete one entire turn. You keep pushing, and the flywheel moves a bit faster. Then, gradually, the flywheel builds up speed and momentum, until it is spinning by itself, its heavy weight doing the work for you.
"You’re pushing no harder than during the first rotation, but the flywheel goes faster and faster. Each turn of the flywheel builds upon work done earlier, compounding your investment of effort." – Jim Collins.
If somebody asked you what was the one big push that caused the flywheel to turn, you wouldn’t be able to answer. Because every push has a part to play. Some pushes might have been bigger than others, but they were ALL important.
“There is no single defining action, no grand program, no one killer innovation, no solitary lucky break, no miracle moment. Rather, the process resembles relentlessly pushing a giant, heavy flywheel, turn upon turn, building momentum until a point of breakthrough, and beyond..” – Jim Collins, From Good to Great
The term “flywheel effect” was most famously used by Jeff Bezos in 2001. Essentially, Amazon's business model always put customers experience first, and gained momentum from there.
So, how do success metrics fit with the flywheel?
The flywheel ties your success metrics to customer and business value across the organisation.
For years, companies have structured their business strategies around the marketing prospects funnel — and it worked. However, today inbound marketing from customer referrals and word-of-mouth have become the largest influence on the purchase process, which means the funnel is broken.
Shifting to a flywheel model re-orientates your business objectives to align with customer needs. It means moving away from a linear model of customer engagement that focuses on that all important ‘first purchase’, to a long term focus on customer engagement and customer lifetime value.
“A flywheel is a collection of variables, levers and interactions. It is a hypothesis for driving sustainable business growth through virtuous loops” – Mallory Busch, Amplitude
How your flywheel supports product-led growth
A flywheel is all about the user experience and how the product itself and customer advocacy drives the growth.
Using the flywheel model can help your teams visualise the momentum you build a great product and customer experience, and identify any drag or setbacks early if your processes start to slow down growth.
Define your flywheel
Start small. Draft your flywheel by identifying the most basic, yet crucial functions that keep the flywheel spinning. After you define these key motions, you can add more inputs to the flywheel, such as smaller loops that spin off the larger flywheel.
