Hiring a Head of Product

Over the last three decades, across 10 full-time jobs and 180 consulting clients, I’ve headed up product teams 18 times (mostly as interim VP) and helped another dozen companies choose their Head of Product.   That may be the record for anyone other than search professionals.  Here are some patterns I’ve seen in picking successful Heads of Product.

Failure modes that often come up:

• Exec teams don’t know what Heads of Product do, or want someone who will “make development more efficient”
• They don’t value experience running product management teams. Instead, they overweight narrow technical or market segment familiarity
• Each department wants to hire in its own image. Sales execs want more sales-y Heads of Product; development execs want more engineering-ish Heads of Product; marketing teams want a marketer in product clothing… no candidate passes muster with all groups.

Let’s unpack.

What’s In a Name?

First, I observe that product titles and roles vary wildly across companies: there’s no consistency even within a segment.  So our first struggle is what to call this role.  Let’s carefully define a “Head of Product” as someone who directly supervises a team of product managers including hiring, work assignments, mentoring, and resolving cross-product disputes.  At your company, they might be called Chief Product Officer, VP Product, Director of Product Management, or Group Product Lead.  Heads of Product may also manage designers, product owners, product operations, and the occasional business analyst or product marketer.

I’m specifically excluding roles that are primarily development management: VP Engineering, CTO, CIO, Director of Development, Engineering Manager, Project Office, or Agile Transformation Leader.  If you’re overseeing 52 developers and 4 product managers, your attention is mostly on engineering issues rather than product issues.

And many executives have never seen good product management.  They come from professional services groups — which is all bespoke contracts and project management.  Or non-software companies — where IT is squeezed as a cost center instead being the company’s main profit center.  Or they play founder-as-fickle-part-time-product-tastemaker — where developers take orders directly from the CEO, buffeted by a constant stream of fresh interrupts and changed priorities.  Or they’ve lived through failed-waterfall-to-failed-agile transformations — where narrowly defined product owners work in feature factories to implement poorly considered projects for non-technical business execs.

It’s no wonder that folks are confused, frustrated, and fail to get the product leadership they need.  We spend our time arguing about titles or rehashing organization-wide failures.

IMHO, Product Leadership Experience Is Essential for Heads of Product

<rant>When companies are interviewing candidates for VP Worldwide Sales (aka Chief Revenue Officer), they look for previous experience as a salesperson and then running a sales team.
When hiring a CFO (aka Head of Finance), they ask about previous experience managing cash flow, payroll, and accounts receivable teams.  CFOs make sure employees get paid and executives stay out of jail, so first-timers are risky hires.
When searching for a VP Engineering, they want someone who’s built a lot of software and managed development teams.  “I think writing software would be fun” isn’t a strong selling point.
When considering VP Marketing hires, they push on positioning, messaging, qualified lead funnels, social media engagement, and broad marketing strategy.  CMOs know that marketing is more than redesigning logos or A/B testing email. </rant>

Yet somehow this thought gets lost in job descriptions and Head of Product interviews.  I find myself repeatedly emphasizing the need for foundational product experience for any product executive.  (Questions: “Have you ever had a team of product managers reporting directly to you?  How many/how long?” “What’s your preferred organization model for product folks?” “Tell me about products or services that you personally managed…”)

Without a clear hiring strategy and crisp criteria, interviewers naturally choose candidates most like themselves.  Sales interviewers crave in-the-field experience and support for “specials;” developers do coding exercises; support teams gush over product managers who say they will prioritize every bug report; finance folks want to hear that we can estimate feature-level ROI to nine decimal places.

I sidestep this by [1] putting previous product leadership experience at the very top of the candidate qualifications, [2] slimming down the rest of the job description, [3] having each member of the interview team read the job description, and then [4] assigning each interviewer an area to explore with all candidates.  That gives us some basis for comparison.

“We Want a Head of Product Who Will Push Engineering Harder”

Lots of CEOs tell me that their VP Product Management should somehow make the development process more efficient.  This comes from a misunderstanding of how product and engineering folks work together, and a fundamental confusion between “faster” and real customer value.

Development teams don’t work for product management: they report to a VP Engineering or other development exec.  And they make most of their process/tooling choices.  (Product managers may have strong opinions about Scrum vs. Kanban vs. XP; or Jira vs. Asana vs. Pivotal Tracker; or Selenium vs. LambdaTest vs. Ranorex; or planning poker vs. snake sorts.)  But developers get to pick.  Our suggestions are just suggestions.  We can’t make the engineering team do what we ask, we can only make them want to do it.

Product’s biggest contribution to development efficiency is throttling down mid-sprint interrupts and de-prioritizing the 92%+ of requests that aren’t as important as the critical 8% we’ll start and then finish.  It’s counter-intuitive for go-to-market executives, but the more we overload development, the less in total we deliver.  Every surprise customer commitment (“BigCorp needs X and it won’t be hard, so we wrote it into the contract”) means less time for our agreed-upon strategic projects and less dedication from our developers.  Stretch goals and contests may motivate sales teams, but mostly dishearten development teams.

So product managers boost productivity and overall delivery by pushing back on almost every well-meaning demand.  (Individual requesters don’t see the pattern, but we get 10 or 20 or 50 new requests each day, each from someone who needs to be our new #1 priority.)

And a Head of Product has to gracefully take the political flak from the rest of the executive team, knowing that every functional group wants more of engineering’s attention.

“Our Product Is Super-Complex, So We Need A Subject Expert”

I hear this all over, from machine learning products to CRM to hospital management systems to design tools to e-commerce to dating apps to network security.  And I almost never buy it.

I do see a big divide between B2C and B2B/enterprise products, and therefore their product managers.  Most B2C products have orders-of-magnitude more users, dramatically shorter/simpler selling cycles, and no single customer with enough purchasing power to hold us hostage.  The buyer tends to be the user, and value stories aren’t routed to the CFO for scrutiny.  We bring different tools and business thinking to consumer vs. corporate products.  So my bias is to look for B2B/enterprise experience for B2B companies.

But within that, I observe that seasoned product managers can learn most of what they need within 1-2 months.  Data warehousing PMs can get up to speed on network security; CAD/CAM folks can quickly grasp ERP systems; veterans of accounting systems can transition to HR/Applicant Tracking Systems.

As Head of Product, I may need to push my team to get out of the (virtual) office.  That first month can’t be spent exclusively on inward-looking agile artifacts or technical analysis.  At least half of their time needs to be directly experiencing  markets / users / competitors / sales pipelines / customer-side ROI and company-side profitability / support issues / onboarding challenges / ecosystems.  Because it doesn’t matter what we think unless it reflects what’s really happening in the marketplace  Good product managers trust the market over their preconceptions; good Heads of Product insist on constant direct customer discovery.

If your product is so complicated that a product manager can’t learn it in 8 weeks, then you’ll have an enormous problem getting prospects to understand it, buy it, use it, and show success.

Here’s what I’ve seen when we put a non-product subject expert in as Head of Product:

• They focus on power users and complex new features. They know how it’s supposed to work.  They’ve “been the customer.”  Unfortunately, this misses what 95% of what real users experience: difficult onboarding, complicated workflows, assumed knowledge, messaging that’s unhelpful or unclear except to other experts.  Often, I hear blaming/shaming of users for being dumb.
• Since they are experts, there’s less urgency to do genuine discovery and validation. Markets shift, competitors emerge, new problems emerge, technical choices evolve – which our experts discount.  They already know the right answer, so no need to confirm.  “Let me explain again why customers really don’t want what they are asking for.”
• Often, our subject experts come out of one long-running user experience. “I ran patient analytics systems at the Cleveland Clinic for 12 years.  I know what hospitals need.” Their viewpoint tends to be old, rigid, anchored in some unique configuration.  It also undercuts a core product management skill: creatively segmenting a market to find a subset that needs us, waving us away from segments where we’re a poor fit.

Product managers need to bring a thirst for knowledge: what’s really happening at every step from customer need to new product ideation to technical choices to lead gen to initial sale to renewal to churned user.  And Heads of Product have to push-push-push them to constantly refresh their observations.

“Prioritization Is Just Putting Our Strategy Into a Spreadsheet”

It’s rare for me to find a company whose strategy is specific and actionable enough to prioritize product work.  Sometimes that’s because they borrowed simplistic out-of-the-book OKRs; sometimes they ‘target’ all possible buyers and users; sometimes goals are just a roll-up of departmental goals into a 60-item jumble of tasks and projects.  Most lack a crisp list of what we’re not going to pursue.

Faced with a laundry list of 6 or 13 or 27 strategic goals, it’s very difficult to prioritize anything.  Most of our backlog will support one goal or another.  And each requesting department calls out the one goal that matches their item.

And every department wants the entire development effort.  Support lives with customer bugs all day long, so expects all of our effort against fixing P1/P2 issues.  Sales brings in all of our revenue, and assumes that 100% of each sprint is to help close major deals.  Customer Success nurses new customers through onboarding: so integration and data conversion should get nearly all of our engineering cycles.  Non-technical founders see too much incremental improvement and not enough innovation.  Compliance wants to keep our execs out of jail, so considers every regulatory item highest priority.  Engineering suffers with architectural debt and imperfect tools, so wants to put at least 80% of our energy into refactoring.

Note that each functional group has a different set of criteria, metrics, justifications, value stories.  These aren’t easy to compare and shift day-by-day depending which customers are in today’s sample.  So this is a mix of pure analysis and internal political logrolling.  I’ve never found a spreadsheet that reflects the complexity.

Which means we need a Head of Product who has great negotiating skills, deep empathy, and a backbone of steel.  Staying on strategy while horse-trading with other execs (without getting fired) is a subtle skill developed over years.  Plus, we need our Head of Product to empower individual product managers: each must balance competing internal interests while delivering a market-winning product that lots of customers will pay for.  Non-product folks think this is easy; seasoned Heads of Product spent part of every day making this look easy.

Sound Byte

Just as we expect sales and engineering and finance execs to have experience running sales and engineering and finance organizations, we should look for Heads of Product who have experience running product teams.
That includes time-in-grade as a product manager, and then leader-level experience: portfolio-level strategy, brilliant cross-functional collaboration, hiring/mentoring new product folks, and exceptional EQ to mollify peer execs who never get as much as they want.   Best to hire a product veteran than someone who thinks it will be a cakewalk.