Discover more from Product State
Büşra Coşkuner on being product-led, PM frameworks, and Impactful OKRs
Product State Q&A
EC:What’s the difference between being product-led, and PLG?
BC: Product Led Growth is buzzing nowadays as a form of growing your product in users and revenue. At the same time, more and more companies undergo a new type of transformation to turn into a product organization. In this context you can hear the buzzword ‘becoming product-led.’
And then, you can watch how people use ‘Product Led Growth’ and ‘Product-led’ interchangeably… But these are two different concepts.
Product Led Growth (PLG):
PLG is a distribution channel and growth concept. It’s based on the strategy that the product is so good that it serves as the main driver of acquisition, activation and retention. Users experience the value of the product on their own and turn into paid customers because it helps them to achieve their desired outcome.
Being product-led is a way of working. This is based on some principles and can (doesn’t have to) also have an effect on the organizational setup. The mindset of being product-led is around seeing the product and the user’s and customer’s success through using your product as the aligning denominator across all teams to build a successful business. All team’s definition of building the right thing becomes the same: Building a product and features that create value for users AND business. I call this ‘Make business with products that customers love.’
In this working style, everybody is pulling in the same direction, aiming for the same goal, for the same outcomes.
This means principles such as:
From ship, to learn fast
From stakeholder focus, to user & customer focus
From output, to outcome
From project, to product
From silos, to collaboration
From random shots, to decisions based on insights
And practices like:
Customer-centric business approach (remember: ‘Make business with products that customers love!’)
User-centric product design
Get market feedback early and frequently
Use qualitative and quantitative data, insights and evidence to inform decisions
Be open to being wrong often
Think big, start small, and iterate
Measure success through outcomes, not outputs
Lead with having a vision, empowering the right people, and outcomes & guidelines
Being product-led and PLG should not be used interchangeably, as I wrote after a rant on LinkedIn here.
EC: How do you think about connecting business goals with user outcomes?
BC: Stop building products that customers love… Instead, start building businesses with products that customers love!
We know Martin Ericsson’s famous venn diagram of product management.
Based on this diagram, a product manager’s responsibility is to make sure that the product is usable, feasible and viable.
Based on IDEO’s definition of risks, a product needs to be desirable, feasible and viable.
Here’s how I define and explain these nuances, changing a bit of these official definitions that were set by big names, often seen as the standard:
A product needs to be
Desirable = Do users want to use and pay for it?
Viable = Can we make business with this? Do we have the right capabilities? Is it the right business model? In case users != customers, will customers want to pay the right amount for this?
Feasible: Can we build this tech wise? Can we run it operations wise? What do we need to run it systemically?
Usable: Can users use this? Is the usability not standing in the user’s way?
We need to make sure that the pieces make sense and are not out of context — and that they also work well together. The most important point is to make sure that everybody is aligned on what’s meant, in which context, and how it’s been applied.
Alignment and a common understanding is key in everything we do to follow the goal of building winning products that create user/customer and business impact.
Having said that, as product professionals we not only need to bring the user and customer view into the product experience. We also need to make sure that the product and its pieces we build are contributing to the business goals. There are multiple considerations that need to be taken into account.
What should the business model look like?
What are our business goals for this time horizon?
Can we make a business out of the product we are developing?
How much revenue do we expect to generate with this product change?
How can we select and prioritize only the features that are relevant to the business and the users/customers?
Some points just need practice, like good communication between business or product leadership and product teams to share the time horizon’s business goals, or writing business cases.
For other points there are some very useful guides or canvases, like the Business Model Canvas and the Lean Canvas for creating successful business models.
And for others — there are frameworks, techniques.
If you don’t know where to start, start with connecting business goals to your product outcomes and eventually to the products or features you’re building. This way you can bring in a strategic prioritization into your decision-making practices.
Here are 3 frameworks that help you do exactly that:
Maps business goal → actor
actors → actor outcomes
actor outcomes → outputs
outputs →stories, experiments and hypotheses
I like to use my adjusted version of the Impact Map that maps perfectly well to the Impact-Outcome-Output understanding in product analytics. It looks like this:
By the way, there’s a trick to the Impact Map. You can turn conversations about ideas / features requests into conversations about business goals by reverting the Impact Map. I call it ‘Reverse Impact Mapping.’
You break a business KPI down into its pieces to get leading indicators of big fat hard to move business lagging indicators. Best is to do this with the help of someone from the finance team because they know best how they calculate business numbers.
Then, you create a user journey map, add metrics to the steps in the journey, create metric-funnels and analyze numbers (if you have any or reliable ones), and then connect these to the KPI-Tree. Or, if you don’t have enough data, you create hypotheses on how the KPI-Tree continues as a product metrics tree. Then map ideas to the metrics in the tree and you know what you work on and what not.
Find the overarching guiding metric that reflects the product’s value to the users and is a leading indicator of revenue. Find the input metrics that lead to the NSM. You can break them further down but make sure to not go too deep down the tree because we want to work on features that create true impact on the NSM and eventually to our revenue targets. Map the ideas for product changes to the metrics that you’ve broken the NSM down to and prioritize those that you expect to have the biggest Impact on the NSM with a reasonable amount of work.
Also see John Cutler’s Miro Board.
These techniques help you to start or continue your product thought process from the perspective of ‘making business.’
EC: How do you derive OKRs with an Impact Map?
BC: There are two places on an Impact Map where you can find your OKRs: On the business goal level and on the actor outcome level.
On the business goal level, you can find your company level Objective and can use actor outcomes as Key Results.
On the actor outcome level, you can also find Objectives. There are two ways to do this:
Way 1: You see these outcomes rather as KRs and reverse-engineer them into Objectives by asking ‘When we improve these numbers, what will this have changed for the actor?,’ or by simply asking ‘Why?’ :)
Way 2: This is similar to way 1 but is going deeper down the outcome level.
Actor outcomes can be very broad, like ‘Make them buy more products.’ How? By making them add more products to cart? Or making them buy products more frequently? These are really very high level outcomes. So high level, that you could even create an own Impact Map for them! I mean it, you can do that. But you can also simply break these high level outcomes further down and build something that I call an ‘Outcome Cascade’ through asking ‘How.’
Now you can use the very top level outcome as an Objective and the lower ones as KRs. In our example, the Objective could be ‘Expand Product Sales’ and the KRs “Increase the number of items in cart from average 2 to average 3,’ ‘Increase add-to-cart conversion on PDPs by 10%,’ etc.
This way, instead of randomly thinking about how your team could potentially contribute to company OKRs by purely brainstorming what you want to offer, you can come up with OKRs that really pay into the company OKRs or business goals.
“Stop building products that customers love…
Instead, start building businesses with products that customers love!”
- Büşra Coşkuner
Thanks for reading Product State! Subscribe for free to receive new posts and support my work.