This week we focus on collaboration and teamwork. 

The most successful teams are those that think of themselves as a whole team - not as separate teams in an organization. How do you make that happen? How do you get everyone working together and not against each other? 

From solving problems as a group to putting out fires, here's how to do it with a slice of pizza in hand 🍕

⭐️ This week's top picks

[Read] Core Concept: Collaborative Decision-Making in a Product Trio

Do product trios really work? What do they do when they can’t agree? Who really gets to make the decisions? Product Leader Teresa Torres guides us through the product trio concept and how to make collaborative decisions in this blog post.

[Read] Why Groups Struggle to Solve Problems Together

There are five stages of problem-solving: defining the problem, generating solutions, evaluating solutions, picking a solution, and making a plan. When we solve problems independently, we intuitively move in between these stages to generate solutions quickly. But when solving as a group, people move through these differently. Al Pittampalli guides us through how to solve problems as a team.

[Read] 3 Signs Your Team Doesn’t Have an Ownership Mindset and What to Do About It

To cultivate an ownership mindset on your team, you should focus on transparency, autonomy, and customer empathy. A few tips from the Atlassian team to improve your team skills here!

[Video] 3 Ways to Create a Work Culture That Brings Out the Best in Employees | Chris White | TEDxAtlanta

Chris White leads the University of Michigan’s Center for Positive Organizations. Through ground-breaking research, educational programs, and organizational partnerships, the center helps leaders build high-performing organizations that bring out the best in people. This is a must-watch for improve team-wide communication and collaboration. Watch it here.

💬 Tweet of the week

Product Gurus via Linkedin

Ok, so this week, we don't actually have a Tweet, but a meme shared on Linkedin that's so funny it crosses language barriers. Who knew you could be funny on Linkedin too?

📘 Top product book

We couldn't pick just one book this week - after all, Summer is here!

Instead, we bring you a collection of books with a specific progression as marked by Nils Janse.

This curated list guides you through the top product management books, from Marty Cagan's Inspired to C.Todd Lombardo and Bruce McCarthy's Roadmaps Relaunched.

Happy Summer! ☀️

This week we focus on lessons learned and experienced gained.

Product is hard, we all know this. But from the tough experiences come lessons learned, some funny, some not so funny - but all truly valuable.

From grilled cheese to jewelry manufacturing, we've got it all for you on this roundup!

⭐️ This week's top picks

[Read] A Masterclass in Product Management - Selling Grilled Cheese

In an endearing and funny roundup of lessons learned, Wil Kirwan's compelling storytelling guides us through how selling grilled cheese taught him about product management. 🥪

[Read] How Writing Made Me A Better Product Owner

One of the most important skills product people must have is the ability to communicate clearly. If you have a great idea but you can't convey it to others, how do can make it happen? Maarten Dalmijn guides us through how constantly writing helped him be a better product owner. If you're wanting to brush up on some writing skills, this is the blog post you've been looking for.

[Read] Your First Thought Is Rarely Your Best Thought: Lessons on Thinking

Have you ever thought about scheduling time to think, not just to work? In this short article, Shane Parrish shares lessons learned after setting time to think, and how it has improved his problem-solving skills.

[Video] 5 Lessons Learned in Product Management by Twitch Sr. Product Manager

In this Product School session, Greg Smith, Senior Product Manager at Twitch, shares his own unique journey to product management spanning time in the film industry, an Apple Store, an international jewelry manufacturer, a wine bar, and playing video games. He discusses the various lessons he learned along the way and how he applies them to product management at Twitch. You can watch it here.

💬 Tweet of the week

keith kurson via Twitter

📘 Top product book

Our top pick for book of the week is Computing Calamities: Lessons Learned From Products, Projects, and Companies that Failed by Robert L. Glass.

The author presents 30 of the worst computer-industry failures of all time - and shows how you can prevent disaster from happening to you. This book is organized into six short sections, each featuring a collection of articles relating to a particular type of computer-industry disaster.

This week we focus on goals, metrics, and product thinking.

Building great products is about learning and iterating - but in order to learn, you need to measure the right things to make informed decisions. But where does one even begin?

From OKRs to building kitchens with the right outcomes in mind, we've got some great reads for you this week!

⭐️ This week's top picks

[Read] How to Measure The Progress of OKRs Using Leading and Lagging Indicators

The most useful goals help teams measure their progress continuously and adjust their actions accordingly. But neither of these will solely be achieved by being religious about "good" and "bad" OKRs. Check out this practical guide to setting up your OKRs by product coach Tim Herbig.

[Read] The Mindset That Kills Product Thinking

Jeff Patton talks us through how to recognize potential anti-patterns that kill creativity and hinder product thinking, with everyday, real-world examples like remodeling a kitchen.

[Read] How Engagement Metrics Can be Misleading

In most situations, tracking engagement metrics will be helpful. But in some cases, they can also be misleading. Oleg Yakubenkov guides us through how to recognize potentially misleading metrics and what you can do about them.

[Video] Why The Secret to Success Is Setting The Right Goals

In this practical talk, John Doerr shows us how we can get back on track with "Objectives and Key Results," or OKRs -- a goal-setting system that's been employed by the likes of Google, Intel, and Bono to set, and execute on audacious goals. Learn more about how setting the right goals can mean the difference between success and failure -- and how we can use OKRs to hold our leaders and ourselves accountable.

💬 Tweet of the week

Gtmhub | For Missions that Matter via Twitter

📘 Top product book

Our top pick for book of the week is Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results by Christina Wodtke.

How do you inspire a diverse team to work together, going all out in pursuit of a single, challenging goal? How do you get your team to commit to bold goals? How do you stay motivated despite setbacks and disappointments? And what do you do when it looks like you’re headed for failure? In Radical Focus, Christina Wodtke combines her hard-earned experience as an executive at Zynga, Linkedin, and many of Silicon Valley’s hottest companies to answer those questions. It’s not about to-do lists and accountability charts. It’s about creating a framework for regular check-ins, key results, and most of all, the beauty of a good fail – and how to take a temporary disaster and turn it into a future success.

This week we focus on psychological safety - yours, theirs, ours. The most important skill a product manager and leader can have is the ability to empathize with others, but developing that skill starts with taking care of ourselves first.

Empathy leads to designing great products - so let's start the conversation. Can one really build products that are inclusive if we aren't providing the same level of inclusion, accessibility, and safety to our teams?

If you don't know where to start, we've put together a great collection for you below.

⭐️ This week's top picks

[Read] EVERYONE NEEDS A COACH

Did you know that all high-performing individuals - from executives to athletes - all have a coach? Yet over 60% of people who are on the edges of leading-edge innovators are actually embarrassed to ask for help. Kate Leto and Barry O'Reilly guide us through how to break through the taboo of asking for help so you can take your career to the next level.

[Read] How One Company Got Employees to Speak Up and Ask for Help

A case study of how a quickly growing startup puts emphasis on their employees' psychological safety to drive innovation. As a leader, if you want to create an environment where it’s okay to ask for help, how can you show that even you need help from time to time?

[Read] Inclusive UX in an era of Anxiety

Considering the skyrocketing rates of mental illness throughout the course of the COVID-19 pandemic — plus many more of us struggling with daily stressors and mood swings that may lead us to irrational negative thinking, how can you design with empathy and accessibility in mind?

[VIDEO] POURing Over Your Website: An Introduction to Digital Accessibility

Digital accessibility - what it is and why it's important. Most sites/apps are awful as far as accessibility goes. It's not something that's taught, and even when there is some awareness, it's considered too hard and costly to implement. In this TEDx talk, Ashleigh Lodge raises visibility about why it's important from both social & business perspectives and provides information and tools for people to take back to their own project use.

💬 Tweet of the week

NHS D&G Patient Safety & Improvement Team via Twitter

This week we bring you some awesome reads around the importance of strategic product research, and why context always matters. From talking to customers to the most ridiculous user experience with peanut butter sandwiches - remember to always focus on what the user wants to achieve.

We wrap up our digest with how Notion took their growth to the next level by tapping into their existing user base and growing their community by 200 members daily (yeah, you read that right!)

Enjoy!

⭐️ This week's top picks

[Read] When's the last time you talked to your customer?

Product leader Adam Thomas tells us about the importance of speaking to your customers, developing relationships, and taking your strategic research to the next level.

[Read] Why you should stop putting features on a roadmap

Make sure your discovery process is problem-focused and not feature-focused by asking questions on the problem the user is having, not the solution you are building.

