Product Management Has a Theatre Problem

On hiring panels, framework worship, and the quiet industry of looking competent

A few weeks ago I sat on a hiring panel for a product role. Fourth candidate of the day. She was good. Genuinely good, in the exact way the process is built to reward. I asked how she’d prioritise a messy backlog and she walked us through RICE, then caught herself, smiled, and said she’d probably weight it against the North Star instead. I asked about a launch that went sideways and out came a tidy little STAR story with a metric at the end and a lesson neatly learned. Forty-seven minutes. Barely a wobble.

And I left that room with no real idea whether she could actually do the job.

That’s the bit nobody says out loud. After eight-odd years doing this across streaming, sports data and enterprise software, and sitting on more hiring loops than I can count, I’ve started to believe something uncomfortable. A huge amount of what we call product management is now performance. We’ve built an entire industry around looking competent, and we’ve quietly stopped checking whether the competence is real.

We need to talk about it.

The Take-Home Assignment Is a Tax on the Desperate

Let’s start with the most extractive one.

Somewhere along the way, the “product exercise” became standard. You know the format. A four-stage process spread across five weeks, and right in the middle, a take-home: “Design our onboarding flow,” or “Here’s a vague problem, write us a one-pager and a prioritised roadmap.” Eight to twelve hours of genuine, unpaid product work, dressed up as an assessment.

Here’s what actually happens with a lot of these. The strongest candidates, the ones with options, quietly opt out. They’ve got jobs. They’ve got lives. They’re not spending a Sunday building a fictional roadmap for a company that hasn’t even confirmed the salary band. So the exercise doesn’t filter for the best product thinkers. It filters for the most available ones. The desperate, the between-jobs, the ones who can’t afford to say no.

And the real tell is what happens to the output. I’ve watched perfectly good take-home submissions get a five-minute skim before a panel that had already made up its mind in the first interview. The exercise wasn’t evidence. It was ritual. A box to tick so the process felt rigorous.

There’s no penalty for designing a hiring process that wastes forty hours of candidate time across a shortlist. There’s no transparency indicator telling applicants how many people are really in the running, or whether the role is even properly signed off yet. The process profits from the appearance of rigour, even when the rigour is theatre.

Sound familiar? It should. It’s the same trick the job boards pull, just at the interview stage.

We Started Hiring For Vocabulary

Here’s the thing though.

The candidate I described at the top wasn’t a fraud. She knew her stuff. But what we actually tested, what the whole loop was optimised to surface, was fluency. Could she speak the language? RICE, MoSCoW, jobs-to-be-done, North Star, opportunity solution trees, the lot. Recite the catechism with confidence and the interview essentially scores itself.

The problem is that vocabulary and judgement are not the same thing. They’re not even close.

I’ve worked with PMs who couldn’t tell you the textbook definition of a North Star Metric to save their lives, and who would, without fail, make the right call under genuine ambiguity. And I’ve worked with people who could deliver a flawless lecture on prioritisation frameworks and then freeze the moment a real trade-off landed on the table with no clean answer and an angry stakeholder attached. Guess which one I’d rather have on my team when a feed goes down at 9pm before a weekend of fixtures.

We can’t easily test judgement in a 45-minute slot, so we test the thing that’s adjacent to it and easy to grade. Then we act surprised when the polished hire turns out to be brilliant at describing decisions and rubbish at making them.

Certifications Are the Gym Membership of Product

Let me be careful here, because I’m about to annoy a few people.

The product certification economy has exploded. Scrum-this, Agile-that, SAFe, AIPMM, a dozen “Certified Product Leader” programmes that didn’t exist when I started. You pay your fee, you sit through the modules, you get a badge for your LinkedIn banner. And here’s the uncomfortable truth: most of them change almost nothing about whether you can actually do the work.

They’re the gym membership of product management. The purchase feels like progress. You’ve taken action, you’ve spent the money, the badge says you’re serious. But the badge and the transformation are not the same thing, and everyone half-knows it.

I’m not saying the courses teach nothing. Some of the content is genuinely fine. The issue is what the certificate signals versus what it proves. It proves you paid and sat still for two days. It signals, to a tired recruiter scanning a hundred profiles, “this one’s legitimate.” And because hiring leans on signals when it can’t measure substance, the badge gets rewarded, the cottage industry grows, and we all pretend the correlation with actual ability is stronger than it is.

