CTOs, Product Management and Program Management
In “The product manager’s lament,” Eric Ries writes about his view of product managers:
Let’s start with what the product manager does. He’s supposed to be the person who specifies what the product will do. He writes detailed specs which lay out exactly what features the team should build in its next iteration. These specs are handed to a designer, who builds layouts and mockups of all the salient points. Then the designs are handed to a team of programmers with various specialties.
…
When I met this team, some acrimony had built up. The last few features came out pretty different from what was origianlly spec’d, and took far too long, to boot. The programmers keep asking for more say in the designs and direction that they work on.
I think Eric is almost right about what a product manager should do. I want to provide two disparate perspectives on what that almost entails, and why it’s important. First, I’d like to talk about the role of the program manager at Microsoft (my current day job) and then about the role of the startup CTO (my previous day job).
The program manager’s job is to understand the market and customer pain, shape consensus around what a solution looks like, spec that solution, then drive implementation and the inevitable tradeoffs and ship a solution which makes customers happy.* I do all of that in creating the SDL threat modeling tool.
Some people think the market approach is strange because inside Microsoft, the SDL requires threat modeling. But most markets are distorted in some way by legal requirements. I treat threat modeling as a market with pain that I need to address, and do my best to win in that market. I’m fairly pedantic about talking about our customers, rather than our users, because we give them better tools, and make them more successful when we treat them as valued customers.
Note that that is a super-set of Eric’s description of what a product manager does. He has some interesting suggestions, but the real fix is to get the guy who owns the spec deeply involved in the software process, from start to finish. Which brings me to the role of the CTO.
The role of a good CTO is to understand the market and customer pain, shape consensus around what a solution looks like, spec that solution, then drive implementation and the inevitable tradeoffs and ship a solution which makes customers happy. There’s also a responsibility to be a company leader, hiring, shaping the culture, and participating in the executive decisions the company makes. Sometimes, there’s a need to step in and build. But a large part of the CTO role is that of the program manager. I think this is why I’m able to succeed as a program manager—I’ve been at it for a while.
In Eric’s post last month, “What does a startup CTO actually do?,” he provided a different list: platform selection and technical design; seeing the big picture; providing options; finding the 80/20 and growing technical leaders. I think that’s a good list, but it’s missing a key piece, which is the vision to bits to customer experience scope that is at the core of the program management mindset.
[Update: The * was going to be a footnote citing an internal doc which I’m paraphrasing, but I decided to cut it, and forgot to remove the *. Oops!]
Eric, I like this post. I just wanted to point out that Microsoft has different titles for these positions than most organizations adopting product management.
I’m not saying they are wrong – clearly, they work for the organization, and that’s what’s most important.
But typically the role of a program manager at MSFT is filled by a “product manager” at other companies. I think MSFT product managers are predominantly marketing (outbound & research) focused, which are typically referred to as product marketing managers.
While a CTO could execute the role you define here (and I’m sure some have with great success), I would lean towards saying that if you want to have product management, a VP, Product or CPO (Chief Product Officer) would be the one researching and understanding the market, defining what to build and so on.
This way, product has a seat at the management table and it’s not left to one individual to both identify market need, define what to build and then actually be the one responsible for building it.
But, like I said – it’s important to find what works for all organizations in order to appropriately satisfy the need(s) of the markets they are going after.