The Product Manager: An Agile Software Team’s Camp Counselor
“So what do you actually do?” It’s a question I’ve gotten a lot since starting as a Product Manager at Labs. It’s easy to understand what engineers and designers do, but what role does a PM play?
***
Three years ago I got into a Computer Science graduate program, quit my job (working as a film producer’s assistant in Hollywood), and started planning for my return back east. I left in May and would begin grad school in September. I wondered, “What should I do with my summer?”
My younger brother suggested I come work with him at a sleep-away camp in the Rockies, about an hour west of Colorado Springs. Being a sleep-away camp counselor had always been on my Bucket List, but at 26 I thought I’d lost my chance. As it happened, I spent the best summer of my life as surrogate parent to a cabin full of rowdy, stinky, homesick, adorable, annoying, wonderful 9 year old boys.
***
Two and a half years later I finished my Master’s and joined Labs as a Product Manager. After five weeks of training, shadowing, and asking people that question, I went to Chicago for my first real engagement. I didn’t know my team, didn’t know the domain and didn’t know the product (already over a year into development). I felt thoroughly unprepared to manage anything.
My first day alone on the project was one of the scariest work days I’ve ever had. People kept coming to me with questions, “Adam, is this feature in the newest build?” or “Hey Adam how soon do you think we can push that bug fix?” or “I got this error message again! Adam can we prioritize this?” All I could think to do was furiously take notes and say, “Umm, can you email me more information?”
Worse, the project was in dire straits — a recent disaster had triggered new data restrictions, client distrust and high stress levels. We also lacked a single empowered Product Owner. The different departments within the client company vied for attention and control, while none of them committed themselves to being the “Decider.” The developers were frustrated that we had no data with which to test/accept new features. The business liaison was frustrated that we weren’t building new functionality. The designers were frustrated that designs approved by one department would be decried by another.
The project was at a dead stop.
***
Being a Camp Counselor was simultaneously the best and most exhausting thing I’ve ever done. As the surrogate parent to 12 little humans, I was working 24 hours a day. Sometimes I just lay in the sun and watched kids play capture the flag. Other times I cleaned vomit out of a kid’s bunk at 3 am.
Every single kid was wonderful, but each had his own challenges. Some kids got very homesick the first week. Some didn’t like playing sports or being active. Others struggled to sit still or focus on a single game for too long.
One my most challenging campers we’ll call “Jack.” Jack was slightly older than the other kids. He was active, competitive, rebellious and reluctant to engage with the structure of a camp-day. He was driving me nuts and soaking up a huge amount of my attention.
After two weeks with Jack, I invented a rule for myself. Every day it was my responsibility to insure that, no matter what, we had more positive interactions than negative/disciplinary ones. If Jack and I had 10 negative interactions in a day, then it was up to me to find 11 ways to have a positive interaction with him that day. I hoped that it would help to change our confrontational dynamic.
***
The single most important thing I did on my Chicago project was empathize. I got to know everyone involved, what made them mad and what made them feel powerless. What’s a good day look like? A bad day? What do you think caused the recent disaster? I listened to them for as long as they felt like talking, and always made sure to have more positive interactions with them in a day than confrontational ones.
I learned that one particular stakeholder at the client company (we’ll call him Allan) deeply disapproved of how another team member (let’s say Kyle) had acted during the recent disaster. He so deeply resented Kyle’s actions that he had disengaged for a while and focused on other projects within the company. “I just needed some time away,” he said. I tried to listen as well as I could, validate Allan’s frustration and then stress the degree to which we needed Allan in the room to make important decisions. We desperately needed his expertise and access and couldn’t afford for him to be grumpy or disengaged. When Allan returned his attention to our product, blockers immediately started to fall away.
It was easier to empathize with the developers; they all sat right near me. I tried to hear them, understand where they were blocked and what they wanted in order to move forward. I’ve heard people describe PM’s as a team’s “CEO,” but I felt more like team secretary. How is today going? Where are you stuck? Is there anything else you need from me?
At the end of my second week, we finally got all six key stakeholders/developers in a room to plan a path forward, a way to get us unblocked. By the middle of the third week we had agreed who was able to make key priority decisions, and had arranged a daily phone call to all touch base. We were still stuck, but at least everyone had come to the table.
***
One of Jack’s bunk-mates had brought a Rubik’s Cube with him to camp. I tried to teach that camper how to solve it, but he quickly lost interest. Jack, however, was intrigued. I was tempted not to bother teaching him; Jack was very athletic/ active, and I didn’t think would take to the intellectual/ mathematical puzzle of the Cube. Plus he had already drained so much of my time, why should I sit with him for private Cube lessons?
In the spirit of my new rule (more positive interactions than negative ones), I sat with Jack and did the first lesson. He loved it, and the lessons became a great way for me to have positive interactions with Jack throughout the day. Our connection, in turn, connected Jack back to the rest of the group. He and I were friends (after all we sat and geeked out together 5–6 times a day), and so when I asked him, “Hey Jack do you mind just playing this game with us for a few more minutes even though it’s not your favorite?” he responded. He wanted me to be happy, and I wanted him to be happy. He didn’t want me to be sad or frustrated. I, too, understood his frustrations, and knew that maybe after 40 minutes of sitting at arts and crafts he would be antsy and need to run around a bit. We understood each other, and were much better positioned to help each other.
By the end of the summer, Jack could solve the Rubik’s cube beginning to end completely on his own. He is a great kid, a friend, and I hope he still remembers how to do it.
***
Among our team in Chicago, the client organization had gotten a bad rap. Why can’t they get along? Why can’t they decide what they want? Why are they imposing all these new quality assurance tests that slow down our feedback loop? If only they would stop getting in our way!
It’s no surprise that although it sometimes felt like “they” were working against us, every individual “he” or “she” was working tirelessly for us, was well-intentioned, smart and capable. By understanding what made good and bad days for all of these people, I tried to align our team conversations with its largest problems. Part of my job was to be friends with the client stakeholders. Not in a false, sleazy way at all; I love getting to know new people and see this as the best perk of my job.
A couple weeks after my recent engagement’s disaster, the developers were very discouraged. Without data, we couldn’t accept stories; without stories, the developers felt as though they were just throwing code out into the void. They were getting no feedback.
My first week I asked the lead developer if he’d get a coffee with me and picked his brain. What’s the biggest blocker to you right now? What are you frustrated with? Who on the client side might be able to help?
By having these conversations with both the developers and the client, by deliberately empathizing with all parties involved, I become a huge asset to the team: a single brain which comprehends everyone’s frustrations, goals and blockers. This puts me, the PM, in position to start undoing the gridlock. We can more quickly get unblocked, and ship effective software faster.
As it turns out, Allan was the right person to help our anchor; and I helped to reconnect them.
***
I still don’t know exactly what a PM does, and I’m quite sure that it’s different on project of different sizes and in different phases. But certainly one thing that a PM is is his or her team’s Camp Counselor. Who’s tired? Does everyone have their water with them? Remember when we get up there there’s a swimming hole at the top so bring your suits. Who doesn’t have his suit? Oh, okay run back and get it. I bet Tim wouldn’t mind taking your pack for a few minutes because you helped him this morning.
I’ve heard that in a Balanced Team, the Designer is the “Empathizer in Chief.” While I think that’s true in terms of user empathy, I would steal that title for the PM as it relates to the team itself. Where are the developers stuck? What does design need to move forward? What does the business need? By asking myself these questions every day, I tried to air-traffic control a team of 15 people, making sure everyone got where they were going and no one ran out of fuel.
Empathy is not to be underestimated. Empathy with users allows you to design an effective product, empathy with stakeholders helps you to stay aligned with the business goals, and empathy with your team ensures good communication and cooperation.
While engineers are responsible for solving all of a team’s technical problems, I believe a PM is the first line of defense against a team’s people problems. By understanding everyone’s abilities and needs, a PM positions him or herself to be the perfect person to make judgment calls about who should focus on what when. This bug is a priority? Great, we’ll put it in the backlog. Oh actually it’s an emergency? Okay I’m going to go interrupt the dev pair I know is working on the least critical thing right now and have them look into it.
***
By the time I left the project in Chicago, I think we were well on our way to solving — as a team — the many people problems that were blocking us. My second week on the project we accepted a measly 0 bugs, 0 features, and 1 chore for 0 points. My last week (four weeks later), we accepted 6 bugs and 8 features for 11 points.
I certainly don’t mean to take credit for this turn-around. A lot of very capable/smart people worked very hard to right our ship. But a significant part of this improvement was due to the team solving its people problems. Instead of shifting blame and avoiding meetings, we were sitting together in rooms and ironing out misunderstandings. People felt heard, they felt that they had a stake in the team, and they wanted to find ways to move the whole team forward.
One of my favorite music professors once said, “The most important thing a choir needs in order to excel, above musicality and everything else, is to love each other.” I believe the same goes for a software team. When the team likes each other, when they feel like a team, they will look for ways to succeed, to get unblocked.
***
When everyone feels happy, heard and validated they work together better. When people know that their grievances are heard and considered they stay invested. When I know that my other team members are counting on me, I commit myself that much more. When I know that those team members also have my back if something goes terribly wrong in my workflow, I can work with the confidence that I’m not alone.
Camp Counselor, Air Traffic Controller… Product Manager. While the goals of a camp (make sure all the kids learn, are safe and have fun) are different from the goals of a software team (ship an effective and lucrative product), both work better closely knit and not disjointed. Being heard, being supported, feeling at home: these are things that in both cases spur people to be their best selves, and to best support the team in accomplishing its goals.
Though I’m not sure all PMs would agree, I believe that this is a significant part of our job. Perhaps it is a leadership position, but I still eschew the CEO metaphor. It’s a service leadership position. We are the team’s camp counselor.
I make sure everyone feels heard and is comfortable. I make sure they feel included. I mine each person for their personal insights, and prioritize which of those need to be presented to the group. Instead of just burying my head and doing a single task, I make sure all the tasks connect in the right way, that the alarm is sounded at the right times and for the right reasons. I help people ask for help, empower them to do the right thing, and make sure that they remember their bathing suits.
