Venture Geek

I have spent the last 5 months back in Product Management Land, and as I prepare to leave to go back to a more marketing-centric role (more on that later) I am reflecting on the nature of my job here. Broadly speaking, there are two primary metaphors I have seen used in describing what product managers do. The first is a translation layer between business and engineering — in this linear process model a product manager is a step along the way of business needs becoming reality through the filter of articulating business requirements into engineering-digestible units. The other is product manager as a hub — a coordinating destination at the center of various constituencies each with their own needs/agendas/perspectives. When I was looking for this job I also was reminded how differently different organizations think about product management vs. product marketing — especially in Silicon Valley, those two roles straddle a line (artificial or otherwise) between production of what one sells from the act of selling (and the organizational support that goes into that selling). The term “product” itself is something that can be thought of very broadly or narrowly depending on the company, industry, and culture — some times it is though to include the total experience of what customers buy (and/or what end-users use) and sometimes it is construed more specifically to be the actual artifact that is exchanged independent of the packaging, services, etc. that are more often than not wrapped around the total offering.

I was recently talking with a junior member of our team, someone new to the role of product management, and (more or less out of my ass) I told him the role comes down to 5 basic elements (it’s worth noting explicitly that all of my direct experience [and the bulk of my indirect exposure] is inside software-driven technology companies of one sort or another, and while I think the overarching themes will apply outside that context that’s what this is about):

• Gather: A huge part of what product management, in my experience, is all about is simply knowing what’s going on — what people do all day as it relates to the product, what kinds of things they wish would change, and how the various constituencies interact. While most product managers have plenty of good ideas on what should be done to improve the product, gathering ideas and identifying problems from the rest of the organization is as important, if not much more important in some cases.
• Synthesize: As various ideas and issues are identified a product manager must create connections where others do not see them. Two groups in an organization may be having two very different problems, but a product manager can often find a way to make a single, better abstracted, view of the underlying concern. Synthesizing also involves created named themes/initiatives/goals for a product — a task that should never be underestimated in its power to create common understanding and bring sanity to the chaos of all the various “line item” requests — this is also instrumental in creating buy-in from others by packaging granular, disparate tasks into meaningful categories.
• Prioritize: Choosing what is most important is an art unto itself in Product Management Land. A deep understanding of the business strategy, market realities, and resource capabilities and constraints is key here, as something is important not simply because someone up the chain says it is (though, of course, that can often trump everything else), but knowing what’s hard vs. what’s easy, what’s of broad vs. narrow value helps to create a rank-order list of the various tasks to be done. Of course, trade-offs are the key here. Given infinite time and infinite resources everything would be possible, but (sadly) that is not something we ever get to come even close to, so making the hard choices (or, perhaps more importantly, being the necessary input to help the rest of the organization make hard choices) becomes one of the central functions of a good product manager.
• Define: Ah, define — where the (tedious) rubber meets the (not as proverbial as one might like) road. It likely goes without saying that a product manager must ultimately own the detailed definition of what the product should do, so engineering knows what they will build. Of course, this involves plenty of documentation, though not as much as some might think in many cases. My general attitude is to document only as much as is needed, rather than creating detail for details sake. Especially in web-delivered software, the need to be quick and iterate frequently puts a premium on moving forward with imperfect information and adjusting a bit as you go. Anyone who has been an engineer or works closely with engineers knows the joys of changing the spec in mid-flight (and/or the dreaded feature-creep), but part of the reason we have seen the rise of Agile methods is that rather than constantly reacting to the often-broken nature of attempting to get to a “finished” spec of a project (only to see that spec change in the middle of the cycle) engineers started to simply build the dynamic nature of requirements into the system. The point being that “Define” does not always mean writing down as much as being the Source of Truth.
• Shepherd: When I originally wrote this word on a white board while making up this list on-the-fly, it was tongue in cheek, but the more I have thought about it, the more I think Shepherd really captures the role of the product manager in making sure everything is moving along smoothly. If I were more PowerPoint inclined, I could see making this list a “cycle”, where shepherding leads directly back into Gathering. A big part of my day as a product manager involves, quite literally, walking around the building. Keeping all of the balls in the air, so to speak, is a critical part of product management because in most organizations there is nobody else who sees all of the various pieces and how they must fit together. Many product efforts require synchronizing distributed efforts towards a single destination (and doing that over and over again), and in my world having the engineering “done” is only about 2/3 of the way through cycle — once the actual “product” is at a finished state there remains various packaging, documenting, training, distributing, etc. etc. etc.

When I first put these 5 elements on a white board I drew alongside the word “CONTEXT” — ultimately, all of these activities must happen with a full appreciation for the business — the goals, strategies, capabilities, culture, and (never to be underestimated) people.