I've been doing product management for years. My title said design.
October 13, 2026
Thank you!
Your submission has been received!
Your submission has been received!
Oops! Something went wrong while submitting the form.
Who is this for? What are we trying to change for them, and how will we know it worked? What will it cost, how big a bet should we place, and what has to be true for it to pay off?
I've spent about twenty years working through those questions with founders, CEOs, product leaders and engineering teams. My title has almost always said design. The work has always included the product management: discovery, prioritisation, packaging, roadmaps, writing the stories, sizing the bets and watching what customers actually did once we shipped.
So when I look at product management roles now, I don't see a career change. I see the same work with the accountability written into the job description. This piece is my attempt to say where the two disciplines overlap, where they still differ, and why I think the difference sits in who answers for the outcome rather than in how anyone thinks.
A CV list of activities doesn't say much, so here is how the work has grouped itself across the companies I've worked with.
Finding what's worth building. Most of my best work started with discovery done directly with founders and CEOs: at PatientPop, Blackpanda, Skills Aware and Chime Labs, and for a stretch at Smokeball alongside the CEO and the CPO. We'd map who the customer was, who was paying, which assumptions the plan rested on and which of them we could test cheaply. In several of those engagements the recommendations became the organisation's strategy. At PatientPop that discovery work helped shape the concept and positioning of a patient-to-provider marketplace, which Tebra later grew into a growth and revenue channel. It's still live as Tebra Care.
Choosing the bets and sizing them. Impact against effort and cost, risk against confidence, the commercial case next to the customer case. At Chime Labs that meant repositioning the product into three tiers, which is packaging as much as design. On SquadSpot, my own platform for Australian shooting clubs, it meant working out how card fees reach members once surcharge rules changed. Neither of those is a screen. Both are product decisions with money attached.
Sequencing and seeing it through. Roadmaps, swimlanes, strategic dependencies, thousands of user stories, and then the part I care about most: watching usage and adoption after release, because shipping is where the real evidence starts.
Along the way I've mentored product managers as well as designers and engineers. I don't offer that as proof that I've mastered every corner of product management. I offer it because the conversations were about prioritisation, stakeholder trade-offs and evidence, and I'd been doing those things long enough to help.
None of this is a personal quirk. Outcomes and business goals have sat inside user experience practice for a long time.
Jesse James Garrett's Elements of User Experience puts site objectives and user needs at the base of the whole model, beneath scope, structure and surface, and treats scope definition and prioritisation as design work. Garrett was careful not to prescribe who does each layer. That's the point: the subject matter is shared even when the titles aren't.
Google's HEART framework, published by its UX researchers in 2010, measures Happiness, Engagement, Adoption, Retention and Task success. Adoption and retention are exactly the numbers a product manager is asked to move. They came out of user experience research.
The history runs the other way too. Neil McElroy's 1931 memo at Procter & Gamble argued for one person responsible for a brand's performance, investigating problems and correcting course. It's an ancestor of product management, written for soap and advertising long before software. So product management didn't appear because designers failed to own the business. Several disciplines have been circling the same concerns for decades, and they still overlap.
If the thinking overlaps this much, what is the difference? I've found it easiest to see at the moment a decision costs something.
Take a familiar one. A large customer wants a feature that would pull two engineers off the roadmap for a quarter. Plenty of people on the team can research it, sketch it and estimate it. The question is who commits the team's time, who says no to attractive revenue if it doesn't fit the strategy, and who answers for the result either way.
I separate that into four things:
A product designer and a product manager can share the first almost entirely. The title mostly changes the second and third. That's why moving into product management feels to me like a change in what I'm accountable for, with the way I think staying much the same. I've carried the first for years; the PM role is where I put my name to the second and third as well.
Anyone who has drawn a RACI chart will recognise the pattern. The work can have several people marked Responsible, but only one Accountable, and accountability isn't delegated. For most of my career I've been Responsible for a lot of the product thinking and Consulted on the commercial calls. The PM role is where the A sits.
Titles don't settle this neatly. A PM title doesn't automatically bring budget approval or make anyone a mini-CEO, and plenty of designers carry real commercial responsibility without the badge. Marty Cagan's four big risks give value and viability to product, usability to design and feasibility to engineering, while insisting the three discover together. It's a useful operating model. I read it as a sensible default for allocating accountability, and teams should still fit it to the people they actually have.
The fair comparison is a strong designer against a strong PM. Set against a weak PM who runs tickets and ceremonies, anyone looks good.
A strong PM brings depth that design training alone doesn't supply: pricing and distribution, the difference between the buyer and the user, unit economics, contractual and regulatory constraints, governance, and commitments negotiated across teams that don't report to them. That last one is underrated. Holding a roadmap together across sales, support, engineering and the executive team is its own craft.
The reverse holds as well. Commercial fluency doesn't give anyone the craft to make an interaction coherent, accessible and trustworthy. And there's a real argument for keeping someone in the room whose job is to protect the user from commercial pressure. If one person carries both, that protection has to live in how they work, through research quality, accessibility standards and long-term trust, because a separate title is no longer guaranteeing it.
Where my experience sits is the intersection: weighing business value and customer value as equals, on customer-facing products, with capable engineering partners beside me. Founder and consulting work is a big part of why. When it's your own platform, or you're the person a founder hands the hard problem to, nobody else is holding the commercial side. You learn pricing, packaging and go-to-market because the product doesn't survive otherwise.
AI has made it cheap to prototype, to test an idea against real data and to cover adjacent work that used to need another person. In my own practice the loop from question to working prototype to customer feedback now runs in days. That makes it practical for an experienced person to carry more of a small team's product loop than before.
There's some evidence for the direction. In a field experiment published this year, Procter & Gamble professionals working alone with AI produced product ideas that matched teams of two working without it, and the AI helped individuals balance technical and commercial thinking. The limits matter: it was one company, one working day, and innovation tasks rather than months of delivery. The benefit showed up mostly in generating ideas, with little gain in picking the right one.
That last finding is the one I'd underline. Faster output means more options to judge, more risk reaching production and more coordination. When building is cheap, the scarce work is deciding what's worth building and getting customers to adopt it. That's product management work, and it rewards people who've spent years close to customers and engineers.
The strongest counterargument comes from Cagan and Bob Baxley's Product, Design and AI. They accept that some people are skilled across disciplines, and warn that the time demands usually make combining the roles unsustainable. I take that seriously. Capacity is the fourth item on my list for a reason. Cagan's newer definition of the product role centres it on discovery, value and viability, and allows that those skills aren't exclusive to people with product titles. The specialisms aren't disappearing. What's changing is how much of the loop one experienced person can sensibly hold.
My argument is modest. Product judgement has never belonged exclusively to people with PM on their business cards, and teams get more from experienced people when they allocate work around what those people have demonstrated, instead of around a default org chart.
For a small team, that can be a simple exercise. Write down who owns each risk and each outcome. Name the expertise that's missing. Make sure whoever carries the product has real access to engineering and commercial partners. Then review the workload and the results after a quarter, and adjust.
As for me, I've done the thinking for twenty years under a design title, discovering the problems with founders and teams, weighing value for customers and the business, and seeing the work through to adoption. What I'm looking for now is the role that makes the accountability explicit: answering for whether the product works commercially as well as for the customer, alongside a team I can help do its best work.