I think that the number one hiring criterion for a vice president of product management (VPPM) should be someone who’s done it before—who has executive-level product leadership experience—but I’m often outvoted. In my experience, executives tend to favor subject experts or chief technology officers rather than candidates with specific experience leading product management teams.
It’s obvious that chief financial officer candidates need to understand revenue recognition and cash-versus-accrual. Chief marketing officers must demonstrate a love of lead generation and market positioning. Engineering vice presidents need to have spent time building production code and earning the respect of their software craftsmen. Often, though, this doesn’t carry over to VPPM openings.
Yet product management teams should scale with engineering. Depending on the company, 50 engineering folks might require three product managers, while 200 engineering folks might need seven to 10 product managers. And at this scale, someone needs to lead the product team and drive coherent results.
A strong VPPM will address company-wide issues and focus on aligning the strategy across organizations and products. The following are six important responsibilities of an effective VPPM.
1. Know what product management is, and sell that to peer organizations.
Individual product managers rarely have the luxury to define their jobs or push back random work dumped in their direction. Without someone to establish job boundaries, they end up doing a little of everything and not enough of their real value-add.
Product management should always include product strategy, release-level feature choices, economic rationale for every major effort and whole-product thinking. It might also include high-level bug triage and UI/UX review. However, it shouldn’t include project management, primary customer support, routine website text editing or order entry.
2. Connect activities and deliverables to business outcomes.
Most line organizations focus on deliverables, not on business results or coherent product offerings. Output instead of outcomes. That makes it easy for product managers to get lost in the minutia: templates, process flows, presentations and release planning meetings. Internal customers notice timeliness more than coherent strategy. How often do we rush market analysis because our developers are idle or ship a product with poorly considered pricing? Prompt but purely tactical product management is just filling out forms.
The VPPM must politely (but relentlessly) push for strategic clarity and intended business results by asking irritatingly hard questions:
- Why are we starting development if we haven’t validated this market segment?
- How do our assumptions change when we shift technical priorities, pricing or sales/distribution models?
- Why should customers want to buy if we’re pushing features instead of customer benefits here?
- Can we use off-the-shelf software for that instead of building something ourselves?
- Does sales concur with our revenue projections?
3. Make sure there’s a company-level product strategy.
Lots of companies have missing, muddled or misguided product strategies. They circulate multi-year dreams that lack specificity, filled with buzzwords instead of strategic choices. Someone has to push for coherent strategies and the difficult resource allocation decisions that strategies imply.
The VPPM doesn’t have to invent or discover the strategy, but should push the company’s best minds to collectively create one. In addition, the VPPM must aggressively defend a good strategy against random changes, fads and single-customer escalations. He or she must push to allocate technical resources strategically among products, not just based on last year’s budget.
4. Drive real participation and input.
We all talk about wanting input from customers and stakeholders, but market input is often handled haphazardly, with poor feedback mechanisms. Every product manager has some unique wiki or spreadsheet for tracking requests and requirements. And sales is tired of asking for enhancements that never get built.
The VPPM has to unify and defend a robust input process, with a common mechanism and accessible list. More importantly, he or she has to point out that asking is not the same as getting. Most enhancement requests will never be fulfilled because no matter the size of the engineering team, customer and sales team demands always vastly outstrip technical resources. The backlog is infinite.
5. Build organizational support for good decision-making.
Functional organizations tend to have a narrow focus and think, well, functionally. Someone needs to encourage cross-functional solutions. Someone needs to be designated as the chief rationalist. It might be the vice president of marketing or chief operating officer, but often it’s the VPPM.
6. Mentor product managers.
Ask great product managers how they learned their craft, and you’ll hear about early mentors. Product management is hard, experiential and doesn’t come out of books. We learn by watching and doing and stubbing our toes. We learn by getting coached through product strategies and economic decision-making. And we learn by seeing that collaboration among many smart people is better than being the smartest person in the room. That’s why it’s important for the VPPM to train up the next crop of directors.
A strong VPPM will drive better processes, encourage more cooperation and create coherent products.
SIDEBAR
4 Mistakes to Avoid as a New Product Executive
Hired as the new vice president of product management? Here are four mistakes to avoid when you first arrive:
1. Don’t recommend any product changes until you’ve been there at least two weeks and have listened carefully to a lot of folks.
You could arrive on day one and decree that your list of product changes is the new priority. Don’t. Premature reprioritization may cost you credibility. What if:
- Your product management team is smart and has a similar list? They need your organizational clout to push for already-well-understood improvements, not another new list.
- You’re not the typical user? This target audience is younger, female, exclusively on Android, international and constantly online. If that’s you, then imagine the opposite. Your intuition and experience may not be relevant.
- There are non-trivial technical or legal issues to overcome? Don’t assume your new company’s only missing ingredient is personal heroism.
- There are already too many engineering projects underway? You may need to swing a cleaver, not another marketing requirements document.
2. Don’t postpone talking directly with live customers or prospects (and don’t stop once you’ve started).
The CEO has an opinion, as does the head of QA, every engineer and random people who tweet about your company. But opinions lack rigor, consistency, business justification, judgment and strategic thought.
Get a list of real customers (users, prospects, beta testers, whatever) and start reaching out immediately. Try to talk with one customer a day, take good notes and share them widely.
Note whether the customer is in the target audience, what they like and would change, and how/why they use your product. Spend five minutes on the phone and 10 minutes more to post a summary. In two or three weeks, you can say “I talked with 20 customers, and here’s what I learned …” Suddenly, your list has the evidence to back it up.
3. Don’t get written off as a technical lightweight.
Especially for computing infrastructure and B2B software companies, the engineering team demands product folks who can keep up technically. They have little patience for marketing types, buzzwords or mixing up compilers with composers. The development team will treat your feature requests with suspicion (or derision) if you don’t know how the fiddly bits work.
Consider sponsoring a lunch-and-learn series for your product team, with software architects sharing their wisdom. You provide the pizza and learn what’s inside the box alongside your product managers. Also, if you can, use your product intensively. Skim the technical docs, talk informally with the development team, sit in on a few support calls. And never let engineers see you wear a tie.
4. Don’t promise delivery dates for anything—no matter how small—until you’ve gotten engineering’s agreement.
No matter how simple a fix appears to be, assume it’s difficult until your development partners agree otherwise. Nothing sinks your credibility faster—both externally and within engineering—than unilateral over promising.
Beware of customers and salespeople who relentlessly chase you down to plead for some improvement that “can’t be more than a few lines of code.” Listen and offer to investigate, but don’t make any commitments out of ignorance or shame. Promise a response, get contact info and use this as another vehicle to learn your new product set. You can play the “I just arrived, I’m not sure, let me look into it” card for a little while.
If you use your first few weeks at a new company to discover what’s really happening and what customers really need, you’ll be ready to speak with clarity and authority.
