ACFrOgBMYKPpbWsXOMy2uCljMUqATcjcPt6ROkceyGtrGiYTfGrOpJKdpB2 n8KJbeVR 7n - mH5YTu0SsgCYBYiceAO8z32h 5JvrfCw0Q0wxJCLMvI0YTal2haSYaY

THE PATH TO
Product
Excellence
STORIES AND ADVICE FROM THE FIELD
productboard publication
Table of contents
Introduction5
Deep User Insight
How to find your customer’s story 9

by Hiten Shah, Co-Founder at FYI, Product Habits and Crazy Egg
Don’t think “solution” too early 15

by Alex Osterwalder, Co-Founder at Strategyzer
The problem with personas 19

by Nils Davis, Product Management Consultant and Author
Fall in love with the problem, not the solution 23

by Brian Crofts, Chief Product Officer at Pendo
Build trust by championing the user 27

by Lucas Cerdan, Senior Product Manager at Algolia
Clear Strategy
How to define your product strategy 32

by Dan Olsen, Product Management Consultant and Author
When you don’t know how to fix your product 39

by Braden Kowitz, Co-Founder and Product Designer at Range Labs
What you’re delivering as a product executive 44

by Kat Kennedy, Chief Product Officer at Degreed
Focus on your product by eliminating bad habits 49

by Alicia Dixon, Senior Product Manager at Hilton Worldwide
Be strategic about chasing new trends 54

by Daniel Elizalde, IoT Product Management Coach & Advisor
Answering tough questions with your product story 58

by John Cutler, Product Evangelist at Amplitude
Your product strategy needs an owner 63

by Tasha Drew, Product Manager at VMWare
Build momentum by focusing on traction 67

by Ash Maurya, Author of Running Lean, Scaling Lean, and Creator of Lean Canvas
Prioritize delight 73
by Scott Baldwin, Director Product Management at Thinkific
Coherent Roadmap
Focus your roadmaps on outcomes, not outputs 80

by Bruce McCarthy, Author, Speaker, Founder at Product Culture
Small teams build companies 85

by Jeetu Patel, Chief Product Officer at Box
Be bold, ship gradually! 91
by Kurt Heinrich, Product Manager at Shopify
Working remotely can make you a better product manager 97

by Courtney Machi, Director of Product at Toptal
Manage growth with initiatives and focus 102

by Roger Dudler, Founder & CTO at Frontify
Align your product roadmap to your company strategy 105

by C. Todd Lombardo, VP Product & Experience at Vempathy
How to make better decisions around your releases 110

by Rachel Wolan, VP of Product at Euclid
Doing product discovery with a remote team 115

by Tim Herbig, Product Leader and Author
Don’t let your roadmap work against you 121

by Joe Cotellese, Product Strategist and Coach
Contributor Biographies 128

Introduction
Imagine what it must have felt like for Steve Jobs to walk on stage
and announce the first iPhone to the world—the sense of pride,
accomplishment, and fulfillment he must have felt.
But it wasn’t just Steve. So many members of different teams

combined their unique skills, curiosity, and creativity to bring the
iPhone to life.
Together, they spent years studying the market to discover deep user
insights about what people really wanted from a smartphone. They
used those insights to deliver something so innovative that users
hadn’t even known to ask for it.
Together, they pursued a clear strategy to deliver a unique product

that played to Apple’s strength in creating simple experiences. This
strategy ensured that their loyal customers would buy the iPhone
over competing products, which often had more features.
Together, and most importantly, they rallied around a coherent

roadmap: a product vision and a set of objectives and outcomes.
5
This allowed everyone to coordinate and combine their skills and
creativity to create an amazing new product.
As a result, the teams at Apple launched something extraordinary—a

product that truly mattered, and continues to delight.
These three pillars of product excellence—deep user insight,

clear strategy, and coherent roadmap—are the foundation of every
successful product organization based on our research. We believe
that these are all within reach of every product manager who strives
to be a true product leader.
Product DEEP
USER INSIGHT
Excellence
M NT
CL ATE
AD RE
ST
AP
EA G
RO HE
R
R Y
CO
So how can you start your path to product excellence? Does your
team have the right tools, processes, and thinking not only to create
such a product but also to continuously deliver memorable product
experiences?
6
To provide some clarity, we asked over twenty product leaders to
offer their thoughts for this book. They each present their unique
perspective on what it takes to build amazing products and teams
based on their years of experience.
We’ve split this book into three sections: Deep User Insight, Clear
Strategy, and Coherent Roadmap. In Deep User Insight, you’ll read
about framing your conversations and interactions with customers
to go past the superficial and get deeper into their problems and
needs. Clear Strategy offers advice about focusing, connecting your
immediate tasks to your long-term goals and prioritizing customer
delight. Coherent Roadmap covers how to think about building and
aligning your teams and processes to execute your roadmaps. These
stories and advice will help you get on the path to product excellence.
We want to thank all of our contributors for graciously offering their

ideas and you, the readers, for taking the time check out this book.
By drawing inspiration from some of the best minds in our field,
we’ll all be better equipped to create truly excellent products!
Hubert Palan
7
SECTION 1
Deep User
Insight
How to find your
customer’s story
by Hiten Shah, Co-Founder at FYI, Product Habits and Crazy Egg
Crazy Egg gave me the product bug. It also was the beginning of a
strange, powerful revelation: that people don’t often understand what
really motivates them to do something. So as a product manager, if
you can figure out what your customer really needs to solve their
problems, then you’ll have an excellent product. I do this by using
story to seek out my customer’s emotional hotspots.
Deep User Insight 9

Realize there’s a difference between sentiment
and utility
Back when I began Crazy Egg, it was difficult to track how people
were actually using a website. Google Analytics was around, but
people weren’t actually using it.
Google wasn’t very visual and was hard for most users to understand.
People couldn’t read the charts or the tables of data. There were all
kinds of inaccuracies. Clicks were miscounted. If two links on a page
pointed to the same address, there was no way of knowing which
one was doing better. Optimization was a pain.
People didn’t talk about this deficiency, but we realized it existed

and decided to build something better. We created a heat map which
showed the hot and cold zones of a website and that became Crazy
Egg, our first successful product. What I realized then was that it
was all about figuring out what problems our potential customers
actually had, and solving them better than anyone else.
Using stories to understand why people make

decisions
These days I start off from the perspective: “Is it worth it?” “What is
it?” and “Why?”
Deep User Insight 10

“Is it worth it?” means I look for opportunities that have tailwind, “is
there some trend making this a growing problem or a market?” “Are
enough people willing to use or pay for this product?”
Then I start asking, “What is it?” meaning I start trying to define what
the problem actually is, without yet worrying about what it is that I’m
going to build.
You start with a really holistic view of things then you look for the
pain points. What are the most difficult problems people have or sets
of problems they have? I really try to spend as much time and energy
as possible on figuring this out. For a new product I’m working on
right now, I just completed 51 interviews in 7 days. To me, it’s the
most important part of the process. I’m looking for pain, looking at
what problems people say they have, and then I’m also looking for
stories (the “why”) that connect it all together.
“I want those moments when people were

motivated to start solving a problem and stopped.”
Stories translate into emotion. What motivates a person’s behavior?

What causes them to take action? I want to hear about failures and
how people solved them; I want those moments when people were
motivated to start solving a problem and stopped. Positive experiences
are important too. What was the precise moment that made someone

hit renew? Emotional stories hint at potential solutions or potential
tipping points in a user’s behavior. Discovering problems is great.
But understanding what motivates someone to do something is even
better.
Reviews of competing products are a great starting point. You look

for patterns, what are the things that bother people the most? What
do they love? What are they lukewarm about? At what point do people
become so frustrated that they actually switch products?
Interviews are a crucial next step. But you can’t just listen to people,
you have to listen actively. When you’ve heard about a problem, for
example, keep going; ask your clients how they solved their problems.
Get specifics. Most of them won’t have a specific solution. But if you
talk to 50 people and five have a workaround, and say three of those
five are using the same workaround, then you’ve got something much
more valuable than just “this feature doesn’t work.”
Again, this all goes back to emotion; you find those few people who
really invested their time and energy into a product (good or bad)
and pry out those significant nuggets of knowledge they’ve come up
with, or figure out what exactly they’re reacting to and why.
Turning 51 interviews into an MVP
With Crazy Egg, what was surprising was how many people said they

liked Google Analytics but weren’t using it. We realized after talking
to dozens of people and seeking out their emotional stories, that
Google Analytics wasn’t actually helping them improve their sites.
After the interviews, I spend my time analyzing. So those 51 interviews

I mentioned doing for my latest product turn into about 24 hours of
analysis: i.e., from 163 pages of interview notes to a single twenty-page
document. I don’t use hacks either; I don’t use machine learning or
tagging; I read like a human and try to find trends. What I’m looking
for are emotions, the emotional points, what makes people go ‘that
made my life easier’ or ‘I don’t care for that.’
“We were able to learn in a matter of days what

would have normally taken months to discover.”
After we’ve gathered all that information, we’ll put together a tiny
team and create a minimum viable product (MVP) that takes less than
7 days to create. In order to validate the solution to a set of problems
we discovered during interviews in the document space, we created
an MVP for FYI in 5 days. FYI lets you find your documents in 3 clicks
or less across all the document apps you use. The MVP connected to
G Suite, Dropbox, Box, and OneDrive and let you see search results
across all of those tools in one interface. We were able to learn in a
matter of days what would have normally taken months to discover.

With Crazy Egg, even though we hadn’t articulated our process
as succinctly as we do now, we took the time to research the risks
involved and interviewed potential users. But there was plenty more
we could have done: for example, we didn’t think about strategy and
made an early decision to get rid of our free plan, which helped in the
short-term with revenue but inevitably hurt our growth. Our process
now ensures we don’t make these key strategic mistakes.
Identify the problems, find the stories, and figure out how to elicit
the emotion so you can identify what matters and what doesn’t.
That’s what this process is really all about. It’s too easy to build lots
of features. You want to find what matters most and double down on
that. The big lesson here is that it’s critical for your product’s success
to learn as fast as you can about what pain people have and build
your product to solve that pain without any distractions.

Don’t think “solution”
too early
by Alex Osterwalder, Co-Founder at Strategyzer
72% of new products do not meet customer expectations, according

to global strategy and pricing consultants, Simon Kucher & Partners.
How could this be happening? We’re supposed to be better at customer
discovery these days—we know now that you have to actually get out
of the building talk to your customers, right? What’s going wrong?

Well, it turns out that we’re not always framing our discussions
correctly. Far too often, we’re thinking about the solution too quickly,
which is true whether you’re in a small startup or a larger enterprise.
To illustrate this, I always return to Harvard Business School Professor
Clay Christensen’s Milkshake Marketing.
Milkshakes can be more than a meal
Christensen describes how a fast food chain wanted to increase

milkshake sales and conducted focus group campaigns asking
potential customers what they would want in a new milkshake.
They changed the milkshake to match that feedback and guess what
happened? Nothing.
What went wrong here? They started with the “solution,” assuming
that making a change, such as to flavor, would increase sales.
Christensen’s team took a different approach. They stationed

observers in front of a restaurant and took meticulous notes on
every transaction. Nearly half of the shakes were sold early in the
morning. Buyers were almost always alone and almost always got
into their cars afterward. What Christensen’s team realized watching
this behavior was that these early morning milkshake buyers were
trying to find a way to get through their tedious commutes and enjoy
some satisfaction. Bagels were too dry, bananas were eaten too
quickly, but milkshakes hit just the right spot.

In this case, the fast food chain created marketing programs based
on this insight to increase sales, but the same process applies for
thinking about how to build your product.
Framing matters
A simple framework to think about framing your conversations with

customers is to think in terms of jobs, pains, and gains.
●● Jobs are what your customers need to accomplish, such as

specific tasks or needs they want to satisfy.
●● Pains are what your customers want to avoid, such as risk,

negative emotions, or costs.
●● Gains are positive outcomes your customers are hoping for, such
as functional utility, positive emotions, or even cost savings.
These translate to the following questions:
●● What are they trying to get done?
●● What are their biggest pains preventing them from getting that
job done?
●● What are the biggest gains they’re looking for after doing the job?

“Customers are the experts of their jobs, pains, and
gains, not the experts of the solution.”
In framing your conversations, it’s important to remember that

customers are the experts of their jobs, pains, and gains, not the
experts of the solution. In the fast food chain’s case, many of the
milkshake drinkers weren’t trying to satisfy their thirst for a tasty
beverage. That wasn’t the “job” they were trying to accomplish. They
were looking for relief from their pain of getting through a difficult
commute. By framing their approach and questions correctly,
Christensen’s team found a solution that created real impact.
You can learn more about jobs, pains, and gains in Value Proposition
Design.

The problem with
personas
by Nils Davis, Product Management Consultant and Author
Your goal is not to create a product—it’s to create customers, lots of

them.
Products are successful for one basic reason: they fulfill a need or
solve a problem better than the alternatives, a problem which people
will pay to solve, no exceptions. If your product does that—solves a

problem better than any of its alternatives, and people are willing to
pay for a solution to that problem, you’re probably going to be fine.
Because of our name—product manager—we naturally focus on our

products. But the fact is that none of the people we want to sell to care
about products. What they care about is whether or not someone can
solve their problems.
Problems and personas
The common theme in my work on product management is the

problem the prospect is suffering from—or the unrealized opportunity,
or unmet desire, or whatever it is.
The original idea behind the “persona” was to help people get away
from living in a solution space by ensuring we considered the
customer’s problem. But, the cart was put before the horse, and the
cause and effect relationship was lost. We lost focus on the problem.
Your prospect is not a person with characteristics. Your prospect is

a person with a problem. The characteristics of that person do not
matter, except insofar as they drive a particular type of problem. For
example, here are two people:
●● Soccer mom Pat has three kids and a minivan, she drives the kids
to practice after work, and often has to take afternoons off to do

Mom stuff. She lives in the suburbs.
●● Young gay man Stephen has a Mini and spends a lot of time at
work. He takes trips to the wine country with his husband on the
weekends. He has no kids so far and lives in the city.
They couldn’t sound more different in terms of demographics, right?
But they are both project managers in mid-size companies. They both
have dozens of projects they are involved in, and their respective
project management office teams have hundreds of projects.
“Your prospect is a person with a problem.”
At work, Pat and Stephen are basically the same people, facing the
same problems. Having a persona for each of them is not terribly
meaningful, except on the margins. Stephen might have a particular
problem with being made to feel stupid, while Pat’s biggest annoyance
is feeling like she’s wasting time or doing the same thing over and
over again.
They have the same problems—resource management is a giant

