It’s a Monday morning in 2017. Two pharmaceutical companies have just merged. I’m walking into a conference room where the people on my left and the people on my right have never worked together, have different ERPs, different vocabularies for the same processes, and a CFO upstairs who needs a unified supply chain forecast in ninety days.
Nobody in that room knew it yet, but we were going to get there. Not because of any heroics — because the boring, unglamorous work of M&A integration is what I had been training for the previous five years without realizing it.
That morning is what I think about when someone asks me why they should hire me. Not the deck. Not the certifications. That conference room.
The only skill that matters
Enterprise product management is not about roadmaps. It’s not about Jira hygiene or stakeholder slides or whatever the LinkedIn discourse has decided this month. It’s about one skill, and only one: making sense of complexity faster than it accumulates.
Everything else — the frameworks, the rituals, the certifications — is scaffolding around that one capability. M&A integrations are where you learn it the hard way, because complexity arrives in waves: two finance teams, two compliance regimes, two manufacturing footprints, two cultures, and one quarter-end that doesn’t care.
I’ve done four of these. Each one taught me something the last one didn’t.
What ten years at Takeda actually bought me
Takeda Pharmaceuticals isn’t a name that lights up the resume scanners the way FAANG does. That’s a feature, not a bug. Pharma is where you learn to ship under regulatory constraint, where the cost of a wrong call is measured in patient outcomes and DOJ subpoenas, not refund rates.
Across ten-plus years there:
- Four M&A integrations led to completion — not “supported,” led. From day-one operating model design through systems migration to the boring sustaining work twelve months out when everyone else has moved on.
- $6.3M+ in documented savings delivered — verified through finance, not hand-waved through a slide.
- PMP-certified — not because the cert is magic, but because it’s a shared vocabulary with the operators and PMOs who actually move money.
If you’re hiring a Senior PM to ride a stable product, I’m probably not your person. If you’re hiring someone to walk into a system that’s mid-restructure, mid-merger, mid-platform-migration, or mid-AI-pivot and bring the chaos down to legible work — that’s the muscle I’ve been training for a decade.
I’m not a PM who learned to prompt
The AI section of most PM resumes right now reads like a checklist: “ChatGPT, Copilot, RAG, agents.” It’s usually copy-paste. The real question hiring managers should be asking is: can you tell me where the model ends and the product begins?
That distinction is where AI products live or die. I’ve been hands-on with this — not as a consumer, as a builder. I’ve shipped agent workflows, debugged retrieval, watched evaluation eat hours and learned to instrument it cheaper, and developed an honest intuition for when an LLM is the right tool and when you’re laundering a deterministic problem through a stochastic one because it’s fashionable.
That last sentence is the one I’d want you to remember. The next decade of enterprise product hiring is going to filter brutally on it.
I’m AI-native in the way someone who grew up with the internet is internet-native — it’s part of how I think about a problem, not a separate skill I switch into.
Fifteen years in front of a classroom
For the last fifteen years I’ve been an adjunct professor teaching operations, supply chain, and project management. Hiring managers usually file this under “nice extracurricular.” I think it’s the most underrated qualification on my resume.
Here’s why: teaching the same material to a new room every semester for fifteen years is an unforgiving feedback loop on whether you can actually explain something. Bad explanations get punished — by glazed expressions, by failed exams, by course evals. Good ones compound. You leave with a calibrated sense of what’s hard, what’s only-pretending-to-be-hard, and which mental models survive contact with a junior engineer who’s never seen the problem before.
A PM who can teach is a PM who can onboard a team in a week, surface the right diagram in a stakeholder meeting, and write a spec that engineering doesn’t have to translate. That’s not soft skill — that’s velocity.
What you’re actually buying
Concretely, in a role:
- A senior PM who can run an enterprise-scale program (M&A, platform migration, AI rollout) end-to-end without needing a PMO to babysit it.
- Real AI/ML build judgment — what to prompt, what to fine-tune, what to leave deterministic, and how to evaluate any of it honestly.
- Regulated-industry pattern recognition. If your domain has compliance, audit, or risk teams as stakeholders, I’ve already had a version of every meeting you’re about to have.
- A teacher’s mindset on internal communication — clear specs, clean frameworks, decisions that survive being explained to the person three meetings downstream.
- Chicago-based. Comfortable on-site, on a plane, or in a Zoom grid.
What you are not getting: someone who needs to be managed, someone who treats PM as ceremony rather than craft, or someone who outsources the thinking to a framework.
The conference room, again
I think about that Monday in 2017 a lot. Not for nostalgic reasons — because it’s the cleanest test I know of for whether someone should be in this kind of role.
If you can walk into a room where nothing works yet, nobody agrees, and the deadline is non-negotiable, and ninety days later the thing exists and is running — you belong here. If you can’t, no amount of certification will fix it.
I belong here. Ten years, four integrations, and several thousand hours in front of a classroom is the receipt.
If you’re hiring for a role where that experience matters, let’s talk. Start a conversation.
Leave a Reply