[Read] The making of a strategic designer

A beautiful design is not the same as a useful design. Read all about the new emerging role that's taking the product world by storm.

[Read] How to write better user stories with gherkins

User stories have been getting a really bad rep lately - spice them up with gherkins (no, not the pickle!) and help your team focus on user outcomes.

[Video] Why user stories with context matter

This hilarious video circulating Reddit hits the spot on user experience, and why user stories focused on outcomes are important. Watch it here.

💬 Tweet of the week

Ryan Kaufman via Twitter

📘 Top product book

Our top pick for book of the week is Product Research Rules by C.Todd Lombardo and Aras Bilgen.

Drawing from decades of experience in product development, the authors lay out nine simple rules that combine user research, market research, and product analytics to quickly discover insights and build products customers truly need.

• Recognize and avoid common research pitfalls

• Switch to the insight-making mindset that underlies all successful research efforts

• Find out how to look at data, formulate the right questions, and pick the right research method

• Learn interview techniques and research skills

• Analyze for insights collaboratively while avoiding bias

• Inspire action with your insights through powerful presentations and prototypes

• Learn how to involve a wide variety of stakeholders in research, from developers to executives

• Discover how you can make research a habit, not a one-off effort

Technical debt is one of the great sources of frustration among product teams and is mostly mismanaged.

Engineering teams hate bringing it up, and sweeping it under the rug leads to accumulation and long-term frustration. 

The culprit is the wrong notion of what tech debt is, its strategic role, and not knowing how to prioritize it.

Newsflash: Products don't win by having little or no technical debt. Keep reading to understand how to manage it strategically.

• Managing technical debt 

• Why scrum prevents and creates technical debt

• Choosing your north star metric(s) and how to create a product strategy

🗂 Managing technical debt

Matt Greenberg & Keya Patel via Reforge

You could think of technical debt as parts of your code that will slow you down in the long run. These could be hard-to-read, low-quality code, shortcuts, tangled dependencies, and temporary hacks that later become long-term pains.

Demystifying technical debt

Typically four main notions undermine the management of tech debt.

Technical debt is bad or burdensome

1) There are different types of tech debt, and their difficulty varies greatly. We cannot classify it all as bad, as this makes it all look the same. We need to organize it by type and estimate the degree of pain/risk.

 2) It's good to have a certain level of tech debt. This suggests that the team isn't focusing on removing it but focusing its efforts on key business areas like development or experimentation. Prioritizing technical debt over business is an indicator of growth problems. Your team will accumulate a bit of technical debt.

 Ask: What can we gain by accumulating tech debt now and tackling it in the upcoming month?

All technical debt is complex work

Many teams have an unaligned definition of done. When it comes to tech debt, you need to have a definition of done, or all tech debt will become complex work. 

Defined

• If your work has a clear start and end, the path to the end might be easy or hard, but there is a definition of what it means to complete it and how to get there.

• If you always define your tech debt, you can begin to understand how many days it would take to complete the work and account for it in upcoming sprints.

Undefined

• If your definition of done is unclear, it'll be harder to manage expectations right off the bat.

• If possible, move to a more defined approach by frontloading some of the work by scoping potential high-level solutions and considering how and when to make the fix.

• You can make it less complex by breaking it into small parts of complicated but feasible work and tackle said pieces over a defined period or sprints.

Ask: What assumptions are we making that could be challenged? How would I break this tech debt for someone who doesn't understand the complexities?

Tech debt is excluded from product work estimates

Product teams tie their work to business goals, metrics, or OKRs, but this is rarely the case with tech debt. This lack of clarity and separation from product work makes it hard to address it. But tackling it at the right time can be critical to the business growth and user experience.

• Even if some tech debt doesn't directly impact metrics, look to understand how it might impact user experiences in the long run.

• Set a time to validate that there's a common understanding between tech and business leads. This will enable the teams to find spots between experiments and builds to address tech debt and incorporate them into the upcoming sprints.

Individual pain is the same as organizational pain

Engineering or dev teams will often put forward pieces of tech debt that they find painful to deal with. They could struggle around QA, and their pain points might seem critical to them without considering the overall strategic context.

• Whenever a high-priority area of tech debt is raised, consider whether this is an individual or organizational level pain point. Will it impact the customer or business in some way in the short or long run?

Questions to begin prioritizing technical debt

Confidence - How high is the probability that this technical debt will cause a significant problem?

Time - How urgent is this problem? When will it become a problem?

Impact to User - How high is the impact of not tackling this piece of tech debt for the end-user? Will it result in a speed or quality issue that will hurt the user experience?

Sequence - Will this piece of tech debt block the team from reaching important milestones? If not, to what extent will it prevent the team from reaching said milestones?

Accumulated debt - How much technical debt has already been accumulated? Is it minimal or significant? 

You can begin to pair up these questions with the type of technical debt, whether it's acute or systemic debt, and the stage of your company's growth to work out how to tackle it strategically. Here's how to put the full framework together.

⭐️ This week's top picks

[Read] Why Scrum prevents and causes technical debt

As a follow-up to the management of technical debt above, we wanted to include a different lens. How teams work with technical debt on a daily basis and how to tackle each anti-pattern.

[Read & copy] Top 5 Notion templates for product managers

Most product teams use Notion for one reason or another. It's a great productivity tool and place to keep your daily work-life organized. From meeting notes to user research, wikis, and sprint retros, these are some templates you'll want to add to your workspace.

[Read] Choosing your north star metric

Here's a guide to help you choose your north star metric(s), based on a survey of current and past employees at over 40 of today’s most successful growth-stage companies. Whether it's revenue, growth, engagement growth (MAU, DAU), this guide could help you nail your north star metric.

[Listen] How to create a product strategy

Nacho details his experience as a CPO creating a product strategy, as well as the situations you'll be facing, the relationship with the overall business strategy, setting goals, time frames, and how the process differs between established products and products that are yet to be launched.

💬 Tweet of the week

Julie Zhuo via Twitter

What should you work on next, and how should you allocate resources?

You probably have RICE, WSFJ, or several frameworks in mind. These are great if you've already done discovery and you know you're working on the right problems.

So let's rewind - How do you know you're working on the right problems? And how do you align your team on the value and efforts they entail?

A shared understanding of your users' problem and how each problem relates to your product strategy is a good place to start.

Here's what we've got in store this week:

• Tackling the problem: A simple framework to align your team’s efforts

• How to break through the ceiling of product-led growth

• How people discover products and how stripe builds them

Managing the right problems and efforts

Tanner Elvidge via Intercom

Teams often misallocate efforts, focus, and resources on the wrong problems. The Intercom team has a way to focus on the correct problems while allocating the right amount of resources - providing a way to the right solutions with a simple framework.

A framework to focus efforts on the right problems

Not all problems and solutions are created equal. Therefore depending on the factors below and their rank from "low," "medium," "high," you'll be able to derive how much effort to invest and transition to exploring the right solutions.

Innovation: Before starting any project, you should categorize and rank how it will factor into your product strategy, business strategy, and execution levels. You'll ask:

• At a product strategy level - does the project require an innovative solution? What level of innovation?

• At an execution level - Will it contribute directly to differentiation or simply closing product gaps?

If the problem is tied to differentiation, innovation will be ranked as "high" and could evaluate high-level directions for solutions. On the other hand, if the project closes product gaps, innovation will be "low," and you'll want to consider existing or repurposed solutions instead of thinking of new approaches.

Investment: Should we spend a lot of time, resources and bring in external teams? Or do we want to solve it quickly without investing significant resources? This is a practical criterion, and its importance relative to other projects should be considered.

A few questions to ask before ranking:

• Can our team solve this on our own? No? Then investment will be higher.

• How will we prioritize it against other problems?

• Would you intend to spend more time solving this problem than others?

Urgency: How time-sensitive is it? Do we need to get it to the market as soon as possible, or can we spend a lot of time on it? Urgency can be determined by top-down problems like product launches, or they could come from a bottom-up perspective such as the problem impacting users significantly. This can be observed from NPS scores, feedback, churn patterns, and blocked sales.

Questions to ask before ranking:

• Is it crucial to the product strategy? Is it strategically important to solve this problem right now?

• How critical is it to a broader launch? Is the other launch dependent on it?

• Is this problem one that majorly impacts how customers use our product? Is it affecting a great pool of customers, or can is it a minor problem for them?

Urgency indicates how fast we should get the solution to our customers, and every project could appear to be of major urgency, but this is not always the case. Perhaps a project is of strategic importance, but there's a current solution that keeps customers satisfied.

