You're the product manager for a successful existing product.
Probably, your network of collaborators is growing,
they're more people that you're working with and a big part of
your job is to create that happy interdisciplinary intersection,
that's a great product,
and a profitable product,
and a durable product.
How do you do that? Well, for most of us meetings are too long and too many.
If an employee in the USA,
the fully loaded cost is $10,0000 a year,
then that is $56 an hour.
If we get six people together for an hour,
that costs the company $336.
Many people will schedule several of these a week and, maybe,
they spend a couple of grand in meetings every week,
and yet they probably don't have the spending authority
to buy 100 bucks under other circumstances.
Meetings are these weird kind of paradox of modern work life.
And so here, we're going to talk a little bit about how as
a product manager you can create better interactions among these people,
spend less time and create more valuable outcomes for everybody.
In the spirit of the way we've been working,
I'm going to organize these around a few problems to be solved.
And there's six of them.
We'll step through each of them here.
Sharing project visibility. How do we do that?
Well, if you have been around agile at all,
you are probably familiar with these three questions,
which are answered at the daily standup.
The daily standup gets like kind of made fun of because it's
one of these things in agile that if a company does it,
they say we have achieved agile, which is,
of course, kind of a silly thing to say or think.
But it is useful,
I mean, it's there for a reason.
And the deal is if you don't know you have a small agile team of dedicated team,
of somewhere on the order of 5-10 people let's say,
they are the ones that answer these questions.
If they need to discuss anything specific,
they take that offline after the meeting.
Other people in some dispositions of agile are allowed to attend
this meeting but they're not allowed to butt in and start asking questions and stuff.
And so this is a pretty effective way to share visibility.
If each person takes just a few minutes to answer these questions,
and you're a 5-10-person team,
it's not going to be a long meeting.
And why do they called it daily standup? Because people stand.
The goal is not to sit around and chat,
it's to share this visibility and then get out and start doing some actual work.
Another great thing, if you're in
the unfortunate circumstance of
not having a dedicated team that you're working with on your product,
a great thing to do is to create a project room.
So even if everybody is unfortunately working on a couple of different things, maybe,
you can get everybody to agree that
from 2:00 PM to 5:00 PM that's when we work on our project together.
And you can create a project room,
you can put your story map,
if you remember up there,
with your storyboard squares.
Maybe you have a Kanban board where you are moving your story
across from idea to completion.
These are, in agile,
things that we call information radiators.
And so the project room can be a great place to kind of
organically or sort of share project visibility by osmosis.
We talked about, the story map is just such a great tool
to help you on this job of deciding what to build and how to build it.
Stories are not a specification,
they are an input into the development process to
drive better discussions about what to build and how to build it.
And that's really important because people
understand a lot less of what we tell them or what we write for them than we think.
There's this great study that I first saw in the book, Made To Stick,
by the Heath brothers where one party taps out a song.
That wasn't very good,
but say I tapped out a song you would understand like Happy Birthday,
or Row Row Row Your Boat,
and the job of the counter-party that they're tapping
to is to see if they recognize the song.
And the amazing result of this study,
I think it was done at UCSD,
was that 74%, if I remember right,
of the tappers thought that, yes,
my counter-party understood what the song was,
but only like seven percent of them actually did.
So if you think about that,
what if you write all these stories and stuff and
the developers are only understanding a tenth of what you think they're understanding.
That's a pretty shocking result, right?
So this is why it is so important to co-create stories and to keep them visible.
A great way to do it, for example,
is you create these storyboards or co-create them,
write the epic stories and then use the storyboards and
the epics to work with your development team in a story writing workshop.
Just a session you guys block out to do this together,
where they write the child stories and you guys iterate through them together.
Even if you get the exact same quality of story that you would have written by yourself,
you may have made
a 10x difference in how well they're actually understood when they go and implement them.
So I would really consider that as you're deciding what to build and how to build it.
The asymmetry of information,
the variability of understanding is probably a lot greater than you think,
and that good product manager works really hard to resolve that.
Alex CowanFaculty & Batten Fellow
