My Role As A Product Manager

Like these team mascots from an earlier project, this role is a constant evolution. My wife has no idea what I do. It was hard enough to explain Product Management to her when I worked on physical things. Now that I work in software, it’s nearly impossible. Fortunately, I long ago learned my role as a Product Manager boils down to two things: Provide Focus Enable Autonomy If I do these things, and do them well, then I will be beloved by my team and together we’ll create amazing things. If I screw either of these up, I’ll be a drag on my team and lead them on a wild good chase. While it sounds simple, it’s anything but. It requires constantly thinking in systems and balancing tradeoffs, both technical and human. Providing focus requires framing the problem your team is trying to solve. For me, this means I make a map of whatever system we’re working in and try to set the bounds of what we can play with and what we can’t. Making a system map is not rocket science, and there is no correct answer. In many ways, it’s a lot like thermodynamics (remember those three laws?): you draw out the system and a relatively arbitrary control volume around what you’re focused on. As in thermo, it’s good to know what is going on inside the bounds, but a PM cares mostly about what goes in and what comes out. As a PM, I provide focus by identifying what is in-bounds and what is out-of-bounds for the team. Drawing a Control Volume (diagram from MIT Thermo course. http://web.mit.edu/16.unified/www/FALL/thermodynamics/notes/node19.html)This may sound relatively easy, and it can be, at first. The complexity will become inescapable once you start mapping out the different stakeholders, the different system components, and the interconnections. Still, it’s important to make the map, even if it’s chaotic. Once I have a map, I share it with my team. They’ll point out all the ways it is wrong, but in the process we’ll have a conversation about what parts we already have, what is missing, and the overall experience. If you’re used to Agile development, the purpose of this is like with stories in Agile: it’s about the conversation it starts more than any fixed artifact. A good map with bounds on it is basically a loose picture of your target future. Another way to paint a picture of the future is to make a mockup that demonstrates what the world could be like. The mockup itself sets implicit limits on the direction and opportunity you want to go after. Here’s the output of a vision from a movie you might have heard of (http://www.wired.com/2016/03/nikes-back-future-self-lacing-shoe-hyperadapt-1-0-finally/)On a very pragmatic level, providing focus typically translates into writing requirements, stories, and epics. But if that’s all your PM is doing, then they’ll probably not keep the team focused and moving together when something goes wrong. There needs to be something (or someone) who is framing the opportunity and coordinating the complete experience so the whole team can focus on the problem they’re solving. That’s what a PM does. Being focused is great, but focus alone won’t get anything accomplished. This is why I see the second part of being a Product Manager as enabling autonomy. Enabling autonomy is often harder for PMs because there is no easy exercise or approach. It requires building a mutual respect within the team, and then trusting each other to do good work. There are all sorts of ways to build respect and trust within a team, and my favorite way to start is by getting everyone to share past work and war stories. Another way to build trust and respect is to make everyone’s voice feel heard. This means collaborating with everyone and sharing the vision, which can be hard for some PMs because it means giving up control. Not wanting to give up control to one of the perennial problems of PMs: micromanagement. [Jobs is] a corporate dictator who makes every critical decision — and oodles of seemingly noncritical calls too, from the design of the shuttle buses that ferry employees to and from San Francisco to what food will be served in the cafeteria. — Fortune, 2011 Sometimes, as with Jobs, it works out. In my experience, most of the time it doesn’t. It’s one of the reasons I like to stick to system maps instead of mockups. Maps support autonomy in a way mockups don’t because they don’t prescribe opportunities instead of solutions. It’s also crucial to trust your team to be the experts in their responsibilities. Once you see your team members as the experts (instead of you being the expert), it only makes sense to give them the space to do their jobs by finding information, clearing roadblocks, and asking how you can help them instead of asking them to help you. The net result of these approaches is a mutual respect and confidence within the whole team. It gives everyone ownership in the outcome and avoids most of the political pitfalls. It’s never easy and requires constant effort, and it creates the best outcomes. I won’t pretend I know what I’m doing every day or even that I have particularly good approaches. What I do know is that by thinking about my Product Manager role as providing focus and enabling autonomy, I’ve become more effective, and I’ve been able to (partially) explain what I do to my wife. Both of those count as successes to me.