There are many different cases and situations where the different factors will rule how you approach your problems and prioritize projects. If urgency is high and innovation low, speed is the important factor, for example

Discover how the factors work together and the different examples in this case study.

⭐️ This week's top picks

[Read] How to break through the ceiling in product-led growth

Product-led growth is often praised, but people rarely talk about the limitations and how to deal with them. This is a guide to understanding its limitations and building a complete GTM strategy, to leverage its full potential. It offers a playbook to build product-led growth into an integrated buying system.

[Read] How people discover new products

An easy read to understand the seven main channels through which people find and ultimately adopt products, with examples, suggestions, and advice as to which channel is right for each product.

[Read] Building products at Stripe

Stripe has been incredibly successful at capturing market share, and you might even be using it yourself. But how does an emerging market leader build products?  Here's an inside look into Stripe's product culture, how new products are shaped, and the role of design.

💬 Tweet of the week

Julie Zhuo via Twitter

How do you build a product that users love? And how do you scale it?

Alignment. The common denominator among great product teams that experience and maintain hypergrowth.

It holds your product strategy stack together and the earlier you adopt it, the more robust your decision-making process will become, as well as adding an agility layer.

Here's what we've got in store this week:

• How Miro scales product alignment

• Why customer onboarding is a vital part of your growth strategy

• How to write OKRs that don't suck

• Rituals of hypergrowth

🗂 How Miro scales product alignment

Via Farbod Saraf (Product lead at Miro)

We all know Miro and how it grew from 3M to 15M users in less than a year. One of its product leaders recently shared how they scale their product strategy, find alignment, frame problems, and even run meetings in this tell-all document.

Why does it matter?

Every company and product team deals with collaboration and alignment issues at some point, especially while experiencing growth. The product alignment approach guides opportunity and solution discovery and ensures widespread product collaboration and knowledge.

The product alignment document

Miro uses this single document to detail the results of product discovery and its impact, with three pillars associated with the stages of the document.

Opportunity/problem framing: Where it all starts. They identify a problem to solve or a new opportunity to seize. Then, the team investigates the problem to be solved, the audience, its importance and the why, success metrics, and competitive research (how are others solving this problem?). Here's where a few possible high-level directions start to be explored. Caution: It's important to stay broad to avoid going into implementation details to stay open to more solutions.

Solution framing: The team chooses a direction and starts working on solution discovery. Scope, key features, and stories, complexity are identified, designers provide key flows, a go-to-market plan is prepared, and engineering design docs are crafted. Their PMs facilitate the flow of collaboration and outline possible risks and dependencies.

Post-launch recap: After launch and implementation, the team assesses how successful they were in achieving the goals according to the success metrics set and the learnings to continue improving.

The meetings

They stress the importance of having the most relevant audience reviewing the document during their weekly meetings to challenge it and provide feedback. Each session focuses either on problem framing, solution framing, or post-launch. They validate opportunities against user needs and business feasibility, get feedback from leadership, and add relevant-only outside perspectives. The only four possible outcomes range from a complete agreement to not approved and points that need work.

Discover how to approach each of the pillars, the questions to be asked, how to structure the meetings, and the actual document for you to copy, right here.

⭐️ This week's top picks

[Watch] Why customer onboarding is crucial for your growth strategy

The first thing that comes to mind when we think about growth problems is getting leads to try it out. But a more important problem is when they actually get to the product, and they leave. Onboarding is one of the biggest weaknesses of most companies, and Casey is here to present ways to successfully tackle it.

[Read] Uber's crazy YOLO app rewrite, from the front seat

A truly riveting story that will have you on the edge of your seat. George gives an insider look at what it was like to re-write the whole Uber app in two months. He narrates how these two months of hell ended in success at the cost of numerous burnouts and team members quitting. 

[Read] How to write OKRs that don’t suck

Many teams fall into the trap of cookie-cutter OKRs that they follow and lose track of the inputs that actually matter. OKRs are a tool for strategy deployment. They must be relatable and understandable, and give the organization the information and tools to steer towards the desired outcomes. If this isn’t the case, then you should make adjustments.

💬 Tweet of the week

Shishir Mehrotra via Twitter

If you were a doctor, you wouldn't prescribe medicine to your patients without understanding their problems first.

The same should apply to product discovery.

Product teams gather long lists of ideas to tackle all sorts of problems, and these idea backlogs give a sense of what to work on next.

It's comforting, and it gives us a sense of direction, but at the end of the day, they only offer prescribed solutions that aren't connected to problems worth solving.

Keep reading to learn about the correct approach to product discovery.

• Kill your idea backlog

• How to create a product adoption strategy

• 50 questions product managers forget to ask

🗂 Kill the idea backlog

Via Tim Herbig

The concept of the idea backlog is inherently flawed, and it's time to drop it.

It's where we collect "great" ideas that never made it to the top of the ideation session, and they slowly become outdated or disconnected from problems worth solving, creating noise. But more importantly, they focus the conversation of what to tackle next, on solutions.

Idea backlogs discourage hard conversations

Management wants to add an idea to work on, so you agree to add it to the idea backlog instead of discussing it. It saves you the hard conversation then, but it'll work its way into prioritization or roadmapping discussions at some point.

So what should you do instead?

If you're currently maintaining an idea backlog, round up the team and inspect each idea, asking why we would want to pursue it.

Tim gives the example of an idea for a Reporting PDF Export.

• Why would you do this? So account managers can share results with clients faster.

• Why would we want to do this? So account managers consider us an excellent solution for working with their clients.

• Why would we want to do this? So we can increase revenue from agency markets that purchase our solution.

Continue until you get something measurable, and if you can't, you should avoid it.

The reasons listed above will be your rationale for your next prioritization or roadmapping meeting, and it will start the conversation of what to work on next with a goal instead of the solution.

The steps that will follow:

1. Start broadly thinking of new solutions that could help you achieve the goal, now that you know it's worth solving, and there's data to back it up.

2. If you can't support the goal with evidence, it shouldn't be prioritized.

Dive into the problem space with the mission briefing

Your boss or a stakeholder will come to you with specific features they want. Your job is to determine if these requests will actually fulfill the expectations of your users or if you'll end up justifying them with vanity metrics.

How will you do this?

Create collaborative alignment by using the mission briefing framework, which clarifies the pillars of your product discovery mission without going into feature details. The five levels are:

1. The Context

2. Strategic Fit of a Problem Space

3. The intent of the Product Team

4. Areas of Uncertainty

5. Boundaries to consider

To avoid group-think, get your team to individually outline each one of them to co-create the mission briefing and understand how to proceed. Here's an example.

Remember why you started

We run discovery to answer whether the problems we propose are worth solving, and if so, will the solutions be worth pursuing, not the other way round.

This is a concept designed to deliver value consistently, and if you'd like to understand it and how to deal with new feature ideas, and those "great" ideas proposed by stakeholders, you can read the full case study here.

⭐️ This week's top picks

[Read] Why the Spotify squads framework doesn't work for product teams

Explore the Spotify Squad framework was emulated by many teams but few were able to succeed at it. It's important to understand why and how Spotify incorporated it, the product development methods it helped with, but most importantly, why they abandoned it.

[Watch] Expert Q&A: How to create a product adoption strategy

Product-led highlights the importance of allowing your product to sell itself, and lots of great outputs to achieve that, from messaging to great onboarding, but how do you decide where to put your focus first? This is where your product adoption strategy kicks in - understanding how to best prioritize that strategy as a team.

[Read] 50 questions that product managers forget to ask

Product managers love to solve problems and get things done. This is great because it means pushing products forward, and solve complexities. The downside to this is that we often forget to ask some questions that are essential to remember but painfully easy to forget.

💬 Tweet of the week

Lenny Rachitsky via Twitter

Repeat after me: I own the backlog; the backlog does not own me.

Your backlog management is a reflection of how agile you are. Therefore, it should constantly be adapting to learnings to maximize value.

Experienced PMs and POs know how to sidestep the pitfalls and tackle the numerous scenarios where they could get buried to the neck with items.

Keep reading to learn more about keeping your backlog in check and outcome-based delivery:

• How to truly own your product backlog

• Deliver value with the Kano model

• Aligning your company around jobs-to-be-done and how to break into the mainstream market

🗂 How to own your product backlog

David Pereira via Serious Scrum