pain, reporting on the status of their projects is very frustrating,
having to go through the same steps each time when starting a new
project is tedious, and manually doing so many steps that should be
automated is draining.

You see that the problem is the fundamental unit for Pat and Stephen,
not their personas.
The throughline from market discovery to product development to

go-to-market is the problem we are solving for the market. If you
focus and align everyone around that, you’ll end up with better
results and better solutions.

Fall in love with the
problem, not the solution
by Brian Crofts, Chief Product Officer at Pendo
Show me a delightful, incredible product—something that inspires

fandom in its users, and I’ll show you something that solves a big,
hairy problem. Users talk about elegance, simplicity, and moments
of delight when advocating for a product, but if you dig down, you’ll
find their advocacy is primarily motivated by pain relief. If you’re
looking to build an incredible product, find an incredible problem

first.
Albert Einstein: “If I only had one hour to solve a problem, I’d spend
55 minutes defining the problem, and the remaining 5 solving it.”
Understanding the problem is the most important step in building
a product. Scott Cook from Intuit always told me, “fall in love with
the problem, not the solution.” There are lots of possible solutions to
any given problem, some of them will work and some of them won’t.
You can always work on solutions, but if you haven’t identified and
studied the problem, your product will be less valuable.
Great problems aren’t found in the office
Big problems induce empathy. They make us feel the customer’s

pain—to the point that we can’t help but start trying to fix it. Great
problems aren’t found sitting in the office. You have to get out.
Spend time in the field listening intently and observing customers.
You find a problem by witnessing people struggle or get frustrated.
In a business setting, pain can take a number of forms—wasting
time, too much anxiety and stress, manual or duplicate work. Look
for these clues.
“You find a problem by witnessing people struggle

or get frustrated.”

Don’t just go into the field alone. I bring my team members from
design and engineering. Big problems are incredibly motivating,
and I want the whole team to empathize with our customers. After
each visit, we debrief immediately. I’ll ask, “what surprised you?”
and “what pain did you see?” This is a great time to synthesize and
formulate insights. You’re ready to move from problem to solution
only when your team can clearly articulate the pain through customer
stories. If you can hear the emotion in their voices as they tell the
stories, you’re ready to start building.
The power of empathy
A few years ago when I was a product manager at Intuit, I took an

engineer named “John” with me to visit a customer. We wanted to
watch this customer run payroll, which was the product we were
working on at the time. During the visit, the customer showed us a
break in the process—a place where she had to create a workaround
to accommodate a bad workflow. It was obvious that this part of our
product was causing her real pain.
Without warning, John jumped up and walked out of her office. It

was awkward, but we continued the meeting. Afterwards, I texted
him, “where are you?” but I didn’t get a response. I finally found him
back at the office with headphones on, typing furiously. “Where did
you go, John?” I asked. “I can fix this,” he said without looking up, “I
can fix this.”

This is the power of empathy: it drives maniacal focus. John felt the
urgency to fix the problem because he had directly felt the customer’s
pain.
Use potential solutions to validate the

problem
Your solution approaches can help to validate the severity of the

problem. You can get a lot of valuable intelligence by launching stuff
before it’s ready. If I build a very basic solution to a big problem,
what measures will customers go to start using that solution—even if
at an early stage? If people are willing to invest time and money into
a solution, to work around usability issues and lack of functionality,
you know you’re tracking against something. This feedback is far
more valuable than what a customer would tell you on the phone or
in a survey.
As you build out solutions, keep the customer’s pain as your North
Star. You may have validated that you’re solving a significant problem,
but you’re likely still far from having a great product. Now is the time
to hone your solution through iteration. Work with your customers to
improve usability, and provide those moments of delight that they’ll
talk about. This is a continuous process—it’s not about creating
something beautiful, but constantly and incrementally reducing
user friction.

Build trust by
championing the user
by Lucas Cerdan, Senior Product Manager at Algolia
“How do you explain product management to a 5-year-old?” is a

recurring question on Quora. That’s an interesting question, but
sometimes it’s hard enough just to answer “How do you explain
product management to your colleague?”
I joined Algolia as their first product manager and quickly found

that the company was not only not very familiar with product
management, but also a bit resistant to it. I know that there are
probably a lot of other product managers who struggle with a similar
situation as well. Here’s how I got in and made enough of an impact
that we grew our product management team, including hiring our
first VP of Product.
Getting in the door
Algolia wasn’t hiring a product manager, but I was excited by

what they were doing, and I was determined to find a way into the
company. I found and talked directly to some of Algolia’s customers
to ask them about their experiences using the product. I recorded
these conversations, analyzed the user feedback, and created a set
of recommendations for how to change their product. I sent this
information along with my application. Fortunately, they were
excited by the work I had done and hired me!
So, I’m in the door and hitting the ground running as a product
manager right? Not exactly.
“Ok, but what do you manage?”
What I found when I started at Algolia was resistance to product

management. The company has a very engineering-led culture,

and many of the team members had poor experiences with product
management in the past. One of my colleagues asked me, “Ok you’re
a product manager, but what do you manage?” I knew then that I
would have to work to build trust.
Championing the user
The best way to build trust is to start showing value quickly, and I
decided to focus on what got me into the company in the first place:
the users. I found that we were getting NPS data, but no one took the
time to analyze it. I analyzed the NPS data and discovered a whole
set of answers to questions we had never answered, including what
the relationship was between a variety of metrics, such as support
resolution rate, churn, MRR, and NPS. I quickly created a framework
that allowed our teams to focus on what to build by eliminating
unnecessary initiatives based on what the data said our customers
wanted, and more importantly, didn’t want.
Based on the success of this initial framework, I kept digging into

this data to deliver new recommendations on what to build next, and
become the “NPS expert.”
To continue championing our users, I went beyond just the NPS data
and started interviewing users and even began bringing developers
on site. This led to even more data points to create recommendations
for our engineering team on what to build.

Be the guide, not the owner
It’s important to point out what I didn’t do. I didn’t declare myself
as the owner and decision-making authority for the product. I built
trust, not by saying what to do, but by empowering the team and
giving them the leverage to build meaningful features that customers
bought and praised. It’s all a team effort, and while you think that
a developer might be the best person to decide on how to build
Algolia, a product for developers, as a product manager, I brought
the customer and market information to help guide those decisions.
“I built trust, not by saying what to do, but by

empowering the team and giving them the leverage
to build meaningful features that customers bought
and praised.”
Over time, I expanded my role to include many of the other traditional

aspects of product management and made it an accepted and vital
part of Algolia, but I started it all by focusing on and championing
the user. I may not have the best Quora answer for “what is product
management,” but if you find yourself in a similar situation, I
recommend starting with your users!

SECTION 2
Clear
Strategy
How to define your
product strategy
by Dan Olsen, Product Management Consultant and Author
When Instagram first launched, there were already many photo

sharing mobile apps on the market. Yet Instagram quickly became the
top photo sharing app. Why was Instagram’s product so successful? I
want to share some important product strategy tools that answer this
question and can help you make your products more successful: The
Kano model and the Product Strategy Grid.
Clear Strategy 32
The Kano model
The Kano model, shown below, plots how fully a given customer
need is met on the horizontal axis and the resulting level of customer
satisfaction on the vertical axis. The horizontal axis ranges from
the need not being met at all on the left to the need being fully
met on the right. The vertical axis ranges from complete customer
dissatisfaction at the bottom to complete satisfaction at the top.
User satisfaction
DELIGHTER
wow
PERFORMANCE
more is better
Need Need
not met fully met
MUST HAVE
User dissatisfaction
The Kano model classifies customer needs into three relevant

categories: performance needs, must-have needs, and delighters.
With performance needs, more is better. As the need is more fully
met, the resulting customer satisfaction increases.
Clear Strategy 33
Must-have needs don’t create satisfaction by being met. Instead,
the need not being met causes customer dissatisfaction. Must-have
features are “table stakes” or “cost of entry”—boxes that must be
checked for customers to be satisfied with your product.
Delighters, or wow features, provide unexpected benefits that exceed

customer expectations, resulting in high customer satisfaction. The
absence of a delighter doesn’t cause any dissatisfaction because
customers aren’t expecting them.
The Product Strategy Grid
See the blank Product Strategy Grid template below that helps you
map your must-haves, performance benefits, and delighters against
your competition. In the first column, you list the benefits that are
relevant to your product category—one per row, grouped by type.
You want to include the relevant must-haves, performance benefits,
and delighters. You should have a column for each key competitor
and a column for your product.
Once you have established the benefits and competitors, you want to
go through each benefit row and score each of the competitors and
your own product. If you are assessing an existing product, you can
score it; if you are building a new product, you can list the scores
you plan to achieve. The entries for must-haves should be “Yes.” For
performance benefits, you should use whatever scale works best for
Clear Strategy 34
you; a scale of “High,” “Medium,” and “Low” usually works well. For
performance benefits that are amenable to numerical measurement,
you can use numbers for higher precision. Delighters are typically
unique, so just list each delighter on a separate row and then mark
“Yes” where applicable.
COMPETITOR A COMPETITOR B MY PRODUCT
MUST-HAVES
Must-have 1
Must-have 2
PERFORMANCE BENEFITS
Performance benefit 1
DELIGHTERS
Delighter 1
Delighter 2
See the example below of a completed Product Strategy Grid. I’ve

intentionally kept the benefits and competitors generic, so you can
envision a similar grid for your product. In this example, there are
two existing competitors for the new product you plan to build. All
three companies have “yes” for all the must-haves. Competitor A is
the best at Performance benefit 1, and Competitor B is the best at
Performance benefit 2. You plan to be the best at Performance benefit
Clear Strategy 35
3. Perhaps you have identified a new customer segment that values
Performance benefit 3 more than the others, or perhaps you have a
new technology that you expect to yield higher levels of satisfaction
with performance benefit 3. Competitor A has Delighter 1, and you
have your own idea for a different delighter, Delighter 2.
COMPETITOR A COMPETITOR B MY PRODUCT
MUST-HAVES
Must-have 1 Yes Yes Yes
Must-have 2 Yes Yes Yes
Performance benefit 1 High Low Medium
Performance benefit 2 Medium High Low
Performance benefit 3 Low Medium High
DELIGHTERS
Delighter 1 Yes
Delighter 2 Yes
Completing this grid helps you clearly articulate how your product
will be better than the competitors. What matters the most from this
exercise are your unique differentiators: the performance benefit(s)
where you plan to outperform your competitors and your unique
delighters. You don’t compete on must-haves. In our example, each
product’s unique differentiators are shown in bold.
Clear Strategy 36
Instagram’s Product Strategy Grid
Let’s look at a real-world example of a Product Strategy Grid. Why

did Instagram become the top photo sharing app? Let’s look through
the lens of the Product Strategy Grid. How did Instagram outperform
the other photo sharing apps? What unique delighters did their
app have? When I pose these questions in my workshops, the first
answer I usually hear is “filters.” Filters were a delighter feature that
delivered the benefit of “make my photos look good.” Instagram also
helped make your photos look good by forcing a square aspect ratio.
By requiring a square aspect ratio for photos, Instagram ensured
that everyone’s feed of photos looked good versus having portrait
orientation photos mixed in with landscape orientation photos,
which would have to be shrunk in size to fit in the feed. Finally, how
did Instagram outperform the other photo apps? Compared to the
other apps, uploading photos from the Instagram app seemed to be
much quicker. How did they do this? The main way they did this was
through a clever UX hack. After the user took a photo, all the other
apps required the user to tap the “Share” button before uploading
the photo. Instagram realized that users tap the “Share” button for a
high percentage of photos, so rather than wait for the user to tap the
“Share” button, the Instagram app automatically started uploading
the photo right away. By the time users tapped the “Share” button 1
to 3 seconds after taking their photo, the photo upload seemed that
much faster.
Let’s use these insights into Instagram to reverse engineer their
Clear Strategy 37
Product Strategy Grid. We have a column for other photo sharing
apps and a column for Instagram. For the must-have, we have “let
me share my photos.” For Instagram’s performance benefit, we have
“post my photos quickly.” And for Instagram’s delighter we have
“make my photos look good.” Understanding Instagram’s strong
unique differentiators helps explain why it quickly became the top
photo sharing app. In fact, Instagram’s original tagline was “Fast,
beautiful photo sharing.” This tagline is very powerful and manages
to convey their entire product strategy in just 4 words. The tagline
covers their must-have: photo sharing; how they outperform: fast;
and their delighter: beautiful photos.
OTHER PHOTO SHARING APPS INSTAGRAM
MUST-HAVES
Let me share my photos Yes Yes
Post my photos quickly Low High
DELIGHTERS
Make my photos look good No Yes
I encourage you to use the Kano model and the Product Strategy
Grid to ensure you have a clearly defined product strategy. You can
learn more about how you can replicate Instagram’s success using
the Kano model and the Product Strategy Grid in my book The Lean
Product Playbook.
Clear Strategy 38
When you don’t know
how to fix your product
by Braden Kowitz, Co-Founder and Product Designer at Range Labs
When you’re a product leader, people look to you for answers. Why
is the churn rate high? Why is feature X not being used? How do we
get revenue up? And most importantly, what are we going to do to fix
it all?
I hate it when I don’t have good answers to questions like this. It
Clear Strategy 39
touches a deep dark fear: maybe I’m not good at my job. As someone
trusted with product decisions, shouldn’t I have all the answers?
Aren’t people expecting me to have all the answers?
I know that’s crazy. Nobody has all the answers. But when I’m feeling
uncertain, it’s easy to put my guard up. Instead of saying “I don’t
know,” I’ll dismiss a question as not important. Worse, when I’m
uncertain, I may stop asking my own questions about what could be
better. This all just leads to worse product decisions.
Fortunately, I know I’m not alone. I’ve worked with dozens of startups
and seen product managers struggle with the same issues. They
might not share their deep dark fears with me, but the symptoms are
recognizable enough.
Product leaders with more assertive personalities tend to deal with

uncertainty by pretending they know everything. They’ll dictate
what to build, even though they don’t have a strong rationale or
supporting data. In the short term, this looks good by creating lots of
activity. But it often doesn’t end well. Poorly designed features don’t
have a good chance of working. And asking a team to build poorly
planned features erodes trust in leadership.
Other product leaders may go the opposite direction: they disengage

