Product managers are the glue that holds everybody
in the company together — business, builders
A product manager is a guard with a T-shaped profile,
that creates common ground in the company by
gathering and sharing the right information.
The main groups to protect are your customers,
builders and business — from each other.
Everybody in your company has different goals
and expectations. To make that work, you need to
figure out what each group wants and how they can
succeed. Then you can help them align their goals,
and help them reach their goals together (or help
them change their minds).
To be able to fulfil that role as a guard, a t-shaped profile
The vertical bar | respresents your base, a solid foundation
in management, for instance in a particular field like
business, design or development. This base allows you to
empathise, talk and connect with people.
The horizontal bar — represents your knowledge and
interest in development, design, business and other fields.
You understand what drives your colleagues, and what
You have to understand why your developers need to
refactor and why it might take a long time. You need
to understand why your designer needs a ui kit. But
you also need to understand why your company needs
money now, and why you need to ship this feature now.
And you need to understand your customers, be able to
communicate with them and figure out why they are
asking for those crazy features.
To tackle this challenge I have some tricks for you, a
process, that I learnt from making mistakes and other
people’s mistakes. This process is not set in stone.
I encourage you to make your own mistakes, and to find
your own style.
In this process, we focus on an iterative approach — one
you adapt along the way to fit your company. It allows you
to hold on to something, to start seeing patterns, where
things went wrong and what went right.
Find out what makes your customers tick, and what
frustrates them. The focus here lies on quality, so
make sure you talk to interesting and relevant people:
your target audience.
A quantitative survey will not help you here, but it can serve
as a starting point, something to hold on to. Make sure you
go deep enough, and don’t try to get the answers you want
to hear. Not influencing your interviewee is harder than you
think, it takes practice. Listen, and ask why.
The goal here is to get the conversation started. You can ask
why again and again, until you forgot your initial question.
As long as you get a good answer that helps you figure out
what they really need.
In the next phase, you can start card sorting. You gather the
customer needs from your in-depth interviews, print them
out and let members from your target audience sort the
needs according to what they think is important.
Take feature requests and input with a grain of salt.
Let your interviewees inspire you, but do not lose track of
your own vision.
Interviewing a lot of people — and different types people
is important. But finding the right ones is not easy.
Expand and use your networking skills to the fullest.
People that challenge you on a deep level are even
harder to find. When you do find those people, keep
them close to you in a customer advisory board. A Cab
with 4 to 5 customers, can help you along the way.
The people in your customer advisory board should be...
• smarter than you
• part of a brand you respect
The quotes on your website will probably be theirs.
You will be spending some time together... have a beer!
When times get harder, they can’t just run away.
After your interviews, go and have some fun with your team. In this
brainstorm, you are going to figure out which problems you can solve
for your customers, based on the needs you discovered.
Including colleagues makes them feel involved, and gives them a sense
of ownership. Make sure you have different types of people in your
brainstorm, for different points of view — for instance a developer, the
CEO, a designer, a sales guy. But keep your brainstorm managable; 4 - 5
people is more than enough.
To make sure the quiet but super smart colleague gets to say something
too, you can ask people to prepare something during or before the
brainstorm and share that with each other.
And if somebody doesn’t want to join... Don’t force ‘m.
There are different types of brainstorms, but you can really go Disney in
this phase. Try to go beyond the obvious features, and challenge your
team a bit. Tough crowd? You can always create a context where it feels
more natural to go a step further.
This brainstorm is based on a game called “The Extra Ordinaires Design
Studio ”. They include a set of fictional characters that serve as potential
customers for your product.
I like creating my own characters. One of my favourite examples is the
rusty robot that lives on planet Mars. He’s rusty, old, but has a heart
for nature and tries to collect all the garbage he can find. Do you see a
business model for him? Could he collect garbage from other planets?
Are you the oil that can make him move quicker, or will you be the
system that helps him communicate with other robots?
It’s important to support each other in this craziness, and go on with
“Yes, and...” instead of “no, because..” or “but”. Because you really want
to step outside the box.
An other type of brainstorm that gets the ideas flowing, is based on
your target audience’s day. Create personas that represent your target
audience in advance, so your brainstorm team knows who to think of.
During the brainstorm, you explore how your product could be
of service for your customer on different times of their day: in the
morning, first thing at work, at a meeting, right before going to bed or
when seriously bored. There are multiple possibilities.
A few tips for your personas: please make your them relevant and easy
to read. We do not care what your persona’s favourite color is. What we
do care about, is how they would use your product and how you can
make them happy. If you want more guidance, I have written a blogpost
on how to create those personas (link to template in comments).
When you have a nice list of crazy ideas, you can start tearing them
down. Take feasibility and usefulness into account, and pin down what
you are going to build. This chart can help you figure that out — the top
right represents the feature you want to be building, what’s left for you
is to decide which ones you’re going to tackle first.
If you are having a rough time deciding what feature goes first, go back
to your personas. When you know what persona is most important to
your company, and what feature is most important to that persona, you
will know what to build first.
Let’s start building. To help the team understand what the feature is and
how to build it, you can create a feature spec.
The spec includes information for different members of your team. Do
not expect everybody to read it entirely, and do not have them create the
spec themselves. You will visit your team members to gather information,
evaluate and refine the feature spec, and you are going to write it.
A spec supports you to make good decisions, and make it easy to iterate
on your initial idea.
(link to the template in comment)
Step 1: write the feature spec.
Make sure you have the full story of your customer in mind: where are they coming
from, what are their expectations, how are you going to help them complete their
goals and do other features need to be adapted to make this one work better.
Step 2: ask feedback from your stakeholders.
Check if this is what for instance your CEO or co-founder had in mind when they
thought up the feature. Rewrite where needed.
Step 3: ask feedback from your customers.
Show your plans, for instance mockups or a flowchart, to one or more relevant
customers. One is better than none. Rewrite where needed.
Step 4: ask feedback from your builders.
Ask developers, designers, marketers) to check if they see any gaps, if you missed
anything and if this is feasible. Rewrite where needed.
Step 5: iterate until you are confident.
Make sure your feature spec is written in an easy-to-adapt format, so
you will not waste time on editing. Some people like to use google docs
or github pages, others like to make a whole website where they can
include clickable prototypes.
Investing some time in figuring out how to create a clickable prototype,
is going to help you a lot in the future.
Make them accessible to everyone at all times, and keep them in the
same format so people will know where to look for what.
Show your product,
even when it’s not done.
Feelings of shame disappear eventually.
It can only improve your product!
You are going to take these steps a couple of times, not necessarily in
this order. Interview, brainstorm, select, prioritise, spec, test. You will
get better at the process step by step, and you will be adapting your
flow along the way. The same goes for your target audience: the more
time you spend with your customers, the better you will know what
they need. Keep your personas up to date.
The most important part of the process, is feedback. Get as much
feedback as you can, as early on in the process as possible, from anyone
really. I do not care how you do it, show your product on a piece of
paper for all I care, but do it.
Big Bertha lists all of your features, to help you keep a bird’s-eye view
on your product. She remembers who these features are built for
(personas), the status of those features and what improvements you
Big Bertha is for your eyes only, because she only represents the
present, and does not prioritise. Make her as extended, ugly or beautiful
as you like. As long as you keep her alive — she will be your guide
through the jungle.
Big Bertha will make it easy for you to create a backlog. A backlog is a
list of important features and bugs, maintained and prioritised by you.
Some companies like to cluster features into user stories: a set of
features that enable a persona / your business / a type of user to
accomplish a goal. This user story is focused on the experience, and to
make sure your features are delivered in a context, and not as a stand-
alone feature. Other companies like to go really far and cluster these
stories into epics — fulfilling a need of a user. Figure out what you need
for your company, and find your own lingo and style.
The backlog will be the fuel for your team. It needs to be accessible at all
times, because this is where your colleagues will find their next mission.
From here, you will have to let your features go. You have prepared
everything as well as you could, received tons of criticism and feedback.
It is your team’s responsibility now to bring your features to life.
After your feature’s first baby steps, it will come back to you crying
things are not working. You adjust some personas, do an other
interview and maybe have a brainstorm, rewrite your feature specs,
update Big Bertha and the Backlog: you iterate.
A backlog is the fuel to your team’s engine.
Assess & pick features every week.
Chop the features up into
bite-sized tasks or issues,
To do Doing In review Blocked Done
and start sprinting.
This is where your team’s mission start. There are millions of ways
to structure your development flow. Some people like scrum, others
like agile. I do not care what you call it or what framework you use,
but the trick is again to find your own flow.
These are the main goals of a good development flow.
A good flow, gives you control over time and output. It does not create more
problems (duh!) but gets them out of the way.
Transparency towards team members and clients, manages expectations.
A good flow facilitates communication on specific moments you agreed upon,
without interrupting people on other times of the day.
Quality & growth
With a good flow, your team members can take responsibility for their work, which
helps them improve themselves, and your product. Encourage autonomy. You want
good team members to stick around. Create an environment they can thrive in —
because there’s more to work than earning money.
You and your colleagues need to be able to communicate goals and
expectations on a regular base. You collect that information, get the
word out about what needs to be done and help them get it done.
∙ Gathers product goals from teams, investors & clients
∙ Prioritises tasks
∙ Share what the team needs to execute tasks & do a good job
This is an example of how you can structure, challenge an motivate
your team. Feel free to research other types of development flows to
see what works for your team — this is just the tip of the iceberg.
I like to work with the terms Marathons and Sprints. The term
marathon reminds you that you’re in it for the long haul, and the
term sprints keep you focussed on getting things done.
A marathon consists for example out of four weeks. The first three
weeks are focussed on sprinting, the last week is meant for zooming
out and cooling down.
The marathon gives you control over your time, and focus on a
steady pace to ensure quality.
The preparation of a marathon happens in the cooldown week of the
previous marathon. The product manager gathers information.
The preparation of your marathon during cooldown week, allows
you to communicate with your team members without bothering
them while they are doing focussed and zoomed in work.
∙ Check Big Bertha & road map
∙ Consult all teams for bugs and requests
∙ Check team availability (holidays etc)
∙ Discuss & plan features in backlog for coming three weeks
During the sprint weeks, your builders pick and assess features from
the backlog. Preparation of a sprint week starts at the beginning of
The sprints help your team to decide what they are going to do and
when, to take control over their own time.
∙ Pick features from marathon backlog for 80% of the week —
leave some room for mistakes. If there’s time left, there’s always
more in the backlog.
∙ Clarify what you need to get it done (what, when, who)
∙ Chop up features into clear, detailed issues & tasks
∙ Assess the features, and assign a colleague
There are multiple ways to make estimates for these features, scrum
poker is one of the examples that focuses on how hard it is, instead
of how long it wil take. Research techniques to find out what fits
This will definitely fail the first couple of weeks: do not give up!
It takes time and practice to master this valuable skill.
To do Doing In review Blocked Done
Every day communication
During your sprint, make sure your colleagues know what you have
been up to. Some people like 15 minute standups (in real life or via
calls), others like to automate it with a system like Jira, Kanban Trello,
Github issues or excel. Find your way to keep each other informed.
The daily updates make communication easier and sure you know
what your colleagues have been up to, and where they need help.
1. What did I do yesterday?
2. What am I doing today?
3. What do I need?
The cooldown allows your team to debrief, show & tell what they have
accomplished in the previous weeks, and get up to speed with others.
Share your stories with stakeholders and (future) clients. Have sales
spice up their pitch.
Cooling down allows you and your team to zoom out, correct
mistakes, improve and refactor where needed. This is also an ideal
moment to study a little, talk to a mentor or finish a project.
The cooldown gives you and your team the time to assess your own
ability and what you have accomplished — which focuses on quality
and (personal) growth.
The product manager gets the time to prepare for the next battle;
a new marathon.
This is one way to tackle your development flow. Get inspired, and
do not lose track of the actual goals of your development flow.
Practice and adapt, do not just throw away your efforts if your flow
fails the first couple of weeks.
A road map is a document that helps you to motivate your team, to
convince investors and to get an idea of what you are doing. When
you reach a milestone, it is an excuse to get out the champagne with
But it is not set in stone — a roadmap is based on ever changing
things like ideas, money, big bertha and personas. So your roadmap
will change accordingly. We can not see into the future, the further
away the more vague it gets, so don't hold on too tight.
You can base your roadmap on numbers like clients or money, on
the personas you want to reach or the user stories you want to tell.
Q1 Q2 Q3 Q4
Napoleon LafawnduhKip Deb
A roadmap gives your team something to strive for. It fuels your
marathons and your backlog. Share it every few months, but do not
go waving it into people's faces every day. Your road map gives you
a sense of direction, it is not a promise set in stone — because your
company will change every day.
When doing this job, things will not always go as expected. Not only
will your process not go in the right order, you also will not be able to
complete all of the steps the way you wanted to.
Have confidence, get up and try again. People will be looking at you
when things go wrong, so you better toughen up and prepare for battle.
You will get better at it, and find a flow that takes your company to the