Your backlog items are an ordered list of what's needed to improve your product, and it should be in a constant state of change. If it grows too big, the chances are that it'll become stale.

When to kill items

If you ask stakeholders, they'll tell you that all their solutions are relevant, no matter how old. Outcome-driven teams and agile development are about learning and adapting to discoveries.

Here are a few situations when items become irrelevant:

1. Discoveries show that the item won't solve the problem it tried to solve.

2. It's no longer relevant due to a change in the direction of the product.

3. Another resolved issue partly or fully fixed it.

4. We will work on a solution that will solve the same problem in the future.

5. Your product's architecture shifts, and therefore the problem your solution is trying to solve becomes irrelevant.

The ancient backlog

Are you hoarding backlog items? A 200-item list can be a common occurrence among new POs inheriting backlogs, where some of the items are over a year old.

Time might have already been invested in them, but they only add noise. A three-month lifespan is a good rule of thumb. Ask yourself:

• How long is your backlog?

• How long are you keeping your items?

• When did you last delete an item?

The dumpster

Can you connect your backlog items to the goals you want to achieve? A feature wishlist where you dump all your stakeholder requests only clouds your vision and ability to focus on outcomes. Challenge items by asking:

• What problem is this item trying to solve?

• How does it help us to reach our product goals?

• Is it relevant to the release?

The recipe book

When you constantly update your backlog items to have all the details, so the developers focus only on implementation, it can become a recipe for subpar outcomes. It becomes a bottleneck for the PO because they have to keep up with the details, and it focuses on delivering features instead of value. Ask yourself:

• Are your backlog items too detailed?

• Are your items problem-oriented? If not, reconsider.

• How much time is item creation consuming?

Deliver value with the Kano model

Mathieu Dhondt via The full guide to the Kano 

If you'd like to go a step further and consider a list of solutions to work on for your next release and figure out what mix is the best in terms of user value, using Kano will help you deliver more efficiently.

Kano allows you to work out the right combination of:

• Minimum basic features that must be included.

• Performance features to start working or investing in.

• Which delight features will impress users the most.

To identify how satisfied or even delighted users will be with a product, we must consider the two dimensions (or plotted axes), satisfaction versus functionality. How will users react to the level of functionality of our features? How well have we implemented it, or how much of a particular feature will they get?

We've explained the Kano model before, and though it's among the best frameworks, there is a lot to understand about putting it into practice. That's why a great place to get examples and keep up with its best practices is the full guide to the Kano model.

⭐️ This week's top picks

[Read & copy] Crossing the chasm with the ‘target customer scenario’ canvas

This is a very helpful tool for product managers to segment markets when defining the product strategy and go-to-market strategy. The canvas forces us to incorporate customer-centric frameworks and see our product from the customer perspective and whether our product could potentially scale by becoming the owner of our niche. 

[Watch] Product is hard

An enlightening talk by Marty Cagan about the challenges and misconceptions product people face and how to face them. Grab some popcorn because this is a deep dive into the applications of lean and agile and topics like validating ideas vs. discovering solutions, risk management, planning vs. prototyping. Bookmark it!

[Listen] Aligning your company around JTBD

Bob Moesta is known for building the jobs-to-be-done framework. In this episode, he breaks down how JTBD comes from the idea that we hire products to help make progress, why context is so important, and how pricing comes down to positioning which is informed by the customer's job to be done.

💬 Tweet of the week

Julie Zhuo via Twitter

Product adoption is one of the least favorite topics for most product managers. 

It's mysterious and elusive for many, and sad for those who keep up with in-app analytics.

But it's a hidden treasure for those who understand how value and influence work together.

So here's a good starting point to start nailing product adoption:

• The power user pitfall - understanding the fine balance

• How to improve user engagement with the BJ Fogg behavior model

• Using triangulation to get better research results + Spotify's design sprint template

🚀 The power user pitfall

Anne Lewandowski, Fareed Mosavat, Bangaly Kaba via Reforge

Our power users...They increase our average customer value and decrease our cost of acquisition. And often end up killing our product.

As PMs, it's only natural to over-cater to those who love and use your product the most. But we fail to consider that they are outliers and not necessarily our most frequent users. So how do we prioritize the right user's needs and avoid failing our most worthy users? Understanding failure.

Failing your wider audience by focusing on your power users

It's simple. You're spending too much time building for your specific power users and failing to consider the needs of your larger audience.

Overcomplicating the product, cutting growth: Building a product for experts or overloading it with functionalities can make it too complex or too expensive for new or non-power users. This can drive segments away. E.g Canva taking over Photoshop's less savvy or price-sensitive users.

Discomforting the user ecosystem: When power users command the product in ways that bothers other users, the larger audience will leave. E.g Linkedin offering more products geared towards sales and recruiters. As inboxes become cluttered with unwanted messages, users become disengaged, reducing value.

Product market fit expansion opportunities missed: If power users take up all your resources, you will risk overlooking opportunities to cater to adjacent users. Letting competitors take over.

On the other hand, you can also neglect your power users...

Missing low-hanging fruits: Power users are also overlooked as they represent a small portion of the user base. This leads to missing high revenue opportunities and related product improvements.

Decline in power user experience: Focusing on making the product convenient for all users, can result in a decline or depreciation of aspects that power users value. E.g Dropbox's sunset of their Carousel features to focus on core offerings, had users switching to Google Photos and Drive.

What are the reasons behind the power user mistakes?

Relying on generic power user definitions: Looking at a histogram of your monthly usage, you'll likely identify your power users as those who spend the most active days. Why is this wrong? Being too focused on usage frequency might miss important power user types, and frequency could be too broad of an aspect, and you'd need to consider actions to pair it up with this frequency.

You are considering ONE power user: Thinking that your product has only one type of power user might be over-simplistic. You'll want to consider whether you can identify multiple ones and balance their needs. One power user will have a higher monetization impact, but another might increase the chances of product-market fit for a broader audience.

Ignoring secondary effects: It would be wrong only to consider direct actions taken by power users. They don't always make purchases or engage in a specific action. Many power users in content-driven social networks are not those who are constantly consuming. This fails to account for those whose content posting is most meaningful and drives readership; ultimately driving more value.

Blindly trusting growth math: Teams who use frameworks like ICE (Impact x Confidence x Effort) often fail to consider that the audience size is the key factor of the calculation. This can lead teams to focus on the largest audience, which could be new users or unqualified ones, and therefore neglect power users.

The main takeaway

A power user should be defined as an outlier in terms of their behavior and influence within your product ecosystem. But it's important to note that they are outliers of numerous types of influence and behavior, such as monetization, creation, feature engagement, audience growth, and costs.

Discover the full extent of the different combinations of influence and behavior, as well as a field guide of power user types and how they fit different products, right here 👈

⭐️ This week's top picks

[Read and copy] Spotify's remote design sprint Figma template

Design sprints should allow for flexibility and have the power to rally the team around problems. As we found out during the past year, there are many challenges that arise with remote teams. However, this is a great tool to have by your side to design the right vision. It includes the templates with an agenda, insight artifacts, lighting talk slides, problem framing, and prototypes. 

[Read] Improve user engagement with the BJ Fogg behavior model

This model is great when it comes to driving behavioral changes and product adoption for new users. It focuses on three elements that work together for the switch to happen - Motivation, ability, and prompt. This article provides a full tutorial on how to implement it.

[Read] Get better research results by using multiple UX methods

Using triangulation when doing research helps to see the problem from a different lens. Different research methods usually allow more reliable results that might have not been obvious at first.

💬 Tweet of the week

James Doman-Pipe via Twitter 

Your product delivers value to your customers. Value is an element that your customer wants. The question is, do you know what that is and how to unlock it?

If you have an outcome-focused product strategy in place, you're aware of the importance of having the right set of problems to solve on top of it.

Knowing how and what to prioritize is difficult. But what happens when we don't get it right the first time? What if the solution you worked on ends up having to be killed off a few months or years later? How do you justify having to do that?

Understanding your user's problems and delivering the right solutions is a continuous and non-linear process. Here are a few resources to go the extra mile:

• When and how to unship features, what most teams miss

• How to write a product problem outline (with a template)

• What is FTUX and how to write clear product specifications

🚢 When to unship features

Keya Patel, Casey Winters, Fareed Mosavat, Neil Rahilly via Reforge

What if product teams were applauded for killing features as they are for shipping them? Unshipping features can have as big of an impact on growth as adding features, but its counterintuitive nature makes it complex.

Simply put, it's hard to explain the impact of removing things. 

