This is another mini series that I had posted on LinkedIn.
Background:
Maybe it’s my bubble but I see more and more people posting about Product Led Growth (PLG) since mid last year. Then, I started to see more people using the term “empowered teams” and “product vs. feature teams”, thanks to Marty Cagan writing more about these.
And then suddenly I saw people using the terms PLG and product led interchangeably.
In the beginning I thought “hm maybe this person simply doesn’t know that these terms mean different things.” Then I saw the next person. And the next person. And even highly senior professionals and coaches and consultants that I highly respect.
And this was the point when I thought “ok I have to say something about it”.
I wrote a little rant and a mini series. This is the collection of this rant and the mini series.
Since then my life has changed. I’m getting messages from people who thank me for clarifying this and support me and want to collaborate with me. I’m also getting messages from people who still argue with me “who has defined it to be this way”. Seriously, when is term “defined”? Only when someone famous writes about it? C’mon, this is industry jargon! We keep using “product thinking” and know what it means. “Sales led”, we know what it means. “Tech driven” we know what it means. But you have a problem with “product led”? I argue myself that when you introduce this way of working in a team, you shouldn’t use the term but instead explain the principles behind. But we in our community shouldn’t argue only because nobody has written a book about it yet.
Oh wait! Marty Cagan is actually doing that 😉 Though he’ll use the word “Product Model” if nothing changes. I don’t care if we then all replace “product led” with “the Product Model” as long as we know what we’re talking about. And as long as we know that it’s NOT the same as PLG!
I also received the question if there’s any company out there that works this way. Yes there are. I myself worked in product led and not product led companies and can describe you the difference first hand. Of course there’s no “perfect” product led companies, and of course there’s nothing like 100% empowerment and no management decisions at all, etc. (and just to mention, this scenario wouldn’t be “perfect” anyways, the management must make decisions and show the direction and can also come up with very well researched ideas, but that’s a topic that would go way too deep for this post). The implementation of product thinking principles is different from company to company. But the general principles stay the say.
Soooo…. Here are the LinkedIn posts with the link to the original post.
Enjoy, and as always: Let me know what you think.
“Product led” and “Product Led Growth” are not the same!
I keep reading this again and again, and I’m not the only one.
In our peer group of independent product coaches, it came up how many folks use these two terms interchangeably. And I see this happening all the time on LinkedIn as well.
Here’s the difference:
𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗹𝗲𝗱
Being a product led organization basically means that you’re using product thinking principles and practices to build your products.
This means principles and practices like for example:
🔸 customer centric business approach (building products and features that create value for customers and users AND the business)
🔸 user-centered product design
🔸 getting market feedback early and frequently
🔸 using evidence and data to inform decisions
🔸 being open to being wrong often
🔸 think big start small
🔸 measuring success by achieving outcomes instead of delivering outputs
🔸 leading by vision, empowerment and outcomes, not by command and control
🔸 …
You don’t have to check all of these to be product led but many of them.
This gets wrongly perceived as the product management team having the full authority to decide what gets built. That’s why for example Saeed Khan proposes to call this way of working rather “Market led” instead.
𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗟𝗲𝗱 𝗚𝗿𝗼𝘄𝘁𝗵 (𝗣𝗟𝗚)
PLG is one way to grow your product and revenue. The abstract thought is that the product provides enough value to convince users to pay for it. It still needs to combined with Sales Led Growth or Marketing Led Growth (some people would through tomatoes now) but is way cheaper than pure SLG or MLG.
This can have different forms but typically there is a free version/model of the product (freemium, trial, free vs. premium version, etc.) that the user has access to. The user can use it for free forever and build up their journey through the product based on their own increase of need. Or they have access for free (entirely or to a premium version) for a limited time and can test it in their own context.
And PLG lives from high retention. High retention is a sign of a highly valuable product.
If you want to learn more about PLG, you should follow Leah Tharin and Elena Verna if you’re not doing so already.
𝗠𝘆 𝗺𝗮𝗶𝗻 𝗽𝗼𝗶𝗻𝘁:
Both words “product led” and “Product Led Growth” are hyped at the moment. But for other reasons and in different contexts because they mean different things.
“product led” is the next step after “becoming agile” because companies understand now that 💩 in 💩 out but faster on the market is not the way to become more successful, but knowing what the right thing to build is the way to go.
PLG is a way of growing revenue that is based on the philosophy that the product delivers high value and does its job well.
𝗣𝗹𝗲𝗮𝘀𝗲 𝗱𝗼𝗻’𝘁 𝘂𝘀𝗲 𝘁𝗵𝗲𝘀𝗲 𝗶𝗻𝘁𝗲𝗿𝗰𝗵𝗮𝗻𝗴𝗲𝗮𝗯𝗹𝘆!
𝗧𝗵𝗲𝘆 𝗮𝗿𝗲 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲!
𝗧𝗵𝗮𝗻𝗸 𝘆𝗼𝘂!
This week’s little series: Product Led Teams.
“OMG she said teams, not organizations”
Yes because there’s a lot more to creating a whole product led organizations, and it heavily depends on the industry, market, way of working… Therefor my focus on PLT.
Let’s start with my point last week: PLG ≠ product led
𝗧𝗼𝗱𝗮𝘆’𝘀 𝘁𝗼𝗽𝗶𝗰 𝗳𝗿𝗼𝗺 𝘁𝗵𝗮𝘁 𝗹𝗶𝘀𝘁: “𝗚𝗲𝘁 𝗺𝗮𝗿𝗸𝗲𝘁 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸 𝗲𝗮𝗿𝗹𝘆 𝗮𝗻𝗱 𝗳𝗿𝗲𝗾𝘂𝗲𝗻𝘁𝗹𝘆”
There are 4 main dimensions to this:
1. 𝗖𝗼𝗱𝗲: Releasing small increments rather than big chunks of code. Production systems are NEVER exactly equal to test and staging environments. There’s always a risk that something does NOT work on production, like “the load balancers are not able to allocate the traffic in the right way so that we can’t upload the images correctly” (one of my “projects” that worked wonderfully on all test environments).
2. 𝗨𝗫/𝗨𝗜 𝗗𝗲𝘀𝗶𝗴𝗻: Test UI and UX before you build it. When you do a complete redesign, test parts of the design separately through prototypes or mockups. You can of course run usability tests but you can also use async testing platforms like Usabilityhub or Usertesting. Keep on testing your solution with actual users or on testing platforms to find opportunities for improvement.
3. 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀: Either you are externally funded or you are bootstrapping. In either case you have business goals. Create revenue, grow user base, reduce churn, etc. What you build needs to pay into the business goals and the company strategy. How can you know that it does if you only check impact on your KPIs at the end of the year? Test if the product or feature is moving business goals before you build it. But you don’t have to test everything. First, decide which assumptions are the riskiest that would kill your business tomorrow if you were wrong. Run experiments around these assumptions, testing the business impact of that change. Other assumptions are typically either reversible or actually well known basics in the market. Also get input from stakeholders and align how realistically can the solution can be sustainably run. Because business is part of your market.
4. 𝗖𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀: Similar to “Business”, you have customer goals. You want people to use the product (and pay for it). But again how can you know that what you’re building has customer impact if you check metric only at the end of the year? Find the riskiest assumptions that would kill your product if you were wrong and test the customer impact of your idea. Is this what customers want? Check early if you’re building the right thing.
Notice something about these four points?
Yes.
You address feasibility, usability, viability and value risks by simply getting feedback early and frequently so that you build the right thing the right way and launch it at the right time to the right market.
Product led ingredient: 𝗢𝘂𝘁𝗰𝗼𝗺𝗲 𝗺𝗶𝗻𝗱𝘀𝗲𝘁 aka “I don’t tell you what to build, I tell you what you should aim for.”
Well, not exactly “I tell you” but we’ll get there in a moment.
When we work in a top-down setup, we try to juggle feature expectations from management and internal stakeholders. They want to know “when feature x is going to be delivered”.
Sometimes they’ve done their research and really know why they want it. Many times – especially in a “project” setup – they want it because it was already planned…..1 or 3 years ago 😅
🙃 𝗡𝗢𝗧 𝗛𝗘𝗟𝗣𝗙𝗨𝗟 🙃
As a Product Led Team you rather want to focus on outcomes because this gives you the freedom to find beneficial features that will deliver results.
Finding implies searching, but searching through blindly poking in the dark won’t get you anywhere. Searching in order to achieve a specific goal however will help you dismiss, prioritize, and focus on opportunities and solutions.
There are two types of outcomes you need to consider:
👫 𝗖𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗢𝘂𝘁𝗰𝗼𝗺𝗲𝘀
Also called user outcomes or product outcomes. Doesn’t matter, it’s all the same: A behavior of your target group (user/customer -> depends; I’ll continue with customer). Here’s the link to an older blog article where I help you formulate better outcomes: https://www.busra.co/post/outcome-thinking-vs-output-thinking.
Your customer is the center of your attention. You want to make or help them to do something with or on your product = behave in a specific way.
But which behaviors are important?
👉 Your task is to find exactly those customer outcomes that pay into your business goals.
🏢 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗢𝘂𝘁𝗰𝗼𝗺𝗲𝘀
or business goals. Well, we could say that business goals are KPIs and business outcomes are rather a break down and formulated in a more tangible way. And this is correct. But in the end your work has to add to KPIs.
You can break down KPIs into business outcomes (for example using a KPI tree) and work from there but no need to overthink it. You don’t need a full tree in place to get started with connecting customer outcomes to business goals.
Methods like Impact Mapping, Goals Signals Metrics, Goals Questions Metrics, Pirate Metrics, and yes KPI or metrics trees can help you find correlating outcomes through a structured thought process.
The easiest way to getting started is using the 5 Whys in a way that build up this connection (see link in comment on deriving outcomes with 5 Whys).
𝗜𝗺𝗮𝗴𝗲𝘀 𝗯𝗲𝗹𝗼𝘄
In the images I show you how these connections could look like. Keep in mind that the exact way depends on your own context.
𝗥𝗲𝗮𝗹𝗶𝘁𝘆 𝗖𝗵𝗲𝗰𝗸
Are you working in an environment where your team is empowered to come up with outcomes? You’re probably getting them from your management and have to find features for them. This is still better than feature expectations.
For teams who still deliver feature, this might even be a starting point to change your management’s expectations 😉
Product led ingredient: 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗺𝗶𝗻𝗱𝘀𝗲𝘁 aka “Hmmm what happens when I pull on this loose thread?”
Learning mindset sounds like another no-brainer but this goes actually quite deep. Deep into team and even company culture. It’s more than the usual buzzwords like “Fail fast learn fast” “Break things early and often” “Build Measure Learn”.
Learning mindset is what actually turns the project-delivery-mindset upside down.
𝗜𝘁 𝗳𝗼𝗿𝗰𝗲𝘀 𝘆𝗼𝘂 𝘁𝗼…
🔸 explore the topic at hand and go on a discovery journey open to be wrong most of the time, instead of planning to deliver your next best idea.
🔸 see big harry changes and strategic initiatives as bets and figure out if you’re wrong (!) with your assumption. If not, then you’re on the right path.
🔸 take risks and try smaller ideas as well (ideally in a structured way) to see what happens and to see if you were wrong.
This journey can start with the basic Build-Measure-Learn cycle. Ideally start with what you want to learn. This will show you what you need to explore and what you need to measure. When you know that, you’ll find the solution that you need to build in order to measure what you want in order to learn what you wanted to learn. And then continue from there: BML, BML, BML, …
My favorite starting point for writing good hypotheses is Strategyzer‘s Test Cards (see image). Starting from there you can create a whole hypothesis driven learning flow (for another post) and enhance your documentation on this. Tanja Lau 🦋 recently shared her learning documentation template that I really like (see https://www.linkedin.com/posts/tanjalau_productmgmt-productstrategy-startup-activity-7036590889724452864-n2hV/).
𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝗖𝘂𝗹𝘁𝘂𝗿𝗲
But learning can only happen in a place where your team feels safe enough and motivated to trying things out, breaking things, and being late with releases, always with the aim to find a target group worth focusing on, opportunity worth pursuing, and/or solution worth building. This is what an empowered team does.
But if they don’t have the environment that encourages the team to actively seek learning, they’re not even going to try. Because they’re not willing to take risks.
👉 They won’t explore, they will only deliver.
👉 They won’t measure anything, because the only important measure is “shipping date”.
👉 They won’t experiment and test, they’ll only build what they’ve been told, even if it doesn’t deliver on customer outcomes or even business goals.
If you want to get away from a pure project mindset, give the product team the space to explore, test, break, fail, and learn. Help them get closer towards becoming product-led.
Strategyzer’s Test Card – A brilliant way to get started with writing good hypotheses and setting up experiment flows.
Product led ingredient: 𝗗𝗮𝘁𝗮 𝗶𝗻𝗳𝗼𝗿𝗺𝗲𝗱 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗺𝗮𝗸𝗶𝗻𝗴 aka “We’ll produce more mango ice cream than chocolate ice cream because bananas are delicious!”
Is this how you feel at work?
When decisions look like there’s only little logic behind and a lot of guesswork?
Let’s have a look.
Let’s assume this year’s goal is to sell more ice cream.
𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁’𝘀 𝘀𝘂𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗲 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗺𝗮𝗸𝗶𝗻𝗴
🔹 5 out of 5 management members have been on the Canary Islands.
🔹 When they think of bananas, 4 of them recall wonderful memories.
🔹 3 of them think of tropical islands and fruits in general when they think of bananas.
🔹 The variety of ice cream flavors they can offer is limited to vanilla, chocolate, strawberry, mango, banana, hazelnut and yogurt.
🔹 All of them find banana ice cream weird.
🔹 Next closest to a banana is mango (as in “a tropical fruit”). They vote and with a 3 out of 5 majority they decide to offer more mango ice cream.
🔹 They go to the product team and say “Produce more mango ice cream by summer.”
➡️ Will they sell more ice cream? Probably not.
Now, what happens when management comes to the product team and says “Find a way to achieve this year’s goal.”
𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝗮𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼𝗱𝘂𝗰𝘁 𝘁𝗲𝗮𝗺 𝗱𝗼𝗲𝘀
🔸 From the business goal they derive outcomes that they can work with, for example “We’ll excite our customer with our ice cream”.
🔸 They know that high season is in summer but sales start to take off in spring.
🔸 They do research and find out that this year everything around fashion and travel destinations tends to be tropical themed. The team has an idea to look deeper into mango and banana flavored ice cream.
🔸 They find out that there are only few ice cream vendors in the city that offer mango ice cream. And they’ve got bad reviews. Banana is not offered anywhere but their own banana ice cream has never been sold very well.
🔸 However sales of bananas have increased this year. Their intuition (yes!) says this is connected to the “tropical theme”.
🔸 Looking more into their own sales data and reviews, they notice that strawberries is their best and vanilla their second best ice cream. They also noticed that their mango ice cream got good reviews but it’s only 4 of 5 stars.
🔸 They decide on the following bet for the year in order to sell more ice cream and achieve some of their outcomes: Focus on mango ice cream.
Coherent actions:
1. Create a new ice cream cup with at least mango & vanilla
2. Make our mango ice cream’s taste mind blowing
3. Tropical themed shop
🔸 They run experiments and see good results for actions 1 and 2.
🔸 They roll out 1 and 2.
➡️ Result: They sell more because people come repeatedly for the mango ice cream and the cup.
And now they produce more mango ice cream than chocolate ice cream because bananas are delicious!
𝗡𝗼𝘄 𝘄𝗲’𝗿𝗲 𝘁𝗮𝗹𝗸𝗶𝗻𝗴 𝗱𝗮𝘁𝗮, 𝗲𝗵?
Data is input for ANY kind of decision
Why you should 𝗡𝗢𝗧 use the term “Product Led”.
“It sounds like outputism. We know how easy it is to fall in love with your own product.”
“But before you jump on new “cooler” terms and hope that renaming would fundamentally change the way you work, you should perhaps question whether you are not treating the symptoms and whether the basic problem lies somewhere else.”
“Product Led Growth is…” (PLG ≠ Product Led!!!)
“Why would you artificially tear apart responsibilities?”
“Why would you artificially give all the responsibility to the product department and let them tell everybody what to build?”
“So are we back with the myth that the Product Owner [or Manager] is the CEO of the product?”
As it is with many other words in the product world, saying “product led” causes lots of confusion. And in the worst case an aversion against good product practices only because we use the term “product led”.
And that’s exactly why you should generally avoid using this term, even if this is what you’re introducing. Better talk about outcomes and what success looks like.
_______
I’m very clear on what it means to be product led: https://lnkd.in/ehHgwqz6
𝗧𝗵𝗲 𝘂𝗹𝘁𝗶𝗺𝗮𝘁𝗲 𝗴𝗼𝗮𝗹 𝗶𝘀 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗳𝗼𝗰𝘂𝘀𝗲𝗱 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝘀 𝗼𝗿 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝘁𝗵𝗮𝘁 𝗱𝗿𝗶𝘃𝗲 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝘀𝘂𝗰𝗰𝗲𝘀𝘀.
If we break this down, it means building products and features…
1️⃣ not only by focusing on the customers, but also on the business. We can build many things that customers will love but if they DON’T support business success, there needs to be a very, very, very good reason to justify it.
2️⃣ not because we can or it’s easy to do, but because it creates value. And that is value for customers and business (see point 1).
3️⃣ that sell because they serve market needs and get frequently adapted to those.
By giving cross functional teams the possibility and accountability to find out what the market needs, what the real opportunity is, how a good solution to this could like, and make sure it’s aligned with business needs…
… through predictability through outcomes; adaptability through learning, feedback and systems that allow for fast and frequent releases; scalability through stable and adaptive systems…
… made possible by a safe to try and fail environment, motivated to become a learning team.
_______
This week I wrote about the feedback, outcome and learning mindset, and data informed decision making that are fundamental parts of being product led.
I hope you enjoyed it.
Let me know what you think.
✨✨✨✨✨✨✨✨✨✨
If you are a Product Leader oder Product Manager who wants to introduce product led principles in your team and need support….
Or if you’re a Product Manager and want to up-skill on product led principles aka product thinking principles….
Get in touch and let’s talk about how I can help you.
I offer team workshops, team trainings, individual trainings, 1:1 coaching as well as courses and various product thinking related topics.
