I sometimes find product management teams composed entirely of first-timers, where not a single person has any previous experience as a product manager (PdM). Instead, it’s made up of internal transfers and ex-developers and newly minted MBAs trying to teach themselves the craft of product management. Typically, the manager or director of this group also has zero years doing actual product work.* This presents a fundamental challenge: how do we train or skill up a whole product team from scratch?
This situation should be vanishingly uncommon. Imagine staffing a software development team entirely with people who have never written any code. Or a finance organization where no one has any previous experience with payroll, A/P, quarterly filings, or stock options. Yet I’ve seen dozens of product teams that are “greenfield opportunities.”
Requests for help regularly come from HR or non-product execs, exaggerated as:
- “We have 20 product managers but don’t yet have a product management process. Do you have a fully documented end-to-end process that we can implement here?”
- “Which 3-day class will teach our new product folks everything they need to know, including ‘best practices’ and strategy and stakeholder management?”
- “We’re inspired to be product-led. How do we transform our downtrodden IT order-takers into empowered strategic product leaders – quickly, inexpensively, and with no changes to the rest of the organization?”
After 35+ years in product management, I still struggle for good answers. Mostly because this frames product work as a repetitive, transactional, tech-only assembly line that converts “here’s someone told us a user asked for” into “specs we can code against.” That product management is paint-by-numbers. That there’s a cookbook. That filling out canvas A and writing Jira ticket B will deliver innovative, groundbreaking, delightful products which sell like hotcakes.
My view is that good product management is more craft than procedure and is best learned through an apprentice model. Blogs and books (including mine) are sources of inspiration, but woefully insufficient. We want PdMs who drive strategy and can also get down-n-dirty with technical teams; who can help Sales close enterprise deals and also build pricing models; who motivate cross-functionally in the absence of real authority; who zoom up to Board-level and also know the status of every roadmap item. Who leap tall buildings in a single sprint.
Much of product management is complex, deeply cross-functional, heavily context-dependent, and entwined with the organization’s culture. Not much is cut-and-paste. A user story is worthless if it’s grammatically correct but doesn’t frame a real problem. Roadmaps don’t need to be beautiful, but they do need to communicate a great strategy. A focus on individual product activities (instead of outcomes) too often leads to more activity but not much impact.
“Show, Not Tell”
So we need to coach/mentor new product managers on how to do these new things well, anchoring the work to its underlying value and context. We need to show someone how to apply new concepts/tools/approaches the first time; pair with them the second time; supportively encourage them to do it themselves the third time; then provide helpful critiques ongoing. Talking about pricing or hard trade-offs or product portfolios or Not Invented Here syndrome doesn’t teach someone how to handle it.
We need to show instead of tell. And plan to show it more than twice. With so many different kinds of strategic work bundled into one job, I sort them into big-and-somewhat-specialized areas and small-to-moderate experience areas that arrive throughout the year.
Big Coachable Areas
IMO, there are a few big chucks of product competency that call for specialized / heavyweight / experiential workshop-style coaching. Especially if your team is starting from square one. The biggest is end user discovery interviews and real customer validation.
Discovery/validation screams for deep “show, not tell” skills-building. For example, Teresa Torres** & Hope Gurion run 12-week coaching-style workshops where cross-functional trios actually learn some tools, sharpen their listening and critical thinking, build opportunity trees, test assumptions, and get helpful critiques all along the way. Josh Seiden & Jeff Gothelf have a similar 4-week process. (As do others.) First-timers can’t teach each other what they don’t already know, and reinventing the opportunity tree takes a very long time.
Depending on the organization, OKRs or roadmapping can be another big chunk. Top-down command-and-control companies tend to push OKRs down from the executive level, and these look just like the quarterly goals they used to set. Sales-led organizations like to convert pure financial goals into matching OKRs (“Desired outcome is to hit $50MM this quarter. Key Result is that we reach it. Don’t care how.”) For real OKR help, I’d reach out to Christina Wodtke or Felipe Castro or another virtuoso in your network. For roadmapping, I’d start with Bruce McCarthy and C. Todd Lombardo.
This is hard work that will take time, money, focus, and deep expertise. I’d encourage bringing someone in who has dedicated years to this specific space.
Smaller Coachable Learning Areas
There are lots of product management undertakings that happen periodically and don’t warrant such a deep-and-narrow engagement. More granular product work that’s hard for a team to teach themselves from scratch:
- Thumbnail business cases. Novices can find 100-page business case templates and 3-line spreadsheets, but making these useful to the right audience at the right level of detail is hard. We can save them weeks of trial-and-error by clarifying our intent and helping on the first 3 or 4.
- Saying NO to executives and internal stakeholders and customers. Every product manager has 10x (or 50x) more requests and demands than their teams can ever fulfill. So we turn down requests every hour of the day. But gracefully saying NO to VPs and CEOs is a learned skill. And letting ourselves be cast as the bad guys can be demoralizing.
I like to periodically run whole-product-team exercises where we take turns role-playing the indignant stakeholder with unrealistic demands. We de-stigmatize the conversation, trade polite versions of “not in your lifetime,” share the pain, laugh a little. Next time, we each report on what worked/didn’t work. We build empathy for stakeholders without giving them everything they want. - EOL planning. There are decent blog posts on end-of-lifing a product, but none of them paint all of the customer push-back, internal politics, CEO interventions, and organizational forgetfulness of a real EOL. And many PdMs go their whole career without sunsetting a product. This is hard, unpopular, exhausting, and high risk. The benefits can seem theoretical. Yet we often throw this as a side assignment to some unlucky rookie. “Can you pull together an EOL plan for Friday’s exec staff meeting?” Much better if someone on the team has done a few EOLs, can share templates and war stories, and support our newcomer.
- Concept mapping. I love the Business Model Canvas that Alex Osterwalder pioneered. But it’s not about filling in the boxes – it’s about using the canvas as an organizing tool for hard thinking, risk identification, sorting customers from partners, and economic inquiry. Someone who’s already put canvases to use would be a great asset to the team
And so on. The best choice would be someone already on the team, steeped in context and direct observations of company culture. Which all begs the important question: who does the mentoring when everyone is new?
We’ll have to find this person outside. It should be a product veteran: 8+ years of full-stack product management on revenue software products – with scars to match. If you have 10 PdMs to skill up, I’d guesstimate this as a half-time coach for a half year.
Intentionally over-emphasizing: don’t bring in an engineering manager instead of a product management veteran. Or an agile development coach, former user, product owner trainer, IT quality expert, executive communications coach, SAFe consultant, industry analyst, or management consulting firm. You need someone who’s lived this specific thing and knows where theory meets practice… who’s been directly responsible for shepherding $100M of revenue products along the way. Otherwise, we’ll all be reading the same book and wondering why it’s so much harder at our company.
Finally, we’ll need a radical shift in hiring strategy. We have to abandon whatever approach filled our product team with rookies. If we’re in the software business, I’d rewrite the PdM job spec to say “must have 4+ years of product management on commercial software products” in 20-point bold type. Above all other requirements or criteria (segment experience, coding skills, internal transfers, famous universities, geography, family ties to executives). And avoid the “I did something just like product management” dance. After we bring in 3 or 4 veterans, we can mix in some more eager beavers.
Sound Byte
Product management isn’t a rote exercise with standard steps. We don’t learn the interesting (hard) parts from process diagrams or PowerPoint. IMHO, the best approach is internal coaching/mentoring from real veterans who guide us through product thinking and show us how to tackle the next task. If your team doesn’t have one, you may have to rent one.
_____________________
* <rant> Companies with very little experience with strategic product management tend to hire CPOs that have (gasp!) zero expertise as PdMs or product leaders. They lack understanding or appreciation for what product managers do, or need to succeed. Instead, they reach for engineering leaders or market/subject experts or sales executives or former customers – usually someone with the same background as the CEO. Hint: this almost always ends badly – in part because they can’t coach/guide their teams through the gritty details of doing strategic product work. And can’t anticipate the unique organizational challenges that every product team faces.
Would we hire a VP Engineering who’d never built software? Or an SVP Sales who’d never managed quotas? Or a CFO unfamiliar with cash flow? Unlikely. But it’s easy to imagine that product work isn’t so hard – easily picked up from a few blog posts. Cf: Dunning-Kruger.</rant>
_____________________
** I no longer do this particular work, and I don’t take referral fees for pointing people toward the experts. That keeps my incentives visibly aligned for my clients.