Product Manager definition: A translator?

About 18 months ago I took a pretty big side step in my professional career, approached Dominique Leblond and told him I wanted to join his team as a Product Manager. 6 months later I left Professional Services - where pretty much all my career was built - and moved away from a comfortable position as Principal Consultant for SDL US to that hotbed of discussion, politics and Priority Management: Product Management.

One of my dearest friends told me: "I hope you make me change my opinion of PMs. Every single one I know sucks".

To me it was a simple decision: move from a position where I implement the product - often working around design limitations and customer's lack of vision - to a position where I can change the product to more closely match (current day) WCM customers. It is not a secret that WCM has changed immensely in the past 10 years, and to continue to stay ahead of the curve we need to (like everyone else) start worrying about what happens after you click the publish button. (Disclaimer: I am in no way responsible for SDL's move into this space, these are processes and projects that can take years to completion and were already in progress before I joined Product Management - probably reason number 1 of why I joined PM was because I agreed with the vision).

What wasn't so clear is exactly what does a Product Manager do? I obviously saw and was inspired by the performances of my fellow co-PMs (Davina, Alexandra and of course Dominique) whenever they had a chance to talk to us - on new product features, on new launches, on roadmap planning, but it wasn't really clear to me what goes on behind the scenes that makes the clock tick. A roadmap or a product launch is not something that happens on a vacuum, born out of pure boredom.

So, in the past 14 months I've been learning the ropes of what it takes to be a good Product Manager. I took to the web for inspiration, and I've learned that if you're good, you're the number 1 position your company can live without... at least for the first year or so. Do go read Kenneth Norton's take on it, a very good read.

And then, yesterday, a thought hit me on the head about what probably defines my role in the best way: I am a translator. I spend my days translating vision into high-level, flashy, sales-ready brochures and presentations, translating vision into low-level, very un-flashy, development ready epics and themes, translating from high-level, blurry customer requirements to development themes, from low-level, incredibly detailed and narrow-focused requirements from the implementer community into higher-level, theme-linked approaches.

Obviously, interpreting priorities is the most challenging part of my job. Understanding that there are 20 things our teams could be doing, but only 5 will be done by the next release is easy. Deciding which 5 is very hard. And I have to do that by translating the needs of our customers (internal or external), the longer term goals of the company, the short term goals of the company (including sales - sales goals are always short term, no matter which company you work for) and doing what's right.

So... let's take a look at an example of how this translation process goes, shall we?

• Roadmap states "Mobile Experience Management" as a theme.
• Translate up: Provide clarity to Product Marketing and Sales teams as to what components are modified (and how) to enable "MEM" (because we need a new acronym, CEM, CXM, WCM, PEM and such others are not enough :-)).
• This will take the form of high-level briefings and presentations on how Mobile Experience Management will part of day-to-day work of both developers and content editors by using modules such as the SDL Tridion Context Engine and Experience Manager's Device Preview (it is awesome by the way)
• Translate down: Provide clarity to developers on how to group devices together, use Ambient Data to track device information, understand if we are currently in "Device Preview" mode rather than a real device (and take corrective measures, for instance, on how we determine which browser you're using)
• This will take the form of low-level use cases and functional requirements that can be further translated to "real" development actions.
• Translate left: Provide information to implementers on how to use this new feature called "MEM" to their benefit, usually by making sure it is all correctly documented.
• Translate right: Inform existing customers and prospects on how MEM will make their life so much easier, they'll forget they ever had a challenge with mobile.

And this is how I spend most of my time: translating. Looking at the same topic from 4 different views, describing it in 4 different ways, using different language, using different techniques and tools, and trying to bridge expectations across all 4 "channels".

A similar process is done with translations going the other way around, where a requested functionality may end up becoming a theme by itself and land on the roadmap, and eventually the product (recent examples include our completely revamped workflow engine and bundles - both introduced in SDL Tridion 2013).

If it sounds boring to you, well, maybe you're just not the personality type that would like Product Management. I do spend a lot of time discussing themes and future developments - not only of the product, but of the web as a whole, with a focus on how Content Management must evolve. But at least half of my time is spent translating. And it's great, often I end up knowing a lot more about a feature I designed myself :-)