from decisions. This is my failure mode. When I’m uncertain, I’m
more likely to withdraw and let each team build whatever their heart
desires. This may foster experimentation, but it doesn’t create focus
Clear Strategy 40
and momentum. The product may improve, but it also becomes
fragmented and incoherent.
If you work with a product leader who’s exhibiting these behaviors,

please cut them some slack. It’s a hard job. What you observe as
arrogance or avoidance is more likely a way of dealing with feelings
of fear and uncertainty.
The good news for product leaders is that there is a path out of
uncertainty. I feel overwhelmed with uncertainty at least once a
year, so I’ve gotten somewhat good at getting myself out of the rut.
Here are the steps I take:
1. Breathe. You’re not alone.
Many of us have the mistaken notion that a great product leader is

some genius character who dictates solutions to the rest of the team.
It’s unfortunate that this archetype has captured our imagination
because it just doesn’t work. Dictators don’t make good decisions,
and no one likes working with them either. But what makes this
image of a product leader particularly harmful is that it suggests we
must have all the answers.
If you get caught up thinking this way, remember that you’re not alone.
You have a whole team that’s excited to solve product challenges with
you. It’s not your job to have the correct solution. It is your job to lead
Clear Strategy 41
the team to find a solution. That may seem like a minor distinction,
but it makes all the difference.
2. Face the problem, together.
My team collectively knows more about product problems than

I could ever know alone. So I start by talking to everyone I can:
Leadership, Sales, Customer Success, User Research, etc. I dive into
the analytics. I’ll even ask friends outside the company for advice.
Then I start making a big list of things that aren’t working well.
If you do this too, you’ll notice that people have very different views
of what the problem is, which can be frustrating at first. But try not
to think about these different viewpoints as sides of an argument.
Instead, it’s helpful to remember the parable of the blind men and the
elephant. One man thinks he’s touching a tree trunk, while another
thinks he’s holding a snake. Don’t get sucked into an argument about
whether to fix one problem or the other. At this point, only try to see
the elephant.
I like to group the problems I find into a few themes and share the
whole thing with my team. It might feel scary to admit what’s broken
but it can be a huge help. Showing teammates that you understand
what’s broken builds trust, and framing product challenges as
broader themes helps teammates suggest better solutions.
Clear Strategy 42
3. Imagine the future.
It’s totally okay if you don’t have a genius solution to the problems
you’ve gathered. More likely, you’ll be feeling in the dumps because
you’ve surfaced all the major flaws in your product.
It’s at this stage where I feel most overwhelmed. A dark voice in my

head nags, “Everything is broken! You’re screwed!”
I find my way out of this darkness by focusing on possibility. I’ll ask

myself, “If we solved this problem, what would that mean for this
company? It would be huge!” That’s the spark of light that kicks me
into a creative mindset where I can find my way forward.
• • •
By this point, I usually feel about a hundred times better. I’ve

remembered that there’s a whole team to support me, I’ve enlisted
teammates to help understand what’s broken, and I can imagine
several paths ahead.
So the next time you’re feeling stuck, don’t let your worst instincts
control you. Get some perspective, either with these steps or with
whatever works for you. It’s always okay to say, “I don’t know what we
should do next.” The sooner we get comfortable with that phrase, the
sooner we can get unstuck and on the road to a successful product.
Clear Strategy 43
What you’re delivering as
a product executive
by Kat Kennedy, Chief Product Officer at Degreed
Seven years ago, my CEO asked me if I was interested in moving from

my software development role into a product management role.
I was a little skeptical about it because I already loved what I was
doing, and to be perfectly honest, I wasn’t exactly sure what product
management was. In fact, I asked him, “what exactly do product
managers do and how many of them do you really need?”
Clear Strategy 44
Luckily, he was patient and explained his plan for both my growth
and how the company would scale. I took him up on his offer and
eventually became our Chief Product Officer. Seven years has flown
by!
• • •
I started my career at Degreed as a software developer and loved

seeing ideas come to life by shipping code. After I moved into
product management, I poured that same passion into delivering
value to users by shipping great products. Now, as our Chief Product
Officer, I get to effectively “ship” an organization. I’m still doing what
I’ve always loved—building, just not products. Instead, I’m building
teams, cross-functional relationships, and processes to make sure
that everyone is successful. Here are some important things I’ve
done to be a successful product executive.
Staying ahead
As an executive, you naturally work a lot with the CEO, other C-level
executives, and the board. What’s unique in these interactions is
that you need to be ahead of the conversations. Have answers to
questions that haven’t been asked yet and have solutions to problems
that haven’t been mentioned yet. Ultimately, leadership’s job is
to manage constraints. If you’re not continuously changing these
constraints or removing blockers, then something is wrong. When
Clear Strategy 45
someone tells you about a problem that you aren’t already acting on,
then it’s too late. You need to have a forward facing view of product
strategy that’s ahead of where everyone else is. Sometimes, it feels
like playing 3-dimensional chess.
“Have answers to questions that haven’t been asked

yet and have solutions to problems that haven’t
been mentioned yet.”
I stay ahead of everything with constant communication and make

sure that I have an in-depth awareness of the company both in the
low-level details and from a 30,000-foot view at all times. The process
is quite similar to product management where you do discovery and
market research to find insights and determine how to act on them.
As a product executive, you do the same work but with people and
processes. I communicate our strategy, our wins, and losses, and I
make sure I know the same information about other teams.
Connecting organizations
It’s essential to have a vision and plan for how your product
organization works with other teams. For example, my goal is to
make sure our product team is innovating instead of reacting, which
is why I make sure they work closely with the sales team to identify
Clear Strategy 46
issues before they become problems.
I built close, trusting relationships with our Chief Revenue Officer

and our Chief Customer Officer and spent a considerable amount
of time on the ground with our sales team. This created a model for
how our product managers should interact with sales on a regular
cadence and how to listen to feedback from them and then turn that
information into solutions that create value for our customers.
When working with other teams, make sure to prevent any kind of
“us vs. them” mentality, which can naturally happen when things
inevitably get tough. Be on the lookout for defensive attitudes, and
make sure to coach everyone on your team and other teams to give
everyone else the benefit of the doubt by highlighting that everyone is
working on the same goal of delivering value to users so the business
can thrive.
Interested in taking the leap?
Product management is a great job that prepares you for executive

leadership. In fact, product managers often become founders. But
often as startups evolve into more mature companies, their product
executives tend to be replaced by more seasoned veterans. I stayed
and continued to grow in my role by asking a simple question:
“If someone were to replace me, what would they do?”
Clear Strategy 47
I thought about that question every day and interviewed other
executives about what they thought. After getting a sense of the
different answers and seeing our company continue to grow, I started
doing those things, some of which I describe above. My advice to
anyone interested in taking a leadership role is to look for problems
to solve internally. As an executive, that’s your primary job.
Clear Strategy 48
Focus on your product by
eliminating bad habits
by Alicia Dixon, Senior Product Manager at Hilton Worldwide
Closed the deal, but lost the customer
At a company where I once worked, a top sales person pushed me to

deliver a feature to close a deal. I disagreed with the feature based
on its complexity but after some back and forth, the executive team
Clear Strategy 49
said to deliver a scaled back version. Sales closed the deal and all was
well. Except not really. The customer was unhappy with what was
delivered and my team and I spent months trying to make it work
for them. Ultimately, they left us and signed with another vendor. It
was a painful lesson, but a valuable experience that reminds me to
be more assertive when I need to be.
A lot of product managers have had that meeting with an executive

where somewhere in the conversation the executive says, “I have
a few ideas for the product.” She then proceeds to tell you about a
personal experience she had using your product, followed by a
detailed ‘recommendation’ of how to update the product to improve
her experience. Her ideas are OK, but not great, and more importantly,
they deviate from your product strategy.
‘Following orders’ is just one example of a bad habit that product

managers tend to pick up once they have worked in the field for
a while. Some other bad habits include, but are not limited to,
minimizing time with your customers, making decisions without
the relevant data, focusing more time on tactical tasks rather than
strategic initiatives, and not keeping your skills updated. Whatever
the bad habit, they all have the same consequence of disrupting your
goal of delivering a great product experience.
Clear Strategy 50
How to stay engaged and focused
When you spend most of your day battling problems, it will eventually
take a toll on you. However, if you aren’t working to stave off bad
habits, they may creep up on you, and once they set in, they become
harder to stop. The key to making sure that bad habits never set in is
to actively keep learning and growing so that you never get stagnant.
So here are some thoughts on what you can do to keep bad habits at
bay.
Find a time management method. Learn how to plan your time to

make room for the things that are important. Once you find a method
that works for you, stick to it. I took the Franklin Covey course, where
you create a “to do’s” list and assign them a priority as well as an
urgency. It helps me focus through the noise.
Learn one new skill every quarter. One of the best ways to keep
fresh is to expose yourself to new ideas or concepts. My current team
is in the midst of adopting OKR’s, so I challenged myself to learn how
to be a better goal setter. I read books on goal setting, watched Lynda
sessions, and drafted personal goals for silly things, such as taking
the stairs every day for a week, to practice doing it.
Choose a different product. Domain expertise is wonderful, but if

you stay working on the same product for too long, you could stall
out. Moving to a new set of challenges can bring a new sense of vigor
to keep you engaged. You can stay at the same company by finding a
Clear Strategy 51
new product. When to change varies for everyone, but have a sense
of when it is time for a change.
Write. Keep a journal of your work challenges along with ideas to

overcome them. Consider publishing your thoughts in a blog.
“Focusing on teaching a junior product person how

to hone her craft can help you grow as well.”
Get or be a mentor. Focusing on teaching a junior product person

how to hone her craft can help you grow as well. Sometimes it is
easier to be objective with another person than with yourself. I once
laughed at the idea of mentoring someone because I always thought I
needed mentoring, but it helped me build my confidence and critical
thinking skills. While you’re at it, reach out to someone more senior
to mentor you.
Establish a network of product folks. Build a circle of peers you can

talk to get feedback and check in with them regularly about what’s
going on with their products. I created a network by attending a
variety of conferences, which leads to my last point...
Attend at least one product conference a year. Getting out of the

office and spending a day or two with other product professionals
exposes you to best practices and trends that you may not have been
Clear Strategy 52
aware of otherwise. I’m a huge fan of ProductCamp and if you ever
find yourself at one of their events, be sure to say hi!
Stay focused
The above list is just a few suggestions for how to eliminate the bad
habits that settle in when you’ve been doing product for a while.
These tactics have worked for my friends and me, and by no means
are they the only things you can do. Overall, the key is to make sure
to stay fresh by challenging your mind and continuing to grow. If you
do that, you can focus on the work of continuously delivering a great
product experience.
Clear Strategy 53
Be strategic about
chasing new trends
by Daniel Elizalde, IoT Product Management Coach & Advisor
As product managers, we find ourselves in eternal conflict trying

to balance the needs of our customers today, while keeping an eye
on the future to stay competitive and avoid becoming obsolete. It
is a tough balance, but that’s what is required to achieve product
excellence.
Clear Strategy 54
We live in a time where technological wonders abound, and there
is always a newer technology just around the corner. Alluring new
trends like artificial intelligence, blockchain, and the Internet of
Things (IoT) promise to be the solutions to all of our problems.
So how should product teams approach this paradox of looking to

the future while still focusing on launching robust products today?
In this era of rapidly evolving trends, companies need a strategy for

how to analyze them and how to decide when—if ever—they should
be embraced. A successful strategy for evaluating technology trends
includes the following:
Focus on value
Customers don’t care about the latest technology trends.
It is important to recognize that technology trends by themselves

don’t add any value. Customers are not interested in simply buying
technology. Instead, they are looking for a solution to a problem,
regardless of how that solution is implemented.
Technology trends such as AI, blockchain, or the Internet of Things,

don’t provide value on their own. They are only a tool that can help us
find a better, cheaper, faster solution to the problems our customers
are facing.
Clear Strategy 55
The key is to understand the core value of the new technology trend
and determine if it can help us provide a better solution for our
customers.
For example, let’s say your product targets transportation companies

and you’ve identified that their most significant pain is the high cost
of fuel. How can you leverage IoT or AI to provide a better solution?
At its core, IoT enables you to add sensors to collect data around
your customer’s environment. If you had that data, what additional
value could you provide? Artificial intelligence, at its core, consists
of analyzing large amounts of data to find patterns and anomalies or
to predict behavior. If you had access to that analysis, how could you
improve your product?
Notice how your product is not more valuable just because it uses
IoT, AI, or whatever technology trend you are evaluating. It only
becomes more valuable when the technology becomes a tool to
implement a more innovative solution and solve your customer’s
pains.
Is your company ready to adopt this trend?
Identifying that a specific trend can propel your product forward

does not yet justify action. Your company must also be equipped to
carry the product through its complete lifecycle.
Clear Strategy 56
If your company has a software background, they might not be
prepared to roll out IoT solutions that require hardware, field
services, networking, etc. It is our responsibility as product leaders
to stretch the capabilities of our organization, but only to the extent
that it makes sense. We are aiming to set our company up for success.
Is the technology trend ready to be

productized?
The final step of the strategy is to determine whether the particular

trend is ready to be deployed at scale. This is where product
leaders need to create clear boundaries between the technology
we can immediately adopt for current products, the feasibility of
implementing other technology trends, and the research efforts
we can sponsor that will help propel future growth. For example,
blockchain might have a lot of promise in the future, but it might not
be ready for you to include in your next release today.
Launching successful products requires a delicate balance between

understanding our customer’s needs, the capabilities of our company,
and state of the art technology. If we jump too soon on any trend,
we risk an accelerated failure. If we wait too long, we might see the
competition pass us by at lightning speed.
Clear Strategy 57
Answering tough
questions with your
product story
by John Cutler, Product Evangelist at Amplitude
First, a short assignment
Do this. Go to your ticket system, whether its JIRA, Trello, Asana,
Clear Strategy 58
or even a physical board. Pick a random in-progress ticket (or card,
story, task, etc.) that has no parent. Now, try to connect that ticket to
a big company goal. Here’s a format you can use:
“We’re working on this ticket to accomplish [the mission of that ticket]