We don't always get it right; the market changes and our strategy changes. This leads to cannibalization, obsolescence, tech debt, underdelivering.

Below you'll get a summary of Reforge and Mixpanel's deep dive into all the aspects of unshipping features.

When should you unship? Any of these reasons make a good case.

Lack of strategic alignment: Your feature doesn't fit your company's strategic direction. E.g. Dropbox launching their 'carousel' photosharing feature.

Underdelivering: Feature isn't intuitive or has too many issues and lacking perceived value. E.g. Whatsapp's  'delete for everyone' only worked if all parties had the most recent version of the app.

Novelty and/or too niche: The feature sees diminishing returns due to natural short-term usage, or simply. engages with a very small pool of users. E.g. Slack's control screen sharing or Instagram event stickers.

Obsolescence and redundancy: No longer serves an important purpose for the user, or competes with a feature that solves the problem.

Incompatibility with your product: The feature worked for other products but not yours. Such as Facebook with avatars, imitating Snapchat.

Technical costs: Maintenance, performance, and operational costs are typically not included in company-level reporting.

What are the benefits?

Teams think of killing features as "what do we lose?" instead of "what can we gain?"

Here are some gains:

Retention will increase over time from users being focused on the core features instead of those that aren't served well, also increasing lead quality and decreasing acquisition costs.

Product's NPS increase as users are focused on the use case your product solves, removing any distractions, as well as an internal focus on feature quality.

Organic acquisition expands with referrals and word of mouth, helping to stick to messaging focused on a core set of features that truly matter.

Support tickets and pager alerts will decrease once removed from the code base, especially if it was a deprecated feature with bugs or increasing technical costs.

Why is it hard to kill features?

Removing features produces long term growth, and tech is focused on immediate revenue growth:

• Roadmaps are often focused on 'quick wins' that move metrics fast, and multi-month or yearly growth features take less priority.

• PMs are often required to show how every idea is tied to revenue and engagement.

• Avoidance of all the sunk costs related to the time, energy that went into the feature.

• Loss aversion overpowers the acquisition of comparable gains. Humans prefer to avoid a loss more than winning.

Discover how to counteract these pitfalls, a deep dive into the possible issues that can arise, and how Slack and Mixpanel overcame them in this case study.

⭐️ This week's top picks

[Read] How to write a product problem outline (with a template)

Here's a framework we can all get behind. It's an outcome-focused approach to understanding product problems and how to run discovery and experiments. It follows a structure that's easy for everyone to understand and presents the indispensable points in a concise way. 

[Watch] What is first-time UX (FTUX) and how can you get it right?

It's hard to get a first-time user experience right. How do you ensure higher adoption rates? After all, it makes sense to increase retention since acquiring customers is typically 5 times more expensive than retaining them. Here's how to ask the higher-level questions that are typically forgotten by companies and how to help your users unlock value.

[Watch and read] Owning and writing clear product specifications

Here's a blueprint for building new features, requirements, or products. Product specs should have all the key information to help the team build a valuable product. It doesn't create transparency but also outlines the decisions, edge cases, scope, and what the product will stand for. So keep this breakdown present!

💬 Tweet of the week

Lenny Rachitsky via Twitter

Just a reminder of why product managers are such valuable assets.

My advice to product teams who build things without understanding their users - Don't run before you can walk.

Understanding them leads to a growing customer base and finding product-market fit. It's a process that starts with the product team, not with marketing.

The great-idea graveyard is overpopulated partly because we are under the oversimplified impression that we either understand or don't understand our customer, rather than how well we understand them and their queries

It's hard...but understanding how to make an impact with the right product research and discovery, will take you a long way!

Here's a summary and resources to get it right :

• Problem stack ranking: How Stripe validates new product ideas

• How to shorten time-to-value with better user onboarding

• Creating a product discovery mindset and outcome-based personas

💡 Problem stack ranking to validate product ideas

Daniel Kyne via OpinionX

Most new product ideas fail to take off. PMs wait a few quarters to validate, then more features get built on top; they re-examine their GTM strategy because they talked to customers and they confirmed that it's the right product. The learning is repeated, and it fails yet again.

Customer problem stack ranking analyzes the importance of your ideas against each other in the eyes of the user. A data-driven way of indicating whether your idea truly solves a major pain point or just a minor concern.

Step 1: Define your question

CPSR is a survey, so you'll start by asking a broad question related to an activity, rather than a problem you're trying to solve. Using the example of a holiday booking app, you could ask, "What is the most frustrating part of booking a group holiday?"

Step 2: Mask your idea as a problem statement

Asking users about your idea often leads to overstated or understated vague opinions. You'll want to turn it into a problem statement in order to compare it to other problems that they face in terms of the 'activity of focus'.

You can have multiple problem statements to dive into different pain points your idea could solve and different buyer personas and words they might use to refer to your 'activity'.

Step 3: Identify indirect problem statements

Lay out different problem statements related to your activity of focus but unrelated to your idea. You can get them from open-ended questions or sourcing pain points from reviews/forums.

Step 4: Send your stack rank to your target audience

To identify true priorities, send the stack rank survey to your specific target audience. Sending it to a randomized pool will generate noisy data. Ask them to stack rank the problem statement and the other problems posed. Allow users to add their own problem statements to learn about new pain points and iterate.

Reach your audience: If you don't have a list of users, try Slack communities or forums with high involvement.

Step 5: Analyze priorities and results

Aggregate and sort the problem statements from highest to lowest to understand your original statement and value proposition compare to the problems your users face. The results help see the big picture from their perspective, as well as whether the vocabulary and idea you have are even on their radar.

Stripe product master Shreyas Doshi recently talked about it, and after trying it, Daniel Kyne explained it in-depth using the example of an app that makes it easier for a group booking their holiday to split the cost of accommodation and activities. Read it here!

⭐️ This week's top picks

[Webinar] Using Jobs to be Done to improve user onboarding

Ramli from Product Led will be digging deep into how you can use Jobs-To-Be-Done in your user onboarding strategy to improve activation and increase retention. You'll learn how to customize onboarding experiences at scale to match different users' "jobs", creating a series of "aha" moments and cross-discovery of other jobs to grow lifetime value.

[Read] How to shorten time-to-value with better user onboarding

If your onboarding has too many unnecessary steps, it'll likely result in abandonment. Your goal is to shorten the amount of time it takes a new customer to see the value of your product. This article gives a great breakdown of how to build the right process around it.

[Read] Product discovery is a mindset, not a process

What is the biggest problem for our users? Will they figure out how to use a possible solution? If so, how? Can we actually build this solution in a way that's profitable for our business? These are some of the questions product discovery answers, but tackling it is hard and confusing. This article brings clarity about the use cases and what not to do.

[Read] Outcome-focused personas — Meaningful personas for product management

Personas are a key part of the discovery and design process but are often neglected or forgotten at some point in the process of development. Since understanding them is a key pillar of problem-solving this article provides an outcome-driven view on how to re-think them and avoid mistakes.

💬 Tweet of the week

John Cutler via Twitter

Some food for thought.

In 2021 nearly every product team is data-driven. We are all somewhere in the spectrum. 

The thing is...running experiments, tracking user insights and metrics, or setting great outcome-based goals aren't enough for our product to be successful.

There needs to be a consistent connection between all these practices, our requirements, and where we stand in order to deliver (more) value.

Here are a few resources that will help you connect the dots:

• The importance of metrics maturity for evidence-driven teams.

• How to use the jobs-to-be-done framework + a template.

• How to get users, analyze interviews, and using a North star metric.

📈 Understanding metrics maturity

Emily Tate via Mind the Product

There are two common traits among businesses who transformed their business by using metrics correctly. They set a clear scope of outcomes and goals from the start, and consistently follow up with the results of what was built. They're evidence-driven teams. Most teams are not quite there but don't know it, or can't identify why so here's your cheat sheet to see where you stand.

Feature factories 🏭

Delivery-focused teams who prioritize producing outputs on time over everything. Roadmaps describe features to be built rather than value to be delivered. The budget holder is typically the gatekeeper to user insights, and 

The hurdles: Since goals are focused on delivering features on time (and budget), there's little room for questioning if the features delivered are achieving the desired outcome, and there's no time for testing or iterations. 

How to progress: Firstly, is there a decision stack in place? From there, you can start to dig into the problem to be solved with each feature request and alternatives to solving the problem. Once in place, you can start measuring results to iterate. 

Aimless explorers 🧭

