1.
W R A N G L I N G P E O P L E
P R O D U C T M A N A G E M E N T

2.
J A N E T B R U N C K H O R S T
@ J A N A K I N
• Product Manager, Carbon Five
• Head of Digital, Asian Art Museum of San Francisco
• Digital Consultant
• Head of UX, Lonely Planet
This is kind of my resume. Mostly to show that I haven’t ever been called a PM before, thought I’ve been doing it for about 10 years! Also because I want
to make clear that, while I’m in a client services organization now, I’ve spent much more time in-house, with ongoing responsibility for the products I was
managing.

3.
So, you become a product manager. Like you all are. You think you’re going to manage a product. And you are. But a lot of the time that might mean
you’re also managing a team. You may or may not be the Team Lead. You may or may not manage any direct reports. Doesn’t matter. Products get built
by people.

4.
A lot of my job is about managing people to enable them to build great products. That was as true when I was head of UX at Lonely Planet as it is now in a
client services context. I’m going to give just a very quick overview of some of the ways I work with teams, and then leave lots of time for you to ask
questions.

5.
My friend and mentor once described me as “the glue” that held everything together on our huge project. I managed senior stakeholders and led the
design team and worked with developers on bugs and advocated for the user in prioritization across a suite of products. Sometimes, but not very often, I
thought more about products than people. But most of the time, it was people I was concerned with.

6.
S TA K E H O L D E R S
This one is big and scary so let’s get it over with. Stakeholder management can be really, really hard. Depending on your role, it may or may not seem like
your job. But unless you’re a startup building your own product, you are almost always dependent on good stakeholder management.

7.
S TA K E H O L D E R M A N A G E M E N T
• Identify your allies
• Get buy-in
• Minimize surprises
Here’s a horror story. I’m not going to share the project or the organization. I led a big project. There were many, many senior stakeholders; I did awesome
stakeholder management. I created a steering committee and met with people 1:1 and made sure that this huge unwieldy group was on board
throughout the process. And then we launched. And the next night I started getting increasingly hostile emails from an irate senior manager who was
upset about her department’s representation in the navigation. It was totally out of left field. The change was minor, it fit with the new site structure. She
wasn’t on anyone’s list of stakeholders. I assumed, wrongly, that the leadership team would be sharing with their peers. Total fail. At the other end of the
scale, you can go out of your way to make sure that stakeholders are in the loop. On the LP redesign I spent a huge amount of time doing incredibly
inefficient communication. I met 1:1 with everyone who thought they ought to have a say. I walked them through designs. I made notes of their feedback.
I consolidated everyone’s feedback and sent it back to the group. Then I communicated the feedback to the design team. No one has time for that. But
consistently we had less friction on the project because no one ever got a nasty surprise when something new went live.

8.
V I S I O N A R I E S
We need them. We love them. Maybe some of you are them. But if you’re going to be a PM, you need to know how you get from vision to
implementation. And most visionaries have ZERO IDEA of how to do that.

9.
V I S I O N A RY M A N A G E M E N T
• Get the ideas out of their heads
• Check in constantly
• Prioritize
On a recent project we were working with a visionary product owner who had never worked in software before. He was a subject matter expert. He had a
great idea. He had no idea how to articulate it in a way that anyone could hope to build. A lot of my job on that project was to get ideas out of his head
and translate them into something the team could build. That meant a LOT of facilitation. The most fun thing we did was to create an algorithm on index
cards. Because the client team had never worked in software before, talking in abstractions was incredibly hard for them. We were trying to build a
feature, and found that it wasn’t working the way they had imagined it; there were too many business rules, too many variables. We proposed creating an
algorithm that would deliver the content in the way they wanted based on patient feedback within the app. But instead of describing it, we showed it to
them. We put a piece of content on each card. We established a set of rules. Then we had them play it as a game. We delivered the first set of content
cards to the user. Then we had them tell us what feedback the user gave the system. And the algorithm did its thing; the next set of content was delivered
based on the users’ feedback. And on we went. When the content delivered was off, we adjusted the rules and played again. By the end, we had the basis
of an algorithm that could deliver medically appropriate content to users based on their feedback. And we did it all without having to explain what an
algorithm was!

10.
T H E P R O D U C T T E A M
My favorite part of being a PM is working with developers. I like designers too, and I used to manage a design team. But working closely with a developer
to solve hard problems is where it’s at for me. Forming close working relationships with your team so you’re all pulling the same direction to make an
awesome product feels amazing. But.

11.
M A N A G I N G T H E P R O J E C T T E A M
• Protect the team
• Be nice, but let it get uncomfortable
• Chocolate
Sometimes teams don’t work well together. No great product is getting built if that’s the case. So what do you do?
Sometimes, it pays to let things get uncomfortable. This takes some finesse. I definitely don’t always get it right. But it’s worth practicing. Good ways to
start are making sure that your team is addressing difficult issues in retros/reflections. Sometimes I will deliberately seed a topic I think might otherwise go
unsaid in order to let other people talk about it. Sometimes I’m more blunt. I’ve been using a tool called the Product Dartboard, which helps identify areas
where a team might need to focus in order to deliver a successful product. Recently in a client kickoff I deliberately pushed on an area where the team
seemed not to be aligned. It was mostly an engineering team, clearly not used to any kind of confrontation. They were pretty uncomfortable. I’m not sure I
got it just right in that case, but we definitely learned something valuable about that team and where they’re at.
And if you’re not sure what else to do, you’d be surprised how effective chocolate can be at boosting a team’s morale.

12.
Q U E S T I O N S ?