to help us achieve [some higher level mission], which will help us achieve
[some even higher level mission], which will help us achieve [some even
higher level mission]…”
Keep going until you hit a meaningful 12-18 month company goal,
such as “decrease churn by 20% in FY2019.” You may even track the
ticket to multiple goals.
So, how’d you do? As a product manager, we’re often asked, “why are
we even doing this task, where are we going?” Or we’re asked, “what
are we doing to achieve this goal?” While we’re good at articulating
both the high-level plan and the details of the immediate tasks, it
can be challenging to walk the path between those two sides of the
spectrum to give compelling answers to those questions.
Create your story with a mind map
Great product managers can answer those two common questions

by telling a complete story that connects the immediate work tasks
to the broader company goals and vice versa. They can also start at
any part of the path and go in either direction.
Clear Strategy 59
A helpful way to build these stories is to use a mind mapping exercise.
Below is an example mind map for a 12-18 month company goal to
reduce churn by 20% in FY2019.
Decrease churn by 20%
BECAUSE WHILE / WITHOUT BY
We know Churn We assume Churned Improving coaching

Without Lowering
impacts short term customers would satisfaction scores
pricing
cost of revenue have high LTV (3.5 -> 4.5)
BECAUSE WHILE / WITHOUT BY
Without adding
We know Customers We assume High
headcount to Creating online
with high scores satisfaction CAUSES
Customer Success scheduling system
churn less often lower churn rates
team
BECAUSE BY
We know There is Integrating

no additional Appointment
budget Scheduler Service
By connects a problem or a goal to a solution and gives us the “how”

of our story. In our example, we plan to decrease churn by increasing
coaching session satisfaction by creating online scheduling.
Because tells us why we are doing that solution and gives us the “why”
of our story. This also ties what we know and what we assume into
our story. So, we’re improving satisfaction scores because we know
that customers with higher scores churn less often. It’s important
Clear Strategy 60
to delineate between what we know and what we assume because
it’s possible, in our example, that coaching session quality does not
affect churn rate and our team should further investigate that.
While and Without give us the constraints of our story. For example,
we need to improve coaching satisfaction scores without adding
headcount to Customer Success. As we did above, we can also give
the reason for each constraint, for example, by saying we can’t add
head account because we know there is no budget.
Ideally, you should have a map that connects each of your immediate
tasks (tasks that you may accomplish in the next week or two) to your
12-18 month company goals. While this is a simplified example, your
map could very well go many levels deep.
Create your map together
Here are some tips to get you and your team to build the mind map.
●● Limit the time to 30 minutes, which is the maximum time a team

can effectively “play” without taking a break.
●● Display the words by, because, we know, we assume, while/

without up on the wall, so they become second nature.
●● Have one person volunteer to drive the mind mapping process.
●● Move through the map methodically and focus on each box at a
Clear Strategy 61
time.
●● As a warm-up, consider applying the process to something

completely unrelated to work, such as picking a lunch spot.
●● Don’t go beyond 12-18 month company goals.
●● Challenge because we know whenever possible and do not take

any assumptions for granted.
●● Consider a turn-based approach to give minority viewpoints

representation.
Clear Strategy 62
Your product strategy
needs an owner
by Tasha Drew, Product Manager at VMWare
More products, more questions
At a previous company where I worked, we had a keen ability to

read the technology tea leaves. We took pride in always being able
to predict our customers’ problems and then deliver data center
Clear Strategy 63
automation tools that solved them. We built and released several
products to help our customers based on various use cases, such as
infrastructure automation and application analytics. However, over
time, we found that the different decisions behind each product
impacted our ability to innovate. Should Product A be open-sourced
or proprietary? Should we bundle Product B with another service or
should we make it free? Hey, is Product D competing with us? We
had a product strategy, but it was hard to interpret answers to those
questions and to see how to connect our products to that strategy.
The product I managed was our “NextGen” product, which we built

in response to the many rapid disruptions happening in the cloud-
native technology space. I found myself asking the same questions
and wondered how other people were answering them. In fact, I was
sure others in my company viewed me as a competitor. I needed a
way to navigate this to make my product successful.
Centralizing and owning the product strategy
We initially developed NextGen as a standalone team and worked

to make it the most compelling application automation platform on
the market. However, I encountered obstacles in getting some of the
more veteran members of the company to work on it, and in getting
it integrated into the core product to help monetize it. I found that I
was not the only person with this issue, so I coordinated with other
product managers to work with leadership to think about how we
Clear Strategy 64
could re-organize ourselves to make sure our product portfolio was
working more cohesively.
We eventually split the organization into Application, Compliance, and

Infrastructure teams. Each team was responsible for integrating their
products into a new common platform. This worked much better,
because each team had in-depth knowledge of their area of expertise,
had a close relationship with customer development partners, and
had similar resources for marketing and visibility.
More importantly, we assigned a single owner for the product strategy

for the common platform. The owner oversaw key features, such
as reporting, access management, and high availability, to ensure
that each team could ship a premium experience. Additionally, this
platform allowed enterprise customers to easily enable demos, trials,
and additional products—including my product.
Meeting the needs of an expanding market
Establishing an empowered platform owner—someone who could

bargain with top executives to make needed cross-functional work
happen—allowed us to stay ahead of customer needs again. We had
someone to help answer the tough questions, and we had a rigorous
process to ensure our products aligned to the overall product vision.
While at times daunting, this rigor helped us deliver a better product
experience. While our core product addressed our main customer—
Clear Strategy 65
the system administrator—each product manager could address
their specific customers, such as application developers and security
engineers. This allowed us to move quickly to meet the needs of an
expanding market.
In this expanding market, I now had the resources and budget to

go outside of the building to do rapid prototyping with key accounts
and to hire engineers who deeply understood the technology space
we were entering. Our resulting product felt natural and behaved
the way users expected. Meanwhile, tough decisions about where
and how to land key monetization features became dramatically
easier when I had a common platform to target. This led to a more
coordinated, seamless premium product because we weren’t
shipping our company’s internal divisions with our user experience.
Clear Strategy 66
Build momentum by
focusing on traction
by Ash Maurya, Author of Running Lean, Scaling Lean, and Creator
of Lean Canvas
Focus on traction, not growth
People don’t like to waste their time. If you want someone to focus
his or her time and effort on your idea, you need to validate that idea
Clear Strategy 67
by demonstrating that there’s a problem to be solved and that your
approach to solving it has a chance at succeeding.
We product managers and entrepreneurs are in the business of

persuading our stakeholders to invest time into an idea. Even if *you*
are your only stakeholder, your time is valuable. The same holds for
rallying a team. Their time is at stake. Too many product managers
and entrepreneurs think about growth above all else, but when you’re
trying to create a new market or a solution that doesn’t exist yet, it’s
better to look for traction, especially early on.
Traction is the rate at which a product (or business model) captures

monetizable value from its customers. Getting traction involves
building a process: focus efforts in the right direction by defining
metrics accurately and honestly. Then use LEAN sprints (fast breaks
of testing an idea, building it, measuring it, analyzing the results,
and taking action). Remember the goal isn’t just growth, as growth
can quickly sputter out.
Avoid success theater
The paradigm for startups has changed. Building a product is much

easier and cheaper than it used to be. What is much more difficult
to achieve is a functioning business model. Ultimately you’re not
building a product. You’re building a process.
Clear Strategy 68
Get your team working in the right direction, and they’ll help you get
there. Waste their time, and they’ll bleed you of time and resources.
So before committing to an idea and spending what can amount

to years of labor on it, mitigate the risk of failure by regularly and
systematically challenging ideas—and by being scrupulously honest
about the results. So instead of pitching and defending ideas, we
should concentrate on building traction.
“If you aren’t building traction, your team is

floundering.”
If traction is going up and to the right, the model is working. Otherwise,

it’s not. If you aren’t building traction, your team is floundering.
Time, our one irreplaceable asset, must be respected. Most product

managers get this backwards. Rather than test an idea before plunging
resources into it, they build the idea before they begin testing it. This
is success theatre. Detached from reality and ignoring the wisdom of
your co-workers: you are, in essence, mapping the journey before it’s
even begun, and leading your team toward a black hole by building
a product no one wants.
Clear Strategy 69
Dump the plan and just experiment
If you aren’t reacting to metrics based on real results, you’re wasting

time and losing the opportunity to test ideas with your customers,
making it harder and harder to succeed. Detach yourselves from “the
plan.” Gaining traction instead consists of incorporating customer
feedback and testing ideas. Your business model is your real product.
“Your business model is your real product.”
When your team is reacting to reality, when they are working on real
problems that users have and coming up with real solutions for those
users rather than just mimicking an abstract model of what ought to
be going on—they’ll be focused building what matters.
A simple way to think about it is as a journey. Ask yourself where

specifically are you taking your customers? (What’s the goal of
your business model or what is your product doing?) Tie this to an
actionable traction metric, one built on customer actions instead
of just revenue. Before product fit, only two metrics matter: Do
customers enjoy their first experience (activation?) and do they come
back?
Create short-term goals and experiment until you reach them.

Orient your goal to align with your solution that ties closely to your
Clear Strategy 70
customer’s needs, such as engagement and active usage for a social
media platform. Entrepreneurs and product managers provide the
solutions. Once you’ve identified your goal, you’ll want to orient
your organization toward constant improvement on that actionable
metric.
Expose, test, repeat
Once you’ve identified your goal and can observe it in action, you’ll
want to be able to make changes in response to what you’ve learned—
and then retest. The idea is to create a constant cycle of validation
and improvement. Observe where your team is in relation to your
goal, reorient your organization based on those observations, and
then make changes.
In the first 90 days, you’ll find out if there’s a product-market fit (if
there isn’t, go back to the drawing board) on a small set of customers.
It’s far less painful to make significant product changes that affect a
dozen customers than it is on ones that affect a couple of hundred
thousand customers. You should focus your time on providing high-
quality customer service to your first dozen customers. Once you’ve
been able to validate product-market fit, you can start increasing
the number of customers, and you can rapidly scale up operations
without wasting resources.
At the core of this process are LEAN sprints: exposing the problems,
Clear Strategy 71
testing solutions, and repeating that process over and over again.
The idea is to source, test, and rank ideas that will move the team
closer to your goal, building velocity in the process.
Respect your team’s time
Validation should uncover both qualitative and quantitative

assumptions, which is why traction is so important. Any other metric
can be gamed. You need to have a success metric that reflects the
outcome you want and shows that customers actually need the tools
you’re building to solve their problems. Orient your organization
towards these solutions to spend your team’s time wisely, so that
they’ll feel more bought into the process.
Ultimately it comes down to respect for your team’s time. If you want
to build the kind of momentum that will create a successful product
or business model, you have to prioritize your team’s time even if
you’re the only one on the team. By optimizing for momentum and
by showing the opportunity of what your product can do through
customer validation, you can motivate them to develop a truly
incredible product.
Clear Strategy 72
Prioritize delight
by Scott Baldwin, Director Product Management at Thinkific
Here’s my most delightful day: going for an early morning long

mountain run (yeah, I’m that guy who’s fully alert and productive
and running up a mountain at 5:00 am that you all hate); coming
home, having a warm bath, and then taking a nap in the afternoon;
sitting down to a roasted chicken dinner with friends or family and a
great bottle of red wine; then sitting back afterwards listening to the
crowd build in excitement while Duke Ellington and his orchestra
bang out Diminuendo And Crescendo In Blue on their amazing live
Clear Strategy 73
album Ellington at Newport.
Moments in life like these are always delightful. As a product manager,

I often struggle to find that same sense of delight in the products I’m
using or sometimes even in the ones I build on my own. But when
I do, it’s a remarkable joy often captured in a single detail, a small
interaction, or a thoughtful, timely touch that’s instantly memorable
and often unforgettable.
So, what exactly is delight?
Delight is generally defined as having a high degree of gratification,

pleasure, and joy. From the perspective of product development,
Aaron Walker, in his book Designing for Emotion, describes a hierarchy
of user needs. He says that every product must be functional (solving
a problem), reliable (up and running), usable (easy to use, learn,
and remember), and pleasurable. For comparison, Dana Chisnell
describes three approaches—Pleasure, Flow, and Meaning—that
teams can use to add delight to their product.
Who is prioritizing delight?
Whether you work in B2B or B2C, spending even a bit of effort

on delight will drive improvements in your key AARRR metrics
(acquisition, activation, retention, revenue, and referral).
Clear Strategy 74
http://startitup.co/guides/374/aarrr-startup-metrics
●● For acquisition, Dollar Shave Club spoke to shaver pain points,

poked fun at themselves, and announced to the world that they
were ready to shake up a previously forgettable industry. They
became the second-largest men’s razor seller in America.
●● For activation, productboard provides a helpful overview of the

product’s features while emphasizing their philosophy and the
problems they solve. They even show new customers example
content in the interface to get them started with the product.
●● MailChimp boosts retention with an easy to use dashboard that

outlines the steps required to send your first email. They also
offer great knowledge base content that’s well-structured, easy-
Clear Strategy 75
to-read, and a support team when you need it.
●● Delight drives ongoing revenue and referral. Help Scout takes

time to send their customer short thank-you notes that highlight
significant moments or milestones. These types of actions, while
small, lead users to recommend these companies to others
looking for solutions.
How to plan for delight
It’s up to you as a Product Manager to determine how to prioritize

delight. Here are some ways you can get started:
Measure delight
Measure your delight success with metrics, such as those based on

Google’s H.E.A.R.T, a framework to measure user experience on a
large scale:
●● Happiness: satisfaction, perceived ease of use, and NPS
●● Engagement: number of engagement actions taken
●● Adoption: changes in adoption rate, number of new subscriptions,

number of signups
●● Retention: number of active users, repeat usage or subscriptions,

renewal rates
Clear Strategy 76
●● Task Success: number of completed tasks, time on task
Include delight in feature ranking
I include delight as one of our key drivers in productboard, with

every feature ranked for delight. Use Google’s H.E.A.R.T.’s 5 factors
listed above to rank and prioritize product changes using each factor
as a Driver in productboard.
Include delight in your product development process
Incorporate delight in all areas of your product development process.

Dan Olsen covers some of these topics in The Lean Product Playbook.
●● Use open-ended questions when interviewing users to get the

real meat of their issues and discover what they’ll respond to
most positively. Sprinkle those discoveries into each release to
“[put] small amounts into your savings account.”
●● When prototyping solutions, consider how your team can reduce

friction, wasted effort, and cognitive load. Provide subtle but not
annoying interactions that bring in your product’s personality.
●● Ensure your product aesthetics are appealing and create a

positive first impression.
●● Develop a style guide, such as MailChimp’s Content Style Guide,

to capture and consistently convey your product’s voice, tone,
and character.
Clear Strategy 77
●● Don’t just consider core business objectives, such as revenue,
when making your product strategy. Include customer related
objectives, such as delight that might lead to improvement.
Share delight
Share your users’ delight with your team, such as:
●● Social media mentions where someone calls out that nice

interface touch or an unexpected way something works
●● A call into your support or customer success team where a

customer mentioned something that was easy
These shared delights encourage your team and help them see the
value in prioritizing delight.
Clear Strategy 78
SECTION 3
Coherent
Roadmap
Focus your roadmaps on
outcomes, not outputs
by Bruce McCarthy, Author, Speaker, Founder at Product Culture
Product roadmaps have gotten a bad rap. Most of them deserve it.
Ask someone what a product roadmap is and 9 out of 10 times you’ll

hear it’s a list of features and dates. And while many roadmaps do
include this info, I think this answer misses the real point of having a
roadmap. As my co-authors and I discuss in our recent book, Product
Coherent Roadmap 80
Roadmaps Relaunched, a good roadmap is a strategic communications
tool, a statement of intent and direction, and, done well, a way of
rallying the whole organization around the key problems that must
be solved to achieve your product vision.
Anthony Accardi, CTO of Rue Gilt Groupe, an online flash sale

e-commerce platform, said it well: “An effective roadmap retains
that context of ‘Here’s why we made these decisions, and here are the
assumptions we’re making.’” And yet, most roadmaps leave all of that
out in favor of minute details about features, bug fixes, schedules,
and dependencies.
This style of roadmap is a legacy of the days of lengthy waterfall

projects. In fact, the invention of the technology roadmap is
usually credited to Motorola’s semiconductor unit in the 1980s. In
today’s businesses, however, the pace of innovation has accelerated
dramatically, and Gantt charts (invented in the 1890s) live about as
long as a mayfly.
Features are outputs. They are the specific changes your team is
making to your product or service in hopes that things will improve
for your customers and your business. Improvement is the outcome
derived from those outputs.
Outcomes are the driving reasons why you have a roadmap at all, so
why not explain from the start what these desired outcomes are?
Coherent Roadmap 81
Let’s say you are thinking of revamping the screens that appear the
first time a new user logs into your app. You could put “Redesign new
user experience” on your roadmap, but why might you be working
on that? Well, maybe you’ve gotten feedback that the landing page is
confusing. And maybe you’ve discovered that 60% of first-time users
never come back. So the real reason you are thinking of this project
is to improve the odds you will retain these customers.
Now ask yourself, what if your redesign doesn’t work? What if the
new screens are even more confusing? Or what if the greater obstacle
to returning customers turns out to be related to login credentials,
project creation, or pricing? Should you just ship your redesign, hope
for the best, and move on? Of course not.
As an industry, we’ve learned to test our assumptions, to put

something out there, measure usage, and tweak or pivot as necessary.
And yet our roadmaps don’t reflect this lean approach to business.
Most roadmaps assume we know what we will ship and when—and
that it will work right the first time.
A better approach is to describe the customer or business problem

we are trying to solve—the outcome—and leave the details of the
features, functions, and fixes we plan to test—the outputs—to JIRA
and Trello. Then you might add something to your roadmap like
“Increase repeat usage by 20%.”
Contactually, a SaaS-based intelligent CRM for real estate
Coherent Roadmap 82
professionals, created this roadmap focused entirely on the business
outcomes they sought. And as you can see, the details on features
and functions are kept quite minimal, even vague at times.
Outcome roadmap through next summer
Outcome we’re seeking September October November December Q1 2017 Q2 2017
Launch 2nd major Launch 3nd major

Launch new features/ RE customer Send individual Send cards en
feature/service to feature/service to
services to increase ASP development cards masse
increase ASP increase ASP
Quick changes to Improved autor/

Improve Prof & Ent plan
60% drive Prof/Ent plan campaigns via
features to increase ASP
adoption Programs 2.0
Improve team functionality Launch features to drive greater Team

Team lead cust dev
to increase ASP Lead adoption
Improve long-term product

15% Quick customer-facing wins & top bug fixes
usage
Invest in infrastracture
Rebuild additional parts of app in React (as needed for other improvements)
15% efforts that will allow us to Rebuild dashboard in React
Launch features/enhancements that leverage data science/ML
iterate & differentiate faster
Build new
Increase % of new trials
10% onboarding testing Continuous iterative improvements to onboarding flow
fully onboarded
framework
And Contactually is not alone. Elli Rego, Product Manager at Wodify,

a gym management SaaS software platform, says “We accept that we
don’t know which specific features we’re going to build, and we give
the teams the freedom [to figure it out].”
The benefits of this approach are many. Making the desired outcomes
clear frees your team to consider alternative solutions that may
reach your objectives faster and easier, sometimes with no feature
work at all. At Localytics, a mobile engagement platform company,
they discovered that improved documentation was the fastest way
Coherent Roadmap 83
to ensure more reliable onboarding of customers, so they scrapped
more involved plans for redesigning their SDK.
Focusing on the “why” in your roadmap instead of the “what”

communicates more clearly where you are headed, and what success
looks like. It also means your roadmap changes less often. People
complain about “roadmap churn,” but customer and business
problems don’t actually change that much or that quickly. An outcome
roadmap is more stable over time with only the tactics employed to
reach those outcomes shifting as different approaches are tested.
If, like many, you’ve been tempted to abandon roadmapping as old-

fashioned, consider a roadmap of outcomes as a way to communicate
your product vision and the problems you think worth solving. This
will help you gain buy-in and leverage the creative problem-solving
energies of your team far better than a list of feature promises you
likely can’t keep.
Coherent Roadmap 84
Small teams build
companies
by Jeetu Patel, Chief Product Officer at Box
In today’s world, every company must become a digital company

or risk being disrupted. One of the key characteristics that will
differentiate the disruptors from the disrupted in the future is how
quickly they can innovate and stay ahead of the curve. Product
leaders are the central linchpin of innovation, and configuring an
organization that sets them up for success is extremely important
Coherent Roadmap 85
when infusing innovation at scale. As Chief Product Officer of an
established, yet growing company, I’ve spent a lot of time thinking
about and putting into action the strategies and tactics for building
an agile and successful product team. The problem a company is
solving, the size of the teams, as well as the team makeup are all
integral pieces to putting together the best product team possible.
Great teams need great problems
Building a great product team starts before a company makes its

first product hire. The single most important thing an organization
can do to attract the best talent is to pick the right problem to solve.
Throughout my career, I have seen a direct correlation between
the difficulty of the problem a company chooses to solve, and the
quality of people that company attracts—basically, the harder the
problem a company picks, the better the talent they will attract, and
therefore, the likelihood of success increases. While this may seem
counterintuitive, taking on a difficult problem requires a person
to be passionate about it—I believe this passion leads to greater
strategy buy-in and a general drive to solve the problem. By setting
this problem from the start, a company can easily convey the “why”
behind it during the hiring process, ensuring that everyone who
comes on board orients around that same problem, and aligns from
day one.
Coherent Roadmap 86
The power of small teams (the PEAPOD)
You’ve picked your problem and are ready to start building your team.
How big should your team be and what does this team look like? At
Box, we have adopted Amazon’s “two-pizza teams”—we want all of
our teams to be easily fed with two pizzas. And this doesn’t change as
we scale. Many people assume that as the company grows, so should
team size. However, I don’t just believe that teams should remain
small as you scale—I believe that big teams can kill a company. Many
times, I have seen incredible talent get lost on large teams because
they no longer see their impact and eventually feel a diminished
sense of accountability and motivation. Goals are then not achieved,
causing a knock on effect that ultimately impacts larger company
goals.
“The single most important thing an organization

can do to attract the best talent is to pick the right
problem to solve.”
Each of our two-pizza teams, or pods, has its own local mission,
strategy, and set of goals that they are laser-focused on. These local
missions and strategies ladder up to the overarching mission of the
product team—but by providing teams with this level of autonomy,
each team member not only understands their individual part in
achieving desired outcomes, but they truly feel their impact. Small
Coherent Roadmap 87
teams are also much more agile than large teams, making it much
easier to pivot strategies if needed—which every growing company
will likely need to do at some point as they mature. But what do these
“two-pizza teams” look like?
When we were deciding how to structure our product organization,

we thought about what our “first team” should look like—what
combination of specific people and disciplines did we believe we
should put our trust in to not only drive product innovation, but to
embody the culture we wanted running through our entire product
organization? What are the different areas of expertise, perspectives,
and experience we needed on this first team to best ensure product
excellence? At Box, we use the acronym PEAPOD to define this
core organizational unit for the product team. PEAPOD stands for:
P: product management; E: engineering; A: analytics; P: program
managers; O: online growth; and D: design. This has proven to be
the right mix of people to drive successful product development at
Box. Of course, every company is different, and it may take time to
find what that exact mix is right for your organization. And it may
change over time but once you’ve defined this “first team,” scaling
and knowing where to invest resources will be much easier.
When diving into what this structure means for the product manager
overseeing a PEAPOD team, the expectation is that they are driving
both the strategic product direction and the overall performance of
the POD. For each product area Box is focused on, entire companies
dedicate themselves to build products in that space. So the product
Coherent Roadmap 88
manager needs to make sure that each function represented within
the PEAPOD is working together to provide 10x capabilities versus
competitors in the market.
Innovating security with a small team
For example, security is one of our strategic focus areas as a company,

and it’s imperative that we continue to break into the market with
cutting-edge technology that goes above and beyond our customers’
needs. The product manager leading this team has a single mission
to enable the continuous innovation needed to develop these
technologies, which enhances Box’s security across all of the relevant
personas and allows us to stay ahead of our competitors. Having this
product manager solely focused on security allows them to think
end-to-end about this product area. This includes everything from
team staffing (i.e., working with the engineering leads to decide if
front-end and back-end engineers are needed), to which customers
and markets to target, to how a product will drive revenue. On top of
this, the product manager needs to keep the team motivated and to
maintain a level of intensity towards accomplishing the team’s goals
across the PEAPOD functions.
Building for the future
It’s not always easy to measure the success of philosophies and
Coherent Roadmap 89
strategies, but I like to think about where we were a few years back
and where we are today. Just three years ago, Box was a single product
company. The creation of focused, mission-driven, agile teams
helped Box greatly expand our product offering to become the true
multi-product organization we are today, driving significant growth
for the company. Today, the majority of our large deals now include
add-on products developed by these teams, in addition to our core
Box product—and we see this trend within our business only growing
over time.
While this is just the beginning of what it takes to build a great product
team, once you set the foundation, your product organization will
be engaged and driven to build amazing products. Importantly, a
company will never be “finished” building their organization. We are
constantly assessing what works for teams at Box and tweaking as
needed. However, with core principles in place, it’s much easier to
tweak along the way, than to overhaul down the road.
Coherent Roadmap 90
Be bold, ship gradually!
by Kurt Heinrich, Product Manager at Shopify
Just ship it.
You’ve probably heard the phrase or even said it yourself. However,

as product managers, we all know that the way something is rolled
out can mean the difference between a successful launch and one
that backfires.
Should you roll everything out quickly and ship boldly or should you
Coherent Roadmap 91
take a bit more of a measured approach and ship gradually? It’s often
popular, especially for startups, to use the shipping boldly approach,
but don’t discount the value of shipping gradually.
Shipping boldly
This approach is optimized for quickly delivering value into the

hands of your users. Generally, changes are rolled out to users all at
once in hours or days. Let’s take a look at some examples.
Facebook is not shy when it comes to making changes as they have

made many of them over the years. As a user, you’ve probably
experienced this when logging into Facebook and seeing something
different. Facebook is famous for their motto of “move fast and break
things,” and it’s gotten them to where they’re at even if they have
toned it down a bit in recent years.
In my previous startup, a B2B SaaS application, we shipped boldly.

We were solving a niche problem, and our user base was made up of
a few hundred paying customers. Like many startups, our users were
early adopters making them more forgiving of changes and willing
to provide feedback. On top of that, we didn’t have the tools or time
to do more gradual rollouts. If something went wrong, we just fixed
it quickly. As I mentioned above, many startups ship boldly.
Coherent Roadmap 92
Shipping gradually
This approach is optimized for learning while minimizing negative

user impact. Generally, changes are rolled out to a subset of users,
monitored for feedback, then rolled out to more users. This process
might happen over a period of weeks or months.
The new Gmail was launched earlier this year. However, it didn’t
happen overnight. It was first announced in April 2018, as an opt-in
experience. Users could try the new Gmail or go back to the old one
if they didn’t like it. During this time, Gmail collected feedback from
users that both stayed opted in or opted out. After 3 months, Gmail
took away the ability to opt-out, and they migrated all users to the
new experience.
I now work at Shopify, a large-scale e-commerce platform with

hundreds of thousands of users. Even the smallest of changes get
noticed and have the potential to disrupt users, which is why I often
choose to ship gradually. I recently worked on a project where
we redesigned one of the most trafficked pages in our app, and
qualitative feedback was one of our success metrics. For this reason,
I took a more gradual rollout so that we could release the changes to
a small set of users and iterate based on feedback, before rolling it
out to all users. This ended up being really smart because we learned
lots of things from real users that didn’t come up in our user testing.
For example, we learned that certain users printed this page out and
some of our changes made that experience worse at first.
Coherent Roadmap 93
Picking an approach
Each approach has pros and cons. Ask yourself these questions to
determine which one is right for your project:
●● What are the biggest risks with this launch? What could go wrong?
●● What is our confidence level in what we’ve built? Are we looking

for feedback? Are we willing to iterate the product based on that
feedback?
●● How much time do we have to roll this out? Do we have a deadline?

Can we afford the additional engineering time to set things up?
Ship boldly when:
●● The changes are small (will only be noticed by some users) and
are unlikely to confuse or disrupt users.
●● You’re highly confident in what you’ve built and have done

extensive user research with mockups and prototypes.
●● You’re going to make the changes anyway regardless of user

feedback.
●● You’re under a tight deadline or simply don’t have the resources

for a more sophisticated rollout.
Ship gradually when:
●● The changes are major (noticeable by most users) and are likely
Coherent Roadmap 94
to surprise, disrupt, confuse, or otherwise negatively impact
users.
●● You’re less confident in what you’ve built or want to see how real
users use the product.
●● You want to iterate the product further based on feedback from