'Build-measure-learn' is their mantra, and testing is their strength. Numbers and metrics are always part of the evidence presented, paired up with strong qualitative research. But it doesn't align with strong product goals.

The hurdles: They are moving the needle, but not of the numbers that actually matter. A lack of clear and solid product goals keeps the team moving in an unknown direction.

How to progress: Evaluating the goals to be achieved isn't intuitive. They need to be tied to specific improvements to gain a competitive advantage or dominate the opportunity space. Frameworks like Opportunity Solution Trees are a way to start.

Hopeful visionaries (a VC's nightmare) 🚀

Well-defined outcomes, goals, and business cases get them funding. They hypothesize and define features to achieve those goals. After launching they don't follow up on metrics, or whether if the original outcome is being delivered. Common in long-planning cycle environments with annual budget approvals.

The hurdles: 'Great visions' and promises with no follow-up don't incentivize change. As a PM it's hard to break the cycle, and it rarely drives product success.

How to progress: Create accountability from within by presenting metrics on everything built and how it contributes to the outcomes set. Place next to what was presented in the business case.

Evidence-driven teams 🔍

This is whom we strive to be. Outcome-focused and business goals drive our metrics, while also reflecting the value users get. Build-measure-learn is a constant while understanding that not every idea is a success, and failure is part of the discovery and validation processes.

Word of caution: Teams can lose sight of the bigger picture, as well as external factors such as unintended consequences.

If you want to dive into the details of how teams fit into the quadrants and how your team compares, you can read it all here.

⭐️ This week's top picks

[Read and copy] Build products that solve real problems with this JTBD framework

Ensuring that your user will find your product valuable takes work. Teams struggle to align on what really matters about their product, and other teams fail to get traction, no matter the lifecycle stage. The JTBD framework provides new insights about your audience, who they are, and their motivations. Here's a practical breakdown of how a Facebook Product Lead uses it, and how you can implement it, with examples. Copy the template here.

[Read] How to analyze user interviews

User feedback is a sensitive topic in most teams. It's laborious and involves uncertainty, but when done right, user interviews can provide valuable qualitative data. This article gives a detailed breakdown of how to code the data, organize it to interpret the right context, and ensure reliability.

[Watch] How to get users and grow

"If you build it they will come" is no longer applicable. Gustaf Alstromer (Product Lead at Airbnb) goes into strategies to grow your product's user base while also understanding the essentials - Measurement, experimentation, and product-market fit, using Facebook as an example.

💬 Tweet of the week

Alex Garcia via Twitter

There's an infatuation with the NSM. But don't let it deceive you. It's an output metric and lagging indicator. Understanding its relationship to input metrics and actions to be take, is key. I found this thread to be a great refresher👇

Bezos' final letter to Amazon shareholders on Thursday got me thinking...

How many teams are sitting in front of feature-idea wishlists that will never move the needle?

Is there a surefire way to connect our roadmap to a strategy that creates value?

We're all trying to find a way to build successful products, and we express this path with our roadmap.

This story-telling tool will give our stakeholders clarity on how projects fit, their impact on the user and business value, and how the product could develop.

So let's do just that. Understand how to clearly describe and reflect strategies with our roadmap.

Here's a deep dive into:

• Transforming project-based roadmaps into outcome-based.

• Applying Amazon's PR/FAQ process to our product methodologies.

• Core product management lessons for our daily dynamics.

Roadmaps: project vs outcome-based

via Gibson Biddle

The project-based roadmap...Reliable, but teams love to complain about it with its ever-changing priorities, and David Cancel, CEO of Drift, even deems them a lose-lose.

🚪Enter the outcome-based roadmap. A cousin of the project-based roadmap but fully focused on problem-solving while telling a story of how things could play out, and used to optimize your approach when paired with strategies, metrics, and tactics.

Here's how Netflix's fictional project-based roadmap transforms into outcome-based. 

The basics: Project-based

As a product leader at Netflix it's not only your job to delight customers in hard-to-copy and margin-increasing ways, but also to help your team understand your product strategy.

Start high-level

For Netflix, retention is the key metric that captures the job mentioned above, as it measures customer delight and margin through higher LTV. But it's hard to move the needle with this long-term metric.

Here's where proxy metrics come into the picture to measure the effectiveness of your hypotheses/strategies undertaken to improve your high-level metric. If these proxies move, over time retention will move. Otherwise, the hypothesis fails.

Proxy metrics & your quarterly roadmap

While the four-quarter roadmap isn't ideal, and it's a good approach if it's complete. It's complete if you have drawn up the strategies, their proxy metrics to measure their progress, and the identified tactics or projects. Here's an example:

Strategy → Metric → Tactics/projects

Watching experience → % customers who watch 40+ hours → Custom playback speed, shared viewing, lip-synch algorithms.

With these identified, your roadmap will reflect your larger strategies in a column, with the respective projects over the following quarters. Here's Gib's example.

Evolving to outcome-based

The challenge with the project-based roadmap is that it creates expectations around a specific schedule, even if the idea is to communicate how projects evolve and how things might play out.

The new format:

• The outcome-based roadmap uses the "Now, Next, Consider" format.

• Applies proxy metrics as leading indicators.

• Replaces the strategies column with "problems to be solved" expressed with user language.

You might be wondering which roadmap style to chose now. Find outcome-based examples and Gibson's full take on it here!

⭐️ This week's top picks

[Read] What we can apply to our product development methodologies from Amazon's PR/FAQ process

New product ideas at Amazon are assessed using the so-called PR/FAQ method. It starts with a press-release-like document (less than 6 pages) followed by an extensive 1-hour FAQ process that stress-tests the idea on all dimensions (financial, market, user value, technical feasibility). Why is it worth trying? Because most fail. That's right. The few that pass usually generate further questions that need to be answered, heavily increasing the odds of success.

[Download] Outcome-based roadmaps: Unleash the power of a shared vision and purpose tracking product metrics

Delivering the wrong feature faster will deliver no value. Also the fact that only 1 in 7 product features achieves any kind of measurable impact is chilling. That's why this is a good place to start learning how to put in place a strategy based on outcomes.

[Read] Nobody really owns product work (by Basecamp's Jonas Downey)

Part of understanding product culture and team dynamics is internalizing that when submitting code your work is forfeited the moment you commit it. It all becomes part of the bigger picture. The faster you internalize this, the more feature attachment issues and headaches you will avoid.

💬 Tweet of the week

John Cutler via Twitter

Refreshing actionable advice on product management processes, accountability, timing, among other aspects of everyday PM. My favorite: "Alignment is ephemeral and must be constantly supported"

Forcing alignment can trigger premature convergence

ToDo: Seek coherence over alignment. Continuously.

In case you haven't heard, Citi recently lost $500M due to a poorly designed UI.

And no, it's no April fools joke, nor clickbait. It's a cautionary tale.

Understanding the user and defining the right user stories and acceptance criteria for the development of the product are vital.

 Here's a deep dive into:

• Crafting a solid acceptance criteria for user stories.

• Actually connecting your product team with the user.

• Choosing the right product metrics and knowing when decisions don't require mathematical proof. 

🧾 Acceptance criteria for user stories

Uroosa Hippargi via Product Coalition

Lists. You go through school, work, and life, creating lists of requirements to avoid forgetting what matters. The same applies to developing a feature. It's called acceptance criteria, and it'll set the standard to ensure you build great user stories.

It defines what should be in the scope, and what shouldn't.

The problem

 Part of the success of product development is attributed to achieving goals. But projects typically fail because they aren't in sync with the business side. In other words, it all starts with clear communication and requirement planning, and this is also where the problems often begin.

The definition of done

Delivering the right functionality depends on how well the user story was planned. Acceptance criteria is what will detail the functionality expectations, and what 'completed' means in terms of requirements, removing ambiguity for your team and QA.

Writing your acceptance criteria

Collaboration. How, and when?

• Perspective: Ensure it's always written from the user's point of view.

• Who writes it: The product manager or product owner.

• Who reviews it: All criteria is to be reviewed by everyone and confirmed.

• When: It must be written BEFORE the PM/PO considers it ready for sprint planning.

Stakeholder-development team consensus.

• Stakeholders: Understand the outcome of each feature.

• Development team: Understand the expected behavior of the feature.

Keep it simple.

• Expressed with simple language. Clear and concise. Avoid 'and, but, or' usage.

• Include only functional and non-functional criteria. No unwanted details.

Make it testable.

Acceptance criteria form the basis of all user story testing. Each criterion must be testable and should have clearly defined success or fail benchmarks. It can only be defined as complete once every criterion has been tested and accepted.

Use a format that fits your needs.

• Scenario-oriented: 'Given, when, then' format mimics the user expectations.

• Rule-oriented: A checklist. In some cases, we are working with inner system-level functionalities that don't fit the GWT structure.

Get a full overview of how each of the examples works right here👈

⭐️ This week's top picks

[Read] Stop playing the telephone game

Just like setting an acceptance criteria, a key part of building products is to understand user problems. The problem is that most companies (maybe including yours?) have a conveyor belt approach where product teams get requirements from customer-facing teams. This needs to stop, along with product teams being the gatekeeper to discovery.

[Read] Choosing, refining, and tracking product metrics

A reason why great product teams often build products that fail to make an impact is that they don't select the right metrics to measure it. It's never one-size-fits-all, and your product team should be addressing questions about the value your user sees as well as for the overall business.

[Read] Great PMs let fires burn

A good product manager is a firefighter. A great product manager prioritizes and finds leverage to reduce destruction. A Facebook PM gives insights on how to tackle the role on a daily basis. "If you spend all your time extinguishing fires, you may miss critical opportunities to build your business. You’ll be all reaction and no action."

💬 Tweet of the week

Shreyas Doshi via Twitter

Product management is an art and a science. Great PMs understand that we build products for other humans. Follow this thread to avoid falling into the "data-driven" label pitfall.

Ask a product manager what makes for a good product strategy. You won't get two identical answers.

More often than not, product teams don't have a clear understanding of what (their) strategy is, and aren't fully aware of it.

It's easier to spot this when they struggle to prioritize product decisions. These difficulties are rarely an execution issue, but a strategy one. 

How can we prioritize decisions when there's no clear guidance on how to do it? 

To pinpoint and fix strategy issues, you need to have a complete product strategy stack that bridges company objectives and product delivery.

Here are some thoughts on:

• Building a complete strategy stack, spotting mistakes, and case studies.

• Airbnb's rapid response as a result of a strong mission. Google's vision framework.

• Setting the right goals, and how cross functional leaders converge.

📚 The product strategy stack

Ravi Mehta and Zainab Ghadiyali via Reforge

Strategy shouldn't be an ambiguous concept, it's a system formed by a stack of 5 components (company mission, company strategy, product strategy, product roadmap, product goals) building upon each other, and their unique relationships. Here's how the system works.

The most common mistakes:

Goals = Strategy

There isn't a universal definition for these terms, but organizations often fail to ensure that there's a common understanding. Strategy is a plan to achieve your goals. How will your team win? Your goal is what a win will look like.

• Goal: Increase revenue by 30%

• Strategy: Tap into new markets or underserved category.

Hitting goals = Fulfilling strategy

Achieving goals doesn't mean progressing on strategy. Focusing solely on goals leads to losing track of strategic progress.

• Goals: Could be defined in a vacuum or on wrong assumptions.

• Strategy: Is affected by external factors such as market conditions.

Product strategy = Company strategy

A commonly mistaken assumption by product leaders. It is central, but not the only driver. The company needs to align it to other functional strategies to gain traction and position the company.

Goals first, then define roadmaps

Thinking about our goals first and making the roadmap secondary, can be rarely pulled off correctly.

• Teams: Tend to do whatever it takes to hit short-term goals, sacrificing features that pair up, good UX, and even long-term progress for quick gains.

• Goals: Should emerge from a roadmap designed to deliver value to the user. This empowers teams to move from trial and error to customer-centric development.

Is your product strategy stack great, incomplete, or poor?

• Great stacks: Have a clear structure of components stacked in order: Mission, company strategy, product strategy, product roadmap, product goals.

• Incomplete stacks: Are missing a few components such as company or product strategy. This eventually leads to misaligned team priorities, resulting in products shipped with ambiguous strategic direction.

• Poor stacks: Missing components, but characterized by components being created in silos, and lacking connections. This results in difficulties setting goals, and reflects a lack of strategic understanding from managers.

You might be asking yourself, how does it all blend together into a tangible example. Here are Slack, Discord and Clubhouse's product strategy stacks.

⭐️ This week's top picks

[Listen] Airbnb's Brian Chesky on rapidly adapting to deliver value differently

An instructive never-heard-before account of the lessons learned after shrinking and navigating a crisis, re-thinking the product and working from a clear mission and the data collected until then, as well as using their S1 as a strategic roadmap.

[Swipe file] Google's building a shared vision framework

In case you're looking to brush up on the highest level of your product strategy stack, here's a 5 component framework to guide your team and develop concrete strategies and deliverables to achieve your mission.

[Event] Netflix's Product Strategy with Gibson Biddle (Former VP Product @ Netflix)

Join this talk on April 1st, where Gib discusses three frameworks to define your product strategy. He will actually show how to make them work while presenting a mock 2021 product strategy for Netflix. Last but not least, he'll use two current Netflix case studies to show the impact of strategy in day-to-day decision-making.

[Read] Goals for alignment, not bonuses

Goals are seen as guidance and purpose, and empowerment. But done wrong, they can easily separate your organization. The idea is to decentralize and empower teams. There are three areas that are key to doing so: Organizational design, the cascade of goals, and the need to empower with goals.

💬 Tweet of the week

Julie Zhuo via Twitter

Your company's success is highly driven by the quality of your product. The pressure is on, but being able to snap out of the silo mentality and align with cross-functional teams and their strategies will go the extra mile to position for market leadership.

A quick history lesson:

A hundred years ago a product pioneer found a different way to product-market fit.

When asked about it, he said: "If I had asked people what they wanted, they would have said faster horses."

Products were a bit different back then but the premise remained the same. 

There's no one way to connect value to your roadmap; there are many.

Each 'right way' to address a user problem will come with its own set of difficulties - the delicate equilibrium between value, feasibility, and viability.

So whether you're Henry Ford reinventing mobility, or iterating on an existing product, don't just listen to your customers and don't deliver solutions.

Understand problems, quality balances, and how to measure opportunities at each lifecycle stage. Below is a comprehensive way to do it.

🧁 Intercom's 5 roadmap ingredients and personal questions

via Des Traynor 

The basics say that a company's true goals are on the roadmap, but Intercom has 5 ingredients to scale the scope of their product.

New ideas: They're counterintuitive and almost asking you not to do them.

• Customers won't be asking for them.

• Data won't support them as they are unprecedented.

• Hard to make a case for, as they are likely to fail.

You can either innovate or you can predict performance, not both. Get ideas to exploration without going through an extreme rationalization process.

Product iterations: Using the cupcake principle. 

• Start small, establish a feedback loop, and scale it up.

• Every new feature brings its own roadmap. Ship, get feedback, repeat.

Customer problems: Find the root-cause of the problem.

• Customers have expertise in their problem.

• But they speak only in terms of pre-conceived solutions.

• Can't predict future behavior and tend to overstate or understate importance.

Improving quality: Understand the quality, importance, satisfaction, frequency tradeoffs.

• Quality: how well executed is it.

• Importance: how important in the workflow is it.

• Satisfaction: how happy are users with it currently.

• Frequency: how often do they use it.

🚨 Questions for you:

New ideas: What new ideas have you rationalized to death?

Product iterations: What features did you ship and never revisit?

Customer problems: What features did you ship without really considering the problem?

Improving quality: What features are under-used or under-adopted in your product? You can increase usage frequency or increase adoption.

Watch Des Traynor digging into Intercom's roadmapping practices here. 👈

🔭 Product discovery - Opportunity decision trees

Teresa Torres via Producttalk

If you're still stuck in the mindset of what feature to ship next, you might want to shift the question to "what is the most important opportunity we should pursue right now?". Opportunity decision trees provide a holistic approach to discovery.

What is it:  Similar to story mapping, it's a visual plan to reach a desired outcome. It follows a non-linear organization of ideation of opportunities and solutions through experimentation and gap identification. 

How does it work: 

1) Identify your outcome(s). Select one metric or OKR you'd like to improve. Make sure there's alignment or the whole exercise won't work.

2) Opportunities should emerge from generative research. Frame the needs and pain-points of your customers as opportunities. Dive deep into each opportunity. What did we learn about our customers and their problems?

3) Solutions can and should come from everywhere. BUT only consider solutions that help us deliver on one of our target opportunities. If they don’t align or connect to the tree, they should be deemed a distraction.

4) Experiment to evaluate and evolve your solutions. Test a single solution. Dedicate your experiments their own row on the tree, and test only the riskiest assumptions, not the whole solution.

PM gaps it solves:

1. We don't fully examine ideas before committing to them.

2. We don’t consider enough ideas.

3. We don’t multitrack in a systematic way.

4. Our solutions don’t connect to an opportunity or our desired outcome at all.

Discover how to set up an opportunity decision tree here.

⭐️ This week's top picks

[Read] What software/tools do you use most regularly to do user research?

In case your team is trying to do user research (hopefully the case), here's a full breakdown of what teams are using. From surveys to prototyping, there's a different one for each use-case. Just like a chef in the kitchen, always make sure you're using the right knife.

[Read] Speed is the killer feature

"I want slower products". Said no customer ever.

Speed is a key differentiator for products that control the market. A user will rarely tell you they want a faster product; it's expected. And somehow, teams continuously neglect this aspect and default to adding more features instead. This article outlines how to assess where speed is most important.

[Read] Designing the smallest possible thing

We all love finding actionable posts and this is one of them. It delves into designing with a continuous discovery mindset. This is how agile teams move from "design everything at once" to breaking things down into shippable chunks, finding how to deliver value in short sprints. 

💬 Tweet of the week

Lenny Rachitsky via Twitter

No matter how experienced you are, keeping a daily checklist like the one below will keep you on your toes. Copy the full list, and grab more inspiration from different PMs in this thread.

Last week we talked about the struggles of eCommerce PMs, but no matter what vertical you're in, fast improvement and scalable execution are always a struggle.

To some, it's a process of short steps and constant iteration, and for others, it involves judgment, some gut feeling ,and intuition, while constantly shipping big bets.

One thing's for sure: projects that entail 6-12 months of work are grueling, and failure is common. But then teams like Stripe come along, and prove it's all possible.

Building products that are consistently better and stand out from anything on the market is rare. Here are some insights on building frameworks to make it possible:

• Shipping big product bets, how great teams scale and deliver innovation

• How product analytics maturity feeds a product-led strategy

• Using data to build products your users want, and using dependencies

🎲 Shipping big product bets - Silicon Valley's dirtiest secret

Andy Johns  and Matt Greenberg via Reforge

One of the dirtiest secrets of most great product teams is that they still follow a waterfally system to consistently launch innovative products and initiatives. 

It serves as an argument against the overreliance on agile or lean processes. Short timelines and iterations are safe but prevent from shipping big bets consistently, and fosters a culture of uncertainty avoidance - inherent to innovative ideas.

Problems of new dimensions: Arise as the product gains traction and the company grows, such as channel saturation increasing CAC, diminished available target market, and need for larger absolute gains to maintain % growth, to name a few.

Strategies must evolve: The focus shifts from acquisition to engagement, but once the gains from engagement start decreasing, only meaningful innovation can overcome diminishing returns.

Scaling product delivery is messy: Uncertainty, risk manifest,misalignment and cannibalization will undermine your path from strategic idea to final outcome. So recognizing the signals of unscalable product execution is vital.

Building a specific system for large product bets is key to consistently ship innovative products, but since there isn't a one-size-fits-all, here's a detailed description of all the steps you'd need to create this system.

📈 How product analytics maturity feeds a product-led startup strategy

Hannah Maslar via OpenView 

How many times have you heard "we don't have enough reliable data"? 

Can you pinpoint your product's "aha moments"? What are the characteristics of your top users? Have you correctly identified user success factors and drop-off?

It's not just a common issue among startups. But it means "product analytics maturity is not a priority" and that you're potentially missing out on reducing time to value, and feedback loops responsive to your customer needs.

Gaining a crystal clear view on how your product creates value for different users is much more attainable than most think.

Wherever you are in your product analytics maturity, layering in a data-driven approach should become the foundation and accelerator of your product. Here's how to implement, and recognize the key indicators to progress at each stage.

⭐️ This week's top picks

[Watch] Making safe bets with good data: Build the products you know customers want

If the articles above weren't enough, here's a great real life example from Jaime DeLanghe (Slack). She'll take you along the journey of using customer insights throughout your data maturity process, and how to act during the different phases. 

[Watch] Dependencies - A 5 Minute Overview. Challenges | Mapping | Types

Most teams should have at least a few big bets on their roadmap. But in order to ship ambitious products and initiatives and scale, cross-functional teams need to be able to overcome challenges such as dependencies, timelines and plans. 

💬 Tweet of the week

Shreyas Doshi via Twitter

Don't you love it when generic-looking tweets come packed with hidden easter eggs? Should you build what users say they want? Should you not? What has a heavier weight, your growth pace, your learnings or your product's reliability? It's never a generic solution to problems or one single way to build the right product. Read the whole thread below👇

It makes no sense.

PMs spend countless hours trying to build the best version of their vision - researching, managing insights, prioritizing, only for the roadmap to fail its purpose. 

It's about where your product is, where you want it to be, and how you'll get there. Not a feature wishlist.

Today's digest is all about building a roadmap that enables great products. In case you need an update on product roadmap best practices, start reading here.

Scroll down for some expert takes on:

• How to approach the roadmap correctly.

• How vision and roadmaps align teams. Tackling the uncertainty of development cycle alignment, and re-prioritizing.

• PRD's with examples, learnings from silicon valley product group, and 25 years of product summed up.

😵 Modern-day problems require modern-day roadmaps

via Malte Scholz and Gibson Biddle

The basics:

Short-term focused and flexible: Any outcome-based roadmap is only as effective as the learning process behind it. Ideally, it should be ready to respond to strategic changes, and ongoing findings about your users. It's not a long-term features release plan. 

Visual communication tool: In the words of former Netflix CPO Gibson Biddle "Your roadmap is a story-telling device that details how things might play out over time". In other words, your vision is always present among your high-level initiatives.

Collaborative: Sounds basic, right? Your roadmap should NOT be created by a PM in a silo. PMs in empowered teams make decisions, but listen to the input of their cross-functional teams. 

How are you handling your roadmap and what questions do you have? Join the discussion on LinkedIn.👈

🔭 Staying true to your product vision

Read the full article on Built In

“Roadmaps can and should change, but the vision itself must remain consistent.”

The strategies to stick to the product vision vary, but the goal remains the same: Maintaining a constant evolution so that product you provide your customers, is the best one possible.

Vision simplified: 

• It's where you want your product to be in the future. Ensure everyone's onboard.

• Keep your roadmap high-level as a reminder of your vision.

• Milestones- You'll need short-term, and long term ones.

• It'll require you say "no".

• Always keep in mind the "why" behind your vision. Why did you create it?

🤝 How to align teams behind a product roadmap?

While changes in a product roadmap are bound to happen, the consequences of changing priorities mid-development will translate to lost time, and interrupted workflows, which can be crippling. That's why, team alignment from the start is non-negotiable. Especially with remote teams.

Development cycle alignment: "If a requirement is missed or a design task or development story gets booted to a later sprint, the roadmap can easily go awry. To mitigate this risk, a product owner should over-communicate progress and needs." Vinny Pizzimenti - Squarespace.

On re-prioritizing: "Regularly incorporate input from analytics, testing and customer feedback into feature-level adjustments. As product managers, it’s easy to assume that the rest of your team understands the decisions behind certain changes as well as you do. But building alignment around a roadmap in flux means taking the time to explain why priorities have changed." Narguess Noshirvani - Work and Co.

Find out how 26 tech product leaders are tackling these uncertainties, right here.

⭐️ This week's top picks

[Copy] Kevin Yien's product requirements document template (PM at Square)

Before committing to a product or initiative you'll want to define its value and purpose. If you can't tie your product goals to your requirements, those of your users, and how they'll interact into this short doc, you might want to reconsider.

File > Make a copy. You're welcome.

[Read] Product vs. Feature Teams by Marty Cagan

Marty Cagan breaks down the differences between outcome-driven product teams which are a rarity, and the great majority of teams in the feature team model, and how to break away from it.

[Watch] 20 Years of Product Management in 25 Minutes by Dave Wascha

2:30 Listen to customers (for user problems)

5:00 Don't listen to customers (for solutions)

6:23 Watch the competition (for customer research)

8:40 Don't watch the competition

💬 Tweet of the week

Emil Kabisch via Twitter

Emil is waging a war against traditional roadmaps, giving a startup PM's view on why they don't serve their purpose, and five alternatives that enable the roadmap to be used as part of a process that harnesses new opportunities as findings arise.