35. Product Tree
Team: 5-8 people
Time: 2-3 hours
Trunk = core
Branches = product areas
Leaves = features
Roots = infrastructure
Result: Product Roadmap
Template: bit.ly/producttree/
Play games
Source: Innovation Games
36. Product Tree
Team: 5-8 people
Time: 2-3 hours
Trunk = core
Branches = product areas
Leaves = features
Roots = infrastructure
Result: Product Roadmap
Template: bit.ly/producttree/
Play games
53. What could
possibly go
wrong?
Made up release dates
Death marches
Mismanaged expectations
Missed market opportunities
Building the wrong thing
Sad product managers
76. Thank you!
I’m Janna Bastow
Let’s go for or and talk product
to @simplybastow or janna@simplybastow.com
Slides and more info at roadmapclinic.com
Notas del editor
I want to talk aboutthe one part of our jobthat we can all agreeis the hardest…
People!
And people are hard.
They’re unpredictable.
They have office politics,
and opinions,
and are wrong an awful lot,
and there’s this whole bunch of them
who have more power and salary than you
and yet they’re wrong just as much
as the rest of them!
Yeah. People are hard.
So how did we end up here?
For me, it started with my first job out of college:
I was a customer support rep working for a tech company
This company, in its entire history,
had never had a single product manager.
Our engineers felt like
they had no clue
what they were building
and why.
Sales and account managers
felt like their voices
weren’t being heard.
Their suggestions
would end up
in the black hole
known as Bugzilla
And on top of that,
they had a culture of treating their customers with…
what I can only describe as disdain.
It was frustrating!
Every day, I had to be on the receiving end
of angry phone calls.
It was hard to defend the customers
from my little cubicle!
I was persistent though.
I did everything I could
to close the gap
between the customers and the rest of the business,
and it got me noticed.
One day,
my boss pulls me aside
and says…
“I like the way you call bullshit”.
He wanted to make me a
Product Manager…
-
and I was like
..
.
Great!
.
..
...
What’s that?
I went back to my desk
and I Googled.
And found…
not much help at all!
So I did what I’m sure
many of you in here
did too…
I took on a role
I didn’t know anything about
and made things up as I went along!
I learned pretty quickly
that there were a bunch of roadblocks
getting in the way of me building good products.
======I had to traverse a stack of bosses
to get buy in for every initiative.=====
I had to get account managers
to trust me with their input.
I had to get the engineers
to understand the plight of the customers.
I had to get sales
to stop selling things we didn’t have.
If I could master this,
I could become an awesome product manager.
But, people are hard.
I had a sales gig back in college..
And it wasn’t even a hard sales gig.
It was selling pet food.
And frankly, selling pet food
to adoring pet owners
isn’t exactly a hard sell.
Even still, the training was intense!
We had monthly gatherings to do
role playing exercises.
We had secret shoppers and scripts.
We were trained to deal with people.
And in my new life
as a product manager?
My training was..
…Google.
And so I fell back on what I already knew.
It turns out that
out of all of the previous gigs I’d had before,
including as a graphic design intern,
self-taught coder,
hell, even my business school learnings!
the sales stuff was what
prepared me the most.
Over my career,
I’ve picked up a big pile
of tricks and hacks
that I’ll share with you today.
These survival tactics
will get you through the hardest parts
of your role.
One of the hardest challenges you’ll face
is getting people aligned…
..particularly if
they have different bosses
and different objectives than you.
It leaves you with very little leverage
when it comes to getting their help.
It helps to remember that
it’s not your job to have all the answers.
You’re supposed to know less than your colleagues.
Instead, focus on asking the best questions.
Ask open questions,
and use prompts
to get people to
continue their train of thought:
‘go on’,
‘what else’,
‘tell me what you really think’.
I do these things I call Roadmap Clinics.
People book a call with me
to look into their roadmapping problems.
More often than not,
these meetings turn into what
I can only call…
(therapy sessions for product managers.)
(I can only call)
therapy sessions for product managers.
And in these sessions,
I’ve seen a lot of bad roadmaps.
I’ve spotted a trend:
a bad roadmap is
a symptom of underlying issues
in the company.
And a frustrated product manager
is a symptom
of people and alignment issues
in their team.
Because people are hard!
Now, these stories are real,
but the names and some details
have been changed for privacy.
So let’s meet some of these product people!
Like Craig.
Craig sent me his roadmap
and it was just….
…incomprehensible.
He spent the first 20 minutes of the call
just trying to explain what half of the labels meant,
and what was next on the roadmap.
Some of the acronyms were so obscure
even he didn’t know what they meant!
Because of this, his team suffered.
They were too focused
on the format and feature list in the roadmap,
rather than looking at the bigger picture.
Here’s a test to see
if you’re in the same boat as Craig:
Print out a copy of your roadmap
and bring it to your mom.
She should more or less get
where you are now
and what sorts of things you’re going to do
moving forward.
If your roadmap
is filled with a bunch of features and acronyms
that require you or your scrum master
on hand to translate,
then it’s a sign
there’s alignment issues
lurking within your company.
I helped Craig simplify his roadmap.
If it was going to get alignment,
it needed to tell the STORY
of how they were going to reach
their product vision.
And that strikes at the essence
of being a product manager
– you should be a storyteller.
Stories have massive power
to translate difficult concepts
and to get people on your side.
It’s why we write
user stories and jobs to be done;
why we craft buyer and user personas.
It’s not our job
to be the best coder, copywriter, or closer.
It IS our job to be the best communicator,
and stories,
in our roadmaps, our specs, and every day work,
are one of our best tools.
Laurie was faced with a classic
chicken and egg problem.
Her company had never had a roadmap
and she was tasked with
coming up with something.
Only.. where was she supposed to begin?
I told her to turn it into a game!
Everyone secretly loves a day off
playing with post-its and stickers,
and you can wrap up weeks of meetings
into a single afternoon.
The Product Tree is the perfect game
for starting off on the right foot
with your roadmap.
Find a big blank wall
and put up a tree outline, like this.
The trunk is what you currently have and will build from.
The branches represent product areas, or directions you could grow in.
The roots represent the infrastructure that holds your whole product up.
To play, get your team to write down
as many product ideas as they can
on to sticky notes
Then have them work together
to place the leaves on the tree.
Your job is to lightly curate,
but let them each make their own arguments
for or against the placement of each leaf.
This is your chance to learn
what’s important to each person in your company.
The leaves placed near the trunk
are the features that your team agrees are more urgent,
while the ones in the canopy
are more nebulous and further out.
As your tree grows upwards, your roots should grow downwards,
filling with sticky notes that represent your architecture.
Leaves that can’t be justified
or if don’t match up with your product vision,
should be pruned out.
The end result
is the beginnings of your roadmap.
With this game, Laurie avoided all that pushback
that she would have gotten
if she had simply presented her roadmap.
Instead, she came to them
with the roadmap
that they helped conjure up.
And everyone on her team had a fun time.
Not bad for an afternoon’s work!
Rebecca was a Head of Product
new to her company.
In the interview itself,
several people
broke out in tears.
They were desperate for her help.
Rifts of misalignment and distrust
had grown between product and engineering.
I told her that it was essential
that she reboot the team.
Rally them together around a project,
even if it was just a hackday.
The goal was to give them something
to take ownership of,
to work without the usual constraints and pressures,
to learn be a team again.
She needed to assure every person on the team
that she was on their side and listening.
She needed to build psychological safety
within the company.
It’s about making people feel
more comfortable speaking up,
reporting errors,
and pitching in to help with the product.
Now how do you build this safety
within your own team?
Here’s a couple tweaks to your language
that’ll help create the right environment:
Phrase questions so they begin with
“How might we…”
It turns the issue into a collective problem.
It SUPPOSES instead of ASSERTS.
And it works really well in conjunction with:
“I bet”.
As a product manager,
you’re going to be wrong, a lot.
“I bet” gives you permission
to fail and try again.
After all, it wasn’t YOU that was wrong
– it was your hypothesis.
And now that you know what DOESN’T work,
you’re free to test the next bet.
It’s subtle, but these shifts in language
set the stage for psychological safety.
There’s a dynamic that’s often overlooked
when you’re a product manager.
You’re in the middle,
and often treated as the lifeline to your execs,
even if you don’t have any explicit authority.
If you want your team to always have your back,
make sure you’ve got theirs.
For example, when a point is raised, make a concerted effort
to echo back their opinions,
using the name of the person.
“I like what Sam just said, when she suggested we so-and-so”.
“Mark had a great point about that earlier”.
Elevate the voices of those around you
to make your team feel valued.
And always bring the donuts.
You can’t do your job
without immense amounts of input
and help from your team,
so do what you can
to make them feel appreciated.
Okay, well
donuts may fly for those around you,
but they won’t always cut it
when you’re managing up.
Let’s talk about ways
to survive even the
pointiest-haired of bosses.
Have you met Ted?
I met with Ted, and Ted was pretty pissed off.
His entire roadmap had just been ditched.
The CEO, on a whim,
had conjured up a new direction.
In Ted’s mind, this was a path to destruction.
So far, it had led to a couple big blow-ups in the team,
and he was on the verge of leaving.
It seemed that
Ted believed he knew the best way,
and his CEO believed he knew a better way.
Both were going on gut feel, though.
Now, I don’t know if Ted was right or wrong.
But I did know that if he was going
up to bat against his boss,
he’d better have more to show for it
than a gut feel.
He needed data and a story to go with it.
I recommended that he play a game.
Product Box is a storytelling game.
It’s perfect for when you need
a lean validation tool
for a new pivot or feature.
It’s also tons of fun
and was going to
take the pressure off the already stressed out team.
Start with a bunch of crafty materials:
cardboard, stickers, markers, tape,
whatever you can get your hands on.
The product box is like something you’d find
at a trade show or in the cereal aisle.
By the time you’re done, it’ll be covered
in what your team thinks are the biggest selling points.
Practice selling your box to other groups,
and get a feel for what sticks.
Ted played this with his CEO.
It turns out, there was merit in both of their approaches.
And because he got his team involved,
they learned a bunch of other things
that would also play into the product direction.
The new roadmap was way more cohesive,
and was something everyone on the team
could get behind and believe in.
Meet Penny. Penny had been told
that the company she was joining was agile.
NOBODY knew agile better than them,
they said.
Except when she saw…
…their 5 year roadmap.
And this was no ordinary roadmap
– it was a feature by feature list
outlining the rebuild of an entire legacy system.
According to her execs,
the roadmap was set in stone,
It had no scope for experimentation,
and had to be delivered all at once.
go wrong? What could possibly go wrong?
helped. I helped Penny.
break down We looked for ways to break down the project
into MUCH smaller deliverables,
client hands and get it into client hands
ASAP as soon as possible,
years instead of years from now…
learn, grow From there, she could learn and grow the app.
permission If only she could get permission.
None, happen None of this was going to happen
until mgmt team until Penny got her management team
on board, plan on board with the plan.
Knew, stand ground She knew she had to stand her ground
risk watching or else risk watching this company
waterfall, oblivion WATERFALL itself into oblivion.
pointers I gave her some pointers
defend to defend her position:
Penny was being asked to commit
to launch dates
months and years in the future.
So she armed herself with this argument:
I don’t know when those new devs are going to start,
let alone how long it’ll take us to build it.
Without putting a ton of resources
just into the planning itself,
you know we’re just making this timeline up.
You know what execs hate?
Wasting time and money.
So hit ‘em where it hurts!
I helped Penny with a spreadsheetthat compared the cost of the 5 years development,against the potential costs of building the wrong thing.
Penny showed them the money.
Her bosses came around to the fact
that the roadmap was full of things
that might not matter
by the time they got around to launching them.
Instead, their resources
were better spent experimenting and iterating.
You’ve heard the saying
“No roadmap survives contact with reality”
Well GOOD.
Just as your first prototypes and MVPs
are going to get trashed by early customers,
your roadmap is meant
to change and adapt as you learn more.
Having a massive, fixed roadmap
doesn’t give you the chance to be agile in the long run.
Penny is in a much better place now.
Some execs surround themselves
with people who agree with them.
Don’t be one of those people.
-
Speak up when you’re told to cut corners.
It might be an awkward conversation today,
but think of the tech debt
you’re saving your product from down the line.
Call bullshit when you see it.
You’re going to find yourself in awkward conversations.
There’s an art in getting people back on your side,
even if there is a disagreement.
Dave talked about saying no earlier...
And here’s another one:
The Yes, and....
is an old improv trick,
a sales trick that I learned:
Use it to agree with the person and their premise,
and then rework it in a way that
bridges the conversation back to your agenda.
It moves the conversation back on track.
It also helps you negotiate for what you want
without shutting them down.
Get to know the executives in your company.
Communicate in a way that makes sense them.
Find out what their objectives are,
how they’re being rewarded,
and figure out
what problems you can solve for them.
You’ve all heard Steve Blank’s
age old advice of
Get out of the building.
Let’s to add to that:
Get in the building.
Go up a floor to where your execs live.
But don’t forget about yourself.
Tie together Because while so much of our job
depends on other people,
you’re the one
that needs to tie
all of it together.
Lonely, tough And it can be a lonely, tough job.
Sam, no one else Sam was given the role
because no one else was doing it.
shared From what he shared with me,
shape he wasn’t in bad shape,
right questions and was asking the right sorts of questions.
handle But he didn’t feel like he had a handle on things
pack, underprepared He felt like he was behind the pack and underprepared.
Sam had Imposter Syndrome.
But can I just level with you guys?
Everyone has imposter syndrome.
Nearly every time I jump
on one of these Roadmap Clinics,
the product person I’m talking to
becomes apologetic.
They feel like they should know
more than they do.
You’re not alone.
You’re NOT behind the pack.
We all landed in this role
by happy chance and accident,
and we’re all making it up as we go along!
Don’t let it consume you,
acknowledge it and roll with it.
Having a touch of Imposter Syndrome is good for you.
It means you’re self aware.
No two product managers
have the exact same challenges.
You each have a different set of
people, personalities, and politics
that make up your product culture.
We’re product managers.
We ask for tough feedback
on our product all the time.
But do we do it for ourselves?
Great products are built with learning and iteration.
Great product managers are too.
As is your product culture.
The most important product
you'll ever work on
is your product culture.
It’s defined
by how your team interact
with your product and with you:
Do people feel comfortable sharing suggestions with you?
Do people think and speak in terms of problems that they’re solving?
Are they challenging themselves and pitching in to help with the product?
These aren’t things that happen overnight,
a good product culture evolves.
Reframe a problem as a game,
or tweak your language,
or tell a story.
These are ways you can help craft a healthy culture.
You’re a multi-skilled miracle,
spinning plates and managing products
like the bad-ass you are.
And you can multiply your power!
Great products are always more
than the sum of their parts.
They’re the direct result
of teams who work well together,
who aren’t letting miscommunication and misalignment
tear them apart.
This is stuff that I want you
to take with you and be able to use
this week when you’re back at the office.
But it’s also stuff that is going to stick with you.
These are the fundamentals
that will help turn you
into a product leader.
And the best way to speed up your progress?
Surround yourself with other product managers!
Everyone in this room,
every product person you’ll meet,
has experience they can share.
Get out there and share your stories of
the toughest, hairiest situation you’re in right now.
I guarantee you that you’ll find
a new perspective that will help you
reframe and crack your problem
We may have walked into this role
completely unprepared.
But together,
we can learn how to best work with people,
to build products people love.