real users.
●● You can afford a longer rollout and have the tools and engineering
resources to target or exclude certain users.
You can ship gradually and be bold!
Shipping boldly might be the default approach and most common.

But shipping gradually can pay off when the stakes are high, and you
want to maximize learning. Another reason it’s probably not used as
much is that it may appear more complicated to set up. However, it’s
very doable to build or you can use a tool, such as LaunchDarkly.
The easiest way to do it is using what’s called a ‘feature flag,’ which is

a bit of code you wrap around your feature to toggle it on or off. As
for turning the feature ‘on,’ that depends how fancy you want to get
with your logic. Some examples are:
●● By percentage (0% to 100% of users)
●● Manually (for select users, you turn it on)
Coherent Roadmap 95
●● User opt-in (the user can opt in or opt out on their own)
If you’re just getting started, I recommend just using the percentage

method. You may consider setting some exclusion logic, such as
for users on certain pricing plans. However, my favorite method is
the user opt-in. The fact that users have opted in (and can opt-out)
makes them more forgiving early adopters and is less disruptive to
everyone else.
The benefits of shipping gradually are great. Don’t confuse it with

being slow or lacking confidence. In many ways, it actually lets you
get your product in the hands of users faster. It also lets you ship
even bolder changes to a subset of users, allowing you to evolve your
product faster. So be bold, and ship gradually!
Coherent Roadmap 96
Working remotely can
make you a better
product manager
by Courtney Machi, Director of Product at Toptal
Making a move
In early 2017, I decided to take a fully remote product leadership
Coherent Roadmap 97
role at an entirely distributed company of around 350 employees.
I had been doing product management in startup-land for a while
and had recently finished a few stints of living and working abroad
in Europe and South America over the last couple years (both for
my employer and for some independent work). The people, ideas,
attitudes, lifestyles, and perspectives I experienced had convinced
me that there was more out there than what I had come to know so
well in San Francisco; and most importantly, that I did NOT, in fact,
need to be in San Francisco in order to build amazing, impactful
products.
Was I nervous? Absolutely. Product management is difficult enough

when you can sit in the same room with your teammates and often,
your customers. But, as most of you product people will identify
with, I was up for the challenge!
Why I love working remotely
According to Edelman Intelligence, by 2027, the majority of the

US workforce will be comprised of freelancers, most of which are
typically remote workers. More and more people want to jump on
the remote train, and I quickly figured out why. Here’s what I came
to love about working remotely:
●● As a global, fully remote company, you now have access to talent

around the world with a variety of experience and perspectives.
Coherent Roadmap 98
●● Building rapport, though a bit more challenging, is fun because
you get used to turning on your video camera and embracing
your “woke up like this” look.
●● Remote workplaces can be true meritocracies because you’re

judged by the output of your work, which becomes your top
communication medium.
●● The additional focus on work and results leads to more focus

on data, KPIs, and continuous improvement with less room for
noise and distraction.
●● Storytelling becomes very important when your communication

medium is your work, typically in presentation form; so you
dramatically improve in that area.
●● You learn to become more disciplined about your work time and
routines which leads to a better work/life balance.
Remotely running a successful product

journey mapping session
But of course, as I expected, there are also challenges to doing

product remotely. Requirements gathering and brainstorms for
complex initiatives proved to be difficult. Getting all the stakeholders
into a room in the office or at a location somewhere in the world was
not really an option anymore (as we are committed to all remote all
the time), making things like user journey mapping exercises seem
Coherent Roadmap 99
impossible.
So we committed to trying these remotely. I’d never seen these done

remotely before, but I figured the worst that could happen was we
end up with a Zoom room full of confused people, a jumbled Mural
board, and all of us chalking it up to a failed experiment.
Believe it or not, it worked very well.
Here are my tips to running a successful product journey mapping

session remotely:
●● Identify one unbiased facilitator, usually the PM or the UX

designer. When I run these, it’s usually me.
●● Get all your participants to commit to 1 hour and 1 hour only.

Timebox the session for maximum productivity.
●● Prepare your participants beforehand. Tell them what to

expect, how to prepare and what they need to contribute, who
is facilitating, and send out the Mural or RealTime board you’ll
use for the session so they can see it in advance. Treat it like an
onsite workshop!
●● Do your research beforehand. As the facilitator, ensure you have

a basic understanding of the flow/process so you can ask the
right questions and prompt for issues/opportunities. Make sure
the board is set up with all the basic steps in the user journey.
Coherent Roadmap 100

●● Though you’ll be sharing your screen and updating the board
with stickies as you progress through the user journey, make
sure you have another person designated as note-taker to capture
anything you might have missed. Record the session too.
We’ve embedded this into our product process, and I now feel it works
better than it did when I was onsite at an office, simply because it
made us more disciplined and efficient. It’s also a fun opportunity to
get everyone together in one virtual “room” as a workshop of sorts,
something that we don’t get to do too often in a remote company.
Becoming a better product leader
While being remote may require more work up front from PMs,
ultimately it provides the opportunity to become a more well-
rounded product leader. Recognizing and overcoming the challenges
associated with remote product management only leads you to hone
your skills and zero in on weaknesses that you may have had in
past onsite positions. For example, I sometimes did not do enough
preparation for workshops in the past simply because “we have the
whole day” for the workshop or because “we will figure it out when
we get in the room together and can whiteboard it out.” There’s also
a whole lot of potential for finding better work/life balance, picking
up new and unique perspectives, and discovering innovative ways to
build products by way of overcoming remote challenges.

Manage growth with
initiatives and focus
by Roger Dudler, Founder & CTO at Frontify
Feeling the growing pains
When we started growing our customer base at Frontify, the number

of customer requests increased like crazy, which, of course, is a good
thing. It means that people care about what you’re doing. They use

your product and have opinions they’d like to share with you. But
how do you handle them when you’re just a few people strong? You
won’t be able to pursue everyone’s request. How could you?
In the beginning, we were successful by quickly fixing issues, or

adding new features, in a matter of hours. That worked well for a
while—but not for long. After this phase, we found ourselves forced
us into “operations” mode, making people happy by just working
through tons of requests, but we failed to find time for innovation
and other important initiatives, such as ensuring system stability
and scalability, customer support efficiency, automation features,
and reducing the number of bugs. It’s an overwhelming number of
goals to handle.
Use Strategic Initiatives
We got a handle on our growing pains by introducing “Initiatives,”

which are goal-driven streams that generally last for around three
months. Each Initiative takes a specific percentage of our resources.
For a particular sprint, our Initiatives may look like:
●● Improvement Initiative (bugs, UX): 15%
●● New Features Initiative: 20%
●● Support Initiative (automation, support tools, self-service UI):

30%

●● Enterprise Customer Delight Initiative: 35%
By doing this, you can make sure that you’re making progress in
every crucial area, and not only one. You can review those initiatives
weekly, or monthly, to ensure that you still have the right focus and
balance.
Focus the Whole Company with a Product

Vision
Once you’ve established a healthy growth of the product and its

ecosystem, you will face new challenges: more clients, more
requests, more extensive features, and more prominent teams. You’ll
ship much more, which is good, but you also have to keep everyone
informed and aligned. At Frontify, we tried to do this by introducing
a product vision with a clearly defined scope. A model that shows
where we are today, what we’re planning to do soon, and later—
always with a clear link to our overall vision. This helps our company
to stay very focused when ideas emerge. It allows us to say “no” to
things that are outside of our playground. It reduces distraction a lot,
and it builds the foundation for a great roadmap.
There are many challenges ahead of us, and I’m excited to master
them together with our team. So should you.

Align your product
roadmap to your
company strategy
by C. Todd Lombardo, VP Product & Experience at Vempathy
First, a post-mortem
Let’s hop in the wayback machine and travel back to summer 2014:

The Amazon Fire Phone was released to much hype, yet 14 months
later the company stopped production and discontinued sales
shortly thereafter. While there are many missteps that might explain
this product failure, I am sure the team behind the Fire Phone had a
fantastic product roadmap. The problem is the Fire Phone’s product
roadmap didn’t line up with Amazon’s company strategy.
Amazon had success with the Kindle tablet where the product
strategy was to profit through sales of digital content, rather than
make money on the device. Amazon’s business strategy is that of
lower prices and winning through operational efficiency. The Fire
Phone launched with a retail price tag of $199 on a two-year contract.
This was the same price as the iPhone and Samsung Galaxy phones
at the time. Where was the lower price strategy? The product strategy
appeared to be selling a premium product at a premium price, just
like Apple. Product strategy and thus the product roadmap didn’t
align with company strategy, and the Fire Phone died a fiery death
(pun intended).
Product strategy ≠ company strategy
There is a hierarchy that starts with company mission or vision: the

‘why’ you exist. This is followed by a company strategy: how you’ll get
there. Under company strategy are operational and tactical initiatives
to realize that company vision. One of those is product vision: the
‘why’ of your product. Your roadmap connects your product strategy

to your company strategy through the product vision.
Stating your vision
You may use mission or vision interchangeably but for this discussion,
we’ll use vision. In our workshops on product roadmapping, we use
a well-known example many are familiar with: Google. Google’s
company vision statement is: To organize all of the data in the world
and make it accessible for everyone in a useful way. Now consider some
of Google’s products, like Chrome, or YouTube. Chrome’s vision is
to simplify web browsing, or to go beyond just web browsing. YouTube’s
vision is to give everyone a voice and show them the world. Each of these
product visions has a strategic relationship to the company vision.
Drive outcomes: Objectives & Key Results
Objectives and Key Results (OKRs) are a well-documented approach

for teams to drive their efforts towards outcomes. Relating this to
your product roadmap, using the concept of themes to not specify
features, rather identify problems to solve and match them to the
OKRs will further that alignment of your roadmap to your company’s
strategy.

The strategic hierarchy of your product
At a startup I work with, every theme we have on our roadmap rolls up

to an OKR, which is aligned with our annual strategic goals. Any new
feature the team works on is categorized under a theme, and every
quarter, we adjust our themes to align with our quarterly objectives.
The illustration below shows how these are connected.
Product strategy
THEME FEATURE EXPERIMENT

COMPANY PRODUCT A
OBJECTIVE
VISION VISION
THEME EXPERIMENT FEATURE
THEME EXPERIMENT
PRODUCT B
OBJECTIVE
VISION
THEME FEATURE FEATURE
THEME EXPERIMENT
Company strategy OBJECTIVE

THEME FEATURE EXPERIMENT
Roadmap Release plan
Each theme may have a set of features or experiments so you can

plan your product releases. Note that the roadmap doesn’t list out the
experiments nor the features. These are a problem-to-solve, typically
from the customer’s point of view, and when these are aligned to
your OKRs, you set the product team (and product) up for success.

Let’s hypothetically apply this to the example we started with,
Amazon’s Fire Phone. Amazon’s vision is to be earth’s most customer-
centric company; to build a place where people can come to find and discover
anything they might want to buy online. Writing the Fire Phone’s vision
to paint the “why” of the product could be: to make online purchases in
the palm of your hand. This product vision statement might be suspect
as most phones already offered this capability and there was no real
differentiation, nor would it be considered visionary.
An investigative article in Fast Company later revealed: “Whenever

anyone asked why we were doing this, the answer was, ‘Because Jeff
wants it.’” Conversely, the company could have gone in a different
direction and doubled down on products like Dash, which could have
resulted in a number of single-function buttons across a consumers’
home that lacked cohesiveness, even though it may have added some
level of convenience.
At the core, a product vision aligns your product’s why to your

company’s strategy, and ultimately this aligns your product roadmap.
Everything on your roadmap has to have a sound strategic hierarchy
that aligns to your product’s vision and company mission. Without a
clear strategic alignment, you may find your product has become a
fragmented mix of features that struggles to deliver on its promise.

How to make better
decisions around your
releases
by Rachel Wolan, VP of Product at Euclid
Be well prepared for a release
I used to run product at a call center software company. One Thursday

in February, we rolled out a small but exciting change to fix a major
data input problem that impacted agents. Before releasing it, we
ran user tests and a month-long beta, thoroughly QA’d the agent
experience, trained our support team, and notified our customers
about the change. I was so comfortable that we did everything right
that the day we rolled out the change to tens of thousands of call
center agents, I left for a long ski weekend in Colorado.
We ended up completely breaking the existing process.
Agents were not getting credit for calls, which is how their pay is
calculated. Supervisors accused agents of not answering enough
calls. We received 10x the typical number of support tickets that day.
Suffice to say, our customers were really unhappy, and I spent the
majority of my vacation holed up in my hotel room rather than on
the slopes!
What went wrong
In the aftermath, we learned that several bugs logged by beta users

were not escalated. We also discovered that our assumptions around
the agent user persona were wrong and that our beta users had a
higher tolerance for change than the overall user population.
I took that opportunity to re-examine many things around our

decision-making process and my personal decision-making

capacity. Too many roads passed through me. My team was not able
to make bigger calls without me. Bugs were not getting escalated at
the right time. Feature requests were not evaluated systematically.
Basically, I was the bottleneck, and I needed to figure out better
ways to decentralize decision-making power. Here are some simple
frameworks I came up with to aid in release planning and real-time
decision-making.
#1: Release an internal alpha first whenever

possible.
We simply skipped the alpha stage in this case. We were lucky that
we had both Support and Inside Sales teams since that is who we
sold to. Involving our teams made them invested in the success of
the product, and they gave feedback in real-time to our product
managers, designers, and engineers. We created an internal product
council based on our most vocal alpha testers.
I also instructed my product managers to review their beta plan with

those teams. Each member of the internal product council had to
sign off before we released agent-facing features. We realized that we
had a greater margin of error for the supervisor and administrator
functionality, but as soon as we touched the agent, we needed to run
a much more careful release process.

#2: Write the release notes as soon as the
engineers begin working.
I had my Associate Product Managers start working with the

organization the moment we had locked in a release, which
happened every month. That gave Support time to build detailed
documentation, User Experience time to create user guides and
onboarding guides, Sales Engineers time to adjust their demos, and
Product time to produce a proper FAQ.
#3: Make bug escalation a team sport.
After the release incident, I realized that information was deposited

throughout Support, Sales, Sales Engineering, Success, other
executives, and more. The bugs we discovered after the rollout had
been reported to Support, but not escalated to us. I hadn’t given those
teams a proper outlet both to escalate concerns, without crying wolf,
and to voice their opinions about the product.
I developed a framework to get cross-team buy-in so that anyone (i.e.,

Support, Sales, Success) could make real-time decisions about bugs
on the spot based on our shared set of rules. Once we implemented
it, we made tremendous strides in improving our bug resolution
process.

Below, you will see the bug escalation framework we developed and
refined over several months. Every time a bug was submitted by
anyone in the organization, they filled out the following scorecard.
Product and Engineering also filled out components of the scorecard
when new tickets were submitted. This gave everyone a voice in the
escalation process and distributed responsibility, ultimately making
it much easier to make faster complex decisions.
Support % Users Affected Technical Business

Score Severity
effort Per Account Risk Risk
S1 - Major. Significant defect SE1 - Continous monitoring U1 >20% of users per T1 - High Risk, poses high BR1 - High Risk.
x3 exists, no workaround and hard replication. More account security risk to customers Impacts ARR > $500K.
exists, reporting data is than 10 customers affected. and to us. Surfaces a severe 1 or more customers in "red."
incorrect. issue in major component. Impacts accounts in implementation.
S2 - Moderate. Affecting SE2 - Can be replicated and U2 Between 5% and 20% of T2 - Medium Risk. BR2 - Medium Risk.
x2 some or no users. requires moderate attention. users per account Impacts ARR > $100K.
Acceptable workaround Up to 10 customers affected. 1 or more customers in "yellow."
exists. Impacts accounts up for renewal.
S3 - Minor. Little to no SE3 - Low attention and U3 <5% of users per T3 - Low Risk (default). BR3 - Low Risk.
x1 impact on functionality, but easy to replicate. Less than account Impacts ARR < $100K
looks sloppy. 5 customers affected. Impacts customers in "green."
By distributing responsibility for the success of the release process,

we significantly de-risked future releases to agents, got earlier buy-in
across the organization, and sourced better ideas from the highly-
engaged alpha product council.

Doing product discovery
with a remote team
by Tim Herbig, Product Leader and Author
There’s a common myth that co-located product teams perform better

than distributed ones. Given the nature of today’s digital workplace,
we should be challenging this assumption and letting people work
how they actually want to work. Remote teams allow you to get
access to the world’s brightest talent and gives your employees more
flexibility to work where they want, allowing for more diverse, happy

teams. However, to achieve this, we need to fundamentally rethink
our toolstack AND our processes.
Fundamental issues with remote work in its

current setup
At my former company, when two members of our team started

working remotely, we continued to run Scrum as if everyone was
physically in one room. We still had a Scrum board, and we conducted
our in-person daily stand-ups and retrospectives in-person. We
shared blurry photos of the whiteboard in Slack and dialed in our
teammates only to waste time complaining about the audio. Needless
to say, this came to an end rather quickly.
While remote teams are a great way to break free from existing
paradigms, they can also amplify existing issues if they’re not set
up properly. There are two fundamental aspects of effective remote
work:
1. Communication can either be synchronous or asynchronous.

For more emotional topics, the team needs to communicate
synchronously.
2. Having a couple of people working from home isn’t remote

work. If everyone in the office continues to “do their thing,”
then the remote workers will feel excluded. Successful remote
collaboration requires equal access to information for each team

member.
Building the optimal environment to kick off

product discovery
When I ran my new fully remote product team, we tried many things
for the first time. I wanted to avoid past mistakes like excluding
individuals who worked from home or picking the wrong tools. The
biggest challenge is transitioning a team from being co-located to
fully remote while using existing modes of communication. You
have to fundamentally reassess which tools you use and how you
communicate synchronously and asynchronously.
For example, when my team conducted our first product discovery

meeting, we decided to take a new approach. Instead of traveling
to meet in one place just to brainstorm and conduct workshops, we
wanted to remain geographically independent and prove that even
traditionally co-located meetings could be done remotely.
Equipped with Slack, Zoom, InVision, and Mural—tools that cater to

the remote workers—we dove right into our product discovery kickoff
meeting. We used a canvas in Mural to plan the day ahead and to
share existing materials like our mission briefing, moodboards, and
InVision prototypes. We stored our mission statement in a central
repository so that it could be collaboratively edited and referenced.
Also, in order to have equal access to relevant design resources, no

one was allowed to capture any inspiration in a local or physical
notebook. InVision became our remote design hub.
After aligning and planning our workshop, we simply followed best

practices:
●● We agreed on the objective of each phase (e.g., ideation, mind

mapping) and paused our video call. Everyone then independently
created their notes in Mural.
●● We set a timer in Slack to notify us when our individual

brainstorming time was up.
●● We discussed, clustered, and voted on the best idea on a video

call while looking at Mural together.
●● We repeated the process through multiple rounds of iterations,

converging and diverging when appropriate.
●● When we came to the “solution” phase, we simply sketched our

solutions on paper and uploaded them to Mural.
I estimate that we only spent 2-3 hours on a video call during an 8-hour
workshop. When we weren’t doing independent work, we made sure
that we were fully present during the meeting. We used webcams so
we could see people’s faces, fostering better collaboration.

Continuing product discovery remotely
After our successful product discovery kickoff workshop, we were

able to quickly move to the next phase of validating our assumptions
and preparing for product delivery. We used the same tools and
processes to continue our work. We drew up a delivery plan and
stored it in a central repository, so we could reference it over the
coming weeks and share it with everyone supporting the initiative.
After we got stakeholder buy-in, we easily sent the assets we created
digitally instead of having to transfer blurry photos of sticky notes
into digital diagrams.
“Fully remote workshops can be more productive

than co-located ones with the right tools and
approach.”
For the phases after product discovery, like user research or backlog
planning, we continued to store all of our plans and insights in a
central repository so that the team could access them.
I‘m now convinced that fully remote workshops can be more

productive than co-located ones with the right tools and approach.

Implementing the same approach in your day-
to-day
When building out remote processes, it‘s important to reflect on

your team and company values and use them to transform your
distributed workplace.
Here are some questions you might ask:
●● Are all the tools available cross-platform, so no one is left out?
●● Did you consider different time zones, depending on where your

people are located?
●● Has the overall objective of the challenge been shared with

everyone in advance and is it easy to access?
Having the right questions in hand is the first step towards identifying
how to set up the right environment for remote collaboration.
Remote teams shouldn’t be a reason why the business slows down.
In fact, there are ways to harness the nature of the work to foster a
better culture.

Don’t let your roadmap
work against you
by Joe Cotellese, Product Strategist and Coach
Imagine you’re taking a trip cross country and you’ve plotted out the
course on a map, yeah, the paper kind. Somewhere around Colorado,
you find out that a massive storm is supposed to hit. The locals tell
you that your vehicle isn’t going to make it over the mountain pass.
They suggest taking another way, or even stopping for the night to
ride out the storm.

Do you listen to the locals and change your plan, or do you blindly
charge your way through the storm? If we used actual roadmaps the
same way we use product roadmaps, you might just keep driving. It’s
all about miles traveled—better to keep inching forward than to stop,
right?
You can probably all see the disconnect here. And this kind of thing
happens with product roadmaps all the time. In fact, it has probably
happened to you.
Let’s take a look at why so many organizations get derailed by the

very thing that’s supposed to keep them on track. Then we’ll discuss
how we, as product managers, can keep everyone’s eyes on the goal
instead of the to-do list.
Focusing on outputs instead of outcomes
Executive stakeholders often want to see a roadmap plotting out the

course over the next year. As product managers, we grudgingly go
through the exercise of filling up a roadmap—laying out projects side
by side throughout the year.
Success is often pegged to the output. Sure, we caveat this roadmap

by saying things like, “We may need to change things later,” or “I
don’t know how long this will actually take.” Nevertheless, once
published, organizations often treat it as the path forward rather

than a potential path.
W1 W2 W3 W4 W5 W6 W7 W8 W9 W10 W11 W12 W13 W14 W15 W16 W17
Feature 1
Feature 2
Feature 3
Feature 4
It’s like driving down the road, oblivious to the snowstorm in Colorado
when you could have easily taken another route.
The team will look at the roadmap and say “How can we do project
feature 4 in Q3 in only three weeks? We don’t even know what feature
4 is!” So, you’ll end up having the same conversation. “We may need
to change things later,” or “I don’t know how long this will actually
take.”
Publishing long-term roadmaps the way most organizations do is

potentially damaging to the culture and bottom line. Here’s why.
It disappoints the team
Stacked roadmaps set the team up for failure. Your roadmap’s caveats
are quickly forgotten as time marches on. Teams feel the stress of
needing to get something done quickly. Executives stakeholders get
annoyed because “We’re behind schedule and we’re not hitting our

goals.”
It breaks your process
The Lean process focuses on small iterations of build-measure-learn.

If your roadmap is pre-planned and tightly packed, you’ll rush to the
next feature instead of learning from the last one. Stacked roadmaps
ultimately lead to an organization focused on “being busy” and your
roadmap becomes a glorified to-do list.
There’s a better way
Now that we’ve identified the problem, let’s look at how to solve it.
Focus on outcomes
Success at the end of the year shouldn’t be measured on “How many

roadmap projects are completed?” Instead, it should be “Did the
projects have a positive impact on the business?”
The easiest way to begin having those conversations is to have a clear

understanding of the organization’s goals. Executive stakeholders
and product managers should ask, “Roadmap items aside, what are
the metrics, and how much do we need to drive these numbers to be

successful?”
Top Line Goal Increase Revenue by 40%
Product Goals Increase NPS score by 3%
Increase the signup-to-activation conversion rate by 5%

Decrease the three-month cancellation rate by 2%
This decouples the outcomes you need to achieve from the individual
outputs.
Use thematic roadmaps
Once you know the outcome you’re trying to achieve, divide your
roadmap into quarterly themes based on those goals. Group items
in your backlog by those goals. You can label them if you use a tool
like JIRA. Then, further refine the backlog by ranking each of the
grouped items.
The features in Q1 aren’t organized by time; they are organized by

priority. This allows the conversation to change from “You don’t
know how long Feature 1 will take,” to “Feature 1 is our top priority.
We’re going to deliver it, then decide whether to iterate on it or move
to the next feature.”

Q1 Q2 Q3
Improve NPS Score Increase activation rate Decrease three-month

cancellation rate
FEATURE 1 FEATURE 1 FEATURE 1
Leave space
When you take time out of your roadmap, you focus on the measuring
and learning from the Lean cycle. What does that look like, exactly?
Put the projects that you think are going to most impact your goals
at the top of this list. When Feature 1 launches, involve the entire
team in measuring and learning. Then, decide as a team whether to
iterate on the feature or to move to the next feature.
Ultimately, you may not complete all the features you listed for every
quarter, which isn’t the goal anyway. Your goal is to focus on working
through the entire Lean process on your high-priority items. If lower-
priority features get bumped to another quarter, that’s just part of
your process.

Better roadmaps lead to better culture
As a product manager, you are responsible for two products—the

thing you ship and the culture in your organization. There’s no
denying that roadmaps have a huge impact on company culture.
I’ve seen organizations improve the morale and engagement of the
team by implementing just some of the ideas here. A more engaged
team is a team that has less turnover, and less turnover leads to more
effective teams that operate at a higher velocity.

Contributor Biographies
Hiten Shah
Co-Founder at FYI, Product Habits and Crazy Egg
Hiten has started a few SaaS businesses including Crazy Egg,

KISSmetrics, Product Habits & most recently FYI. He’s also an
investor & advisor to over 120 founders and their companies. He
loves helping others succeed.
Alex Osterwalder
Co-Founder at Strategyzer
One of the world’s most influential proponents of business model

innovation and value proposition design, Alexander (Alex)
Osterwalder provides a framework for large companies and startups
to innovate by rapidly experimenting with new business models and
value propositions. He is co founder of Strategyzer, an innovation
powerhouse that helps organizations develop growth engines,
better customer understanding, more attractive value propositions
and powerful business models via online applications and blended
online/offline courses.
Osterwalder invented the Business Model Canvas, Value Proposition

Canvas, Culture Map, and Business Portfolio Map, to help business
people with practical tools to help address important strategic
jobs. He simplifies the strategy development process, turning
complex concepts into digestible visual models. As a result, a better
language for identifying and communicating value is created and
disseminated throughout an organization. Osterwalder’s talks –
which illuminate the application of these practical tools with current
market examples – consistently rank first or second among his peers
at global conferences. By punctuating his informative speeches with
humor and interactive exercises, Osterwalder establishes a deep
and direct connection with audiences ranging from five to 5,000 and
beyond, commanding high levels of participation, engagement and
enthusiasm. His speeches further reveal how his business model
and value proposition frameworks allow companies to grasp and
maintain a competitive advantage in the midst of a crowded, or
previously uncharted, industry.
Nils Davis
Product Management Consultant and Author
I think I was born to be a product manager. I like to have my fingers

in everything, and I love working with people and teams to help
them achieve great things. After I started in high tech (as a technical
writer) colleagues suggested I apply my talents for persuasion and
communication, combined with technical credibility, to product
management.
I started doing enterprise software product management in that long

ago time when there were no classes or books on PM. I always wished
I had the “secret” handbook about product management to help
me get over the humps. Instead, I was lucky to work with excellent
mentors across my career, who taught me about finding marketing
problems, driving the creation of solutions, and taking the solutions
to market effectively.
Product managers are ultimately responsible for delivering products

that create value in the world. My commensurate goal is to help us
all create more value by ensuring every product is a solution to a
meaningful market problem. And that every team creating and
selling products is as effective as they can be. In my book, The Secret
Product Management Handbook and on my blog of the same name, I
share what I’ve learned on how to achieve this.
Brian Crofts
Chief Product Officer at Pendo
Brian Crofts is the Chief Product Officer of Pendo, a product cloud

that helps digital product teams deliver software customers love.
Throughout a career in finance and product management, Brian
has been responsible for building high-performing teams, achieving
business results/growth, innovation, and change management. Prior
to Pendo, Brian spent 12 years at Intuit, most recently leading global
expansion for QuickBooks, Intuit’s suite of accounting and payroll
SaaS solutions for 1.5 million small business users. He lives with his
wife and four daughters in New York City.
Lucas Cerdan
Senior Product Manager at Algolia
Lucas Cerdan is a senior product manager at Algolia, a fast-growing

SaaS search company, and the co-founder of La Product Conference.
Dan Olsen
Product management consultant and author
Dan Olsen is a product management consultant and author. At Olsen

Solutions, he works with companies to build great products and
strong product teams. His clients include Box, Facebook, Box, One
Medical Group, and Medallia.
Dan is the author of the bestseller The Lean Product Playbook. Prior to
consulting, Dan was a product management leader at Intuit. Dan is
also the founder of Lean Product, a monthly speaker series in Silicon
Valley with over 7,200 members.
Braden Kowitz
Co-Founder and Product Designer at Range Labs
Braden Kowitz is a product designer and co-founder at Range Labs,

where he builds software that solves team’s toughest communication
challenges. Previously, Braden was a design partner at GV, a venture
capital fund backed by Google, where he had the good fortune
of working with many truly amazing startups: ClassPass, Slack,
Medium, HubSpot, RetailMeNot, Nest, and many more. During his
time at GV, Braden co-created the design sprint process, which he
cited in Sprint: How to Solve Big Problems and Test New Ideas in Just
Five Days, and designed many of Google’s early apps. You can find
out more at kowitz.co.
Kat Kennedy
Chief Product Officer at Degreed
Kat Kennedy is a problem solver, passionate about making great

products that help people lead more productive lives. As part of the
founding team at Degreed, she has helped build an award-winning
platform that uses data (about content, jobs and skills) to help you
continuously build and measure the capabilities you needs next.
So you can keep your business and your people’s careers moving
forward. Every day.
Alicia Dixon
Senior Product Manager at Hilton Worldwide
Alicia Dixon has over a decade of experience building consumer and

enterprise technology solutions, which evolved into a specialization
in mobile apps. She enjoys focusing on new product development,
product strategy, and market research. Alicia has held positions at
leading companies including Hilton, UPS & Dell. She is a proud
alumnus of Howard University where she earned her Bachelor’s
degree. In addition, she holds an MBA from Baruch College, CUNY
and an MS in Marketing from the University of Alabama. She loves
travel, especially to beach locations, and she has a goal to visit all
50 states ( just 8 left). You can connect with Alicia on Twitter at @
Li_Li_D.
Daniel Elizalde
IoT product management coach and advisor
Daniel is an IoT coach and consultant who helps product leaders

develop successful IoT product strategies. He has 20 years of
experience in managing the lifecycle of IoT products in many
industries, including manufacturing, automotive and renewable
energy. Daniel teaches IoT Product Management online, and at
Stanford Continuing Studies. He is also the host of the IoT Product
Leadership podcast and writes about IoT Product Management in his
popular blog at danielelizalde.com.
John Cutler
Product Evangelist at Amplitude
John Cutler is keenly focused on user experience and evidence-

driven product development. He mixes and matches various
methodologies—jobs-to-be-done, Lean UX, Lean Startup, customer
development, and design thinking—to help teams deliver lasting
outcomes for their customers.
John currently works as a product evangelist at Amplitude. As a

former UX researcher at AppFolio, a product manager at Zendesk,
Pendo.io, AdKeeper and RichFX, a startup founder, and a product
team coach, John has a perspective that spans individual roles,
domains, and products.
His viral enthusiasm has been heard through speaking/teaching

engagements at Front, Oredev, Mind The Product, Agile 2015, Heart
of Agile Philadelphia (2016), and various ProductCamps (Vancouver,
Los Angeles, Raleigh NC) and MeetUps (Santa Barbara, Los Angeles,
New York). John’s talk on Feature Factories was voted one of the Top
10 Product Talks of 2017.
Tasha Drew
Product Manager at VMWare
Tasha Drew is a customer centric technical product management

leader, who has spent her career working on development of platforms
to enable enterprises to graduate to cloud native technology with
legacy and greenfield applications. Her focus is on B2B platform
technology with an emphasis in SaaS, PaaS, cloud and datacenter
computing and automation. She holds an MSM from RPI, and a BSc
CSCI from USC.
Ash Maurya
Author of Running Lean, Scaling Lean, and Creator of Lean Canvas -
Helping Entrepreneurs Everywhere Succeed @LEANSTACK.
Ash Maurya is the author of two bestselling books “Running Lean”

and “Scaling Lean”, and is also the creator of the highly popular one-
page business modeling tool “Lean Canvas”.
Ash is praised for offering some of the best and most practical advice
for entrepreneurs and intrapreneurs all over the world. Driven by the
search for better and faster ways for building successful products,
Ash has developed a systematic methodology for raising the odds
of success built upon Lean Startup, Customer Development, and
Bootstrapping techniques.
Ash is also a leading business blogger and his posts and advice have
been featured in Inc. Magazine, Forbes, and Fortune. He regularly
hosts sold out workshops around the world and serves as a mentor to
several accelerators including TechStars, MaRS, Capital Factory, and
guest lecturers at several universities including MIT, Harvard, and
UT Austin. Ash serves on the advisory board of a number of startups,
and has consulted to new and established companies.
Ash lives in Austin, TX.
Scott Baldwin
Director Product Management at Thinkific
Scott is the Director Product Management at Thinkific. Scott is

passionate about the interaction between people and products and
has worked in various product and UX roles over his 20+ year career in
technology. He’s an active participant in the product community and
has spoken at various events including ProductCamp, Agile Vancouver,
WorldIA Day, Style & Class, and ProductBC. Scott has a Diploma in
Music from Grant MacEwan College; an Award of Achievement in
Web Analytics from the University of British Columbia; a Certificate
in Product Management from Berkeley Haas School of Business; and
has completed Pragmatic Marketing product training. Outside work
you’ll find Scott running in the forest, mountains, and roads as an
ultramarathoner and occasionally behind a drum kit wishing he was
Taylor Hawkins.
Bruce McCarthy
Author, Speaker, Founder at Product Culture
Bruce McCarthy is a serial entrepreneur, prolific writer, organizer,

and sought-after speaker at product management, agile, UX,
and innovation events around the world. He helps companies
like Vistaprint, Localytics, Huawei, Nuance, and Zipcar achieve
their product visions through workshops, mentoring, and team
coaching. Bruce founded Product Culture to help communicate the
key principles underlying consistently successful product-focused
organizations. He leads the Boston Product Management Association
and is a head judge at the annual Harvard Business School New
Venture Competition. Bruce’s new best seller, Product Roadmapping
Relaunched: How to Set Direction While Embracing Uncertainty is now
available from Amazon.
Jeetu Patel
Chief Product Officer at Box
Jeetu Patel is Chief Product Officer at Box. He leads the company’s

overall product and platform strategy, driving Box’s long-term
roadmap and vision for cloud content management in the enterprise.
Previously, as Chief Strategy Officer and SVP of Platform at Box,
Jeetu led the creation of the Box Platform business unit, overseeing
product strategy, marketing and developer relations. He grew the
team from a nascent product to a revenue generating business
line and key element on Box’s overall suite of offerings. He also led
corporate development & M&A strategy as well as Box for Industries.
Before joining Box, Jeetu was General Manager and Chief Executive
of EMC’s Syncplicity business unit which he grew from $0 to $100M in
2.5 years. Prior to EMC, Jeetu was president of Doculabs, a research
and advisory firm co-owned by Forrester Research focused on
collaboration and content management across a range of industries,
including financial services, insurance, energy, manufacturing and
life sciences.
Jeetu holds a B.S. in Information Decision Sciences from the

University of Illinois Chicago.
Kurt Heinrich
Product Manager at Shopify
Kurt Heinrich is a product manager at Shopify where he helps

simplify logistics for online retailers. His foray into product
management started when he built and sold his company, HubLogix,
a SaaS product to help online retailers automate their dropshipping
operations. In his free time, he enjoys playing hockey as a goalie and
taking care of his two Irish greyhounds.
Courtney Machi
Director of Product at Toptal
Courtney is the Director of Product at Toptal, a fully remote online

freelance marketplace, leading cross functional teams responsible
for building and scaling Toptal’s platform and products. Courtney
has over 10 years of experience launching successful products
at both multinational companies and startups. Prior to Toptal she
was Director of Product at Anaplan, helping lead the enterprise
planning & modeling company through hypergrowth to become a
$1B “unicorn” and an eventual IPO.
She is passionate about Toptal’s mission to change the future of work

and brings that to her day-to-day approach to problem solving and
thought leadership. She holds a BSc in Information & Computer
Science from the University of Pittsburgh. Check out www.
courtneymachi.com to get in touch or learn more.
Roger Dudler
Founder & CTO at Frontify
Roger Dudler, Founder & CTO at Frontify, 34, born in a small city
in eastern Switzerland, worked as a software engineer and product
designer in the software industry for over 10 years. He’s a father of
a 3-year old boy, living in the city of St. Gallen. Before Frontify, his
first startup, he worked on several software products ranging from
governmental to weather forecast applications.
C. Todd Lombardo
VP Product & Experience at Vempathy
Data nerd. Design geek. Product Fanatic. Product-guy who believes

‘product’is not the right fit for today’s data-driven, experiential world.
I focus on building and mentoring teams in areas of user experience
design, product management, and product strategy. I serve on the
adjunct faculty at Madrid’s IE Business School, and Baltimore’s
Maryland Institute College of Art where I teach courses in design,
innovation, and data visualization.
I co-authored a book on Design Sprints (2015) and Product

Roadmapping (2017), both published by O’Reilly Media.
Rachel Wolan
VP of Product at Euclid
Rachel is a seasoned product executive, bringing over 15 years of

experience in B2B SaaS product, engineering and analytics. She is
responsible for the Product and Design team at Euclid. Prior to Euclid,
Rachel was the Head of Product at Talkdesk (backed by Salesforce
Ventures and Draper Fisher Jurvetson). She grew the product into
an enterprise-grade call center platform that scaled to support tens
of millions of calls per month, tens of millions in revenue and ran
a globally-distributed Product and Design organization. Before her
role at Talkdesk she spent several years in product and engineering
roles at HP, Facebook, Pearson, and Say Media. She received a BS
from Northwestern University and an MBA from the University of
California at Berkeley.
Tim Herbig
Product Leader, Author, and Speaker
Tim Herbig is a product and business leader, as well as a prolific

speaker and author of the book Lateral Leadership: A Practical
Guide for Agile Product Managers. Over the past eight years, he held
product leadership roles at large-scale companies such as XING
and Gruner+Jahr, as well as multiple startups in the SaaS and social
network space. He also co-organizes the Product Tank Hamburg
meetup to promote the local product management community.
Joe Cotellese
Product Strategist and Coach
Joe’s first professional job involved playing video games for 9 hours a
day. After experiencing early signs of brain rot, he decided to teach
himself how to write software.
His entire career is characterized by this “why not?” attitude.
Joe is currently applying his experience at product development to

help early to mid-stage companies develop a “product first” mindset.
Prior to this, Joe held engineering and product leadership positions
at a number of high-tech companies in the Philadelphia area.
The best way to catch up with Joe is on the website www.joecotellese.

com
Ready to make
excellent products?
www.productboard.com

ACFrOgBMYKPpbWsXOMy2uCljMUqATcjcPt6ROkceyGtrGiYTfGrOpJKdpB2 n8KJbeVR 7n - mH5YTu0SsgCYBYiceAO8z32h 5JvrfCw0Q0wxJCLMvI0YTal2haSYaY

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ACFrOgBMYKPpbWsXOMy2uCljMUqATcjcPt6ROkceyGtrGiYTfGrOpJKdpB2 n8KJbeVR 7n - mH5YTu0SsgCYBYiceAO8z32h 5JvrfCw0Q0wxJCLMvI0YTal2haSYaY

Загружено:

Авторское право:

Доступные форматы

THE PATH TO

Deep User Insight

How to find your customer’s story 9

Don’t think “solution” too early 15

The problem with personas 19

Fall in love with the problem, not the solution 23

Build trust by championing the user 27

How to define your product strategy 32

When you don’t know how to fix your product 39

What you’re delivering as a product executive 44

Focus on your product by eliminating bad habits 49

Be strategic about chasing new trends 54

Answering tough questions with your product story 58

Your product strategy needs an owner 63

Build momentum by focusing on traction 67

Focus your roadmaps on outcomes, not outputs 80

Small teams build companies 85

Working remotely can make you a better product manager 97

Manage growth with initiatives and focus 102

Align your product roadmap to your company strategy 105

How to make better decisions around your releases 110

Doing product discovery with a remote team 115

Don’t let your roadmap work against you 121

Contributor Biographies 128

But it wasn’t just Steve. So many members of different teams

Together, they pursued a clear strategy to deliver a unique product

Together, and most importantly, they rallied around a coherent

As a result, the teams at Apple launched something extraordinary—a

These three pillars of product excellence—deep user insight,

We want to thank all of our contributors for graciously offering their

Deep User Insight 9

People didn’t talk about this deficiency, but we realized it existed

Using stories to understand why people make

Deep User Insight 10

“I want those moments when people were

Stories translate into emotion. What motivates a person’s behavior?

Deep User Insight 11

Reviews of competing products are a great starting point. You look

Turning 51 interviews into an MVP

Deep User Insight 12

After the interviews, I spend my time analyzing. So those 51 interviews

“We were able to learn in a matter of days what

Deep User Insight 13

Deep User Insight 14

72% of new products do not meet customer expectations, according

Deep User Insight 15

Milkshakes can be more than a meal

Christensen describes how a fast food chain wanted to increase

Christensen’s team took a different approach. They stationed

Deep User Insight 16

A simple framework to think about framing your conversations with

●● Jobs are what your customers need to accomplish, such as

●● Pains are what your customers want to avoid, such as risk,

These translate to the following questions:

●● What are they trying to get done?

Deep User Insight 17

In framing your conversations, it’s important to remember that

Deep User Insight 18

Your goal is not to create a product—it’s to create customers, lots of

Deep User Insight 19

Because of our name—product manager—we naturally focus on our

Problems and personas

The common theme in my work on product management is the

How to find your customer’s story 9

Don’t think “solution” too early 15

The problem with personas 19

Fall in love with the problem, not the solution 23

Build trust by championing the user 27

How to define your product strategy 32

When you don’t know how to fix your product 39

What you’re delivering as a product executive 44

Focus on your product by eliminating bad habits 49

Be strategic about chasing new trends 54

Answering tough questions with your product story 58

Your product strategy needs an owner 63

Build momentum by focusing on traction 67

Focus your roadmaps on outcomes, not outputs 80

Small teams build companies 85

Working remotely can make you a better product manager 97

Manage growth with initiatives and focus 102

Align your product roadmap to your company strategy 105

How to make better decisions around your releases 110

Doing product discovery with a remote team 115

Don’t let your roadmap work against you 121

Contributor Biographies 128