I did an MBA. I rate it for what it gave me. But I’d never confuse the certificate on my wall with the judgement I built from shipping things that broke and then fixing them. One is a receipt. The other is the actual education.

Frameworks Were Meant To Be Scaffolding, Not the Building

This is the one I find hardest to write, because I genuinely love a good framework.

I structure my team’s quarterly objectives around Tim Herbig’s Real Progress approach. I reach for frameworks all the time. Used well, they’re scaffolding. They give a messy decision a shape, they help a new team find shared language fast, they stop you from forgetting the obvious. That’s the point of them.

But somewhere the scaffolding became the building.

I’ve sat in planning sessions where more energy went into colour-coding the prioritisation matrix than into the actual conversation about what users needed. I’ve seen teams run a flawless discovery process, opportunity solution tree and all, and ship something nobody wanted, because the framework was treated as a substitute for thinking rather than a support for it. That’s cargo-cult product. Going through the motions of the ritual and expecting the outcome to follow, because the smart-looking people seem to do the ritual.

A framework can’t make a decision for you. It can only organise the inputs. The judgement, the bit where you stare at incomplete data and a real deadline and a stakeholder who wants the opposite of what the data suggests, and you call it anyway. That bit is irreducibly human, and it’s the bit no template covers. We keep dressing it up in process because the process is comforting and the judgement is terrifying.

The Job Descriptions Are Fiction Too

Quick one, because it makes me laugh and then makes me tired.

Read enough product JDs and you start to notice they describe a person who does not exist. Deep technical chops and slick commercial instincts and design taste and data fluency and stakeholder charisma, eight years of it, for a mid-level salary, ideally yesterday. The unicorn PM. A role written by committee, where every function lobbed in their wishlist and nobody had the nerve to cut it.

These descriptions aren’t really specifications. They’re aspirational fiction. And they do real damage, because the people most likely to self-select out are exactly the ones the research keeps pointing to: capable candidates who read the wall of requirements, decide they only hit seven of the eleven, and never apply. Meanwhile the role sits open for months while everyone wonders where all the good PMs went.

They didn’t go anywhere. They just took one look at the fiction and got on with their day.

So What Actually Tells You Someone Can Do This Job

To be fair, none of this means hiring is hopeless or that the craft is fake. It isn’t. Most of the PMs I admire are quietly excellent. The theatre is the packaging, not the work itself.

So here’s what I’ve started actually paying attention to, the bits that survive once you strip the performance away.

How someone reasons through a problem they’ve never seen, out loud, with no clean answer available. Not the framework they name, but how they handle the moment the framework runs out. Whether they can describe a real decision they got wrong, in specifics, without reaching for a tidy redemption arc. The ones who say “honestly, I called it wrong and here’s the messy reason why” tell me far more than the ones with a polished failure that conveniently turned into a win.

I look for evidence they’ve shipped something and lived with the consequences. Not the strategy deck, the aftermath. What broke, who complained, what they did at 9pm on a Friday. And I look for how they treat the engineers and designers in the room, because the job is mostly other people, and no certificate measures that.

None of these survive a tick-box process. They need a conversation, a bit of trust, and a willingness to score judgement over fluency even when fluency is so much easier to grade. Which is precisely why most processes don’t bother.

The deeper problem is that product management sits in an awkward spot. The output is collective and the timelines are long, so individual contribution is genuinely hard to measure. And when something is hard to measure, we reach for proxies. Vocabulary. Badges. Frameworks. The performance of rigour. We optimise for the proxy until the proxy becomes the job.

I don’t have a clean fix, and I’m wary of anyone who claims one. But I do think the first honest step is admitting how much of what we reward is performance, and how little of it is the thing we actually need. The good PMs were never the ones with the best vocabulary. They were the ones who could decide, ship, and own it when it went wrong.

So next time you’re on a panel, or sweating over which certification to buy, maybe ask the quieter question. Not “does this look like competence?” but “is any of this actually it?”

I’m still working out the answer myself.

If this resonated with you, or even just made you pause and think, I’d really appreciate a clap or two. It genuinely helps the article reach other product managers who’d find it useful.

And if you’re not already following along, I write weekly-ish about product management, AI tooling, and what’s actually working (and what isn’t) in my day-to-day as a PM in London. Hit follow and you’ll catch the next one.

If you’ve got value from my writing and fancy supporting the work directly, you can buy me a coffee here:

Either way, thanks for reading.