Last Thursday I was at the Design Leaders Happy Hour. Summer winding down, everyone comparing notes.
I ended up talking with a design leader who runs design at a large enterprise org, the kind that is big enough to have design program managers (DPMs) on staff. We got onto DesignOps, and she said something that has stayed with me these past few days. She is trying to work out how her DPMs refocus. What they should become.
Peter Merholz asked me a version of the same question when I was on Finding Our Way. I have very mixed feelings about the role.
DPM is a bundle of work that used to travel together. Roadmap coordination, ritual facilitation, cross-functional liaison, reporting, risk escalation, documentation, intake, tooling administration, resourcing, vendor and budget management, and quality stewardship. Eleven or twelve different things, held by one person, because the workflow that produced them was coherent enough to bundle.
That coherence is what came apart. Some of those tasks a tool now does. Some can shift to a TPM who is already doing the same work and should have the capacity to cover. Some require genuine judgment and need someone accountable. And some are producing artifacts like dashboards nobody reads anymore.
Once you see it as a bundle of work rather than a role, the hiring question changes shape. You stop asking whether to hire a DPM and start asking which pieces you actually need held, and by whom. Also, if we free DPMs from some of the work, what else should we add to their day-to-day responsibilities?
This is the same argument I made in Stop Doing the Work. Start Building Enablement, applied to one role instead of the whole function. Ops builds the system. Sometimes the system is a person, and sometimes it is not.
I went to Indeed in August and searched for exact phrases, United States, on the same day. “Design program manager” returned 33 openings for me. “Technical program manager” returned 2,852.
I wouldn't read any job board posting number alone. It is a signal. What I am interested in is the ratio. Same source, same day, same method makes the ratio worth something. For my search, roughly one to eighty-six, DPM : TPM.
That ratio is what helps me see the potential. Companies are far more aligned on hiring TPMs and more willing to fund the practice. Using that capability, and collaborating with the team that already has it, is the least resistant way to get things done.
So, the counterargument. TPM is not DPM. A DPM understands the design team.
True. But the role itself is already changing. In my conversations with Peter and Jessie James, I have been pushing on this: take the traditional DPM out of the design org and point them at cross-functional operations; educate the non-design org on how design works.
You don’t have to take my word for it. Look at what companies are actually hiring operators to do. The shift isn’t happening only inside DPM titles. Look at the job description for this Product Operations Manager posting. This is where the fluid role needs to move.
“At Gusto, building a great product and delivering a great service aren’t separate tracks — they have to move together, and that’s what Service Transformation Product Operations exists to ensure. As a Principal Product Operations Manager, you’ll own some of the most cross-cutting work in the Customer Experience org: shaping how new products and features come to market, leading service design that identifies where AI can create the most leverage across the service experience, and operating as the connective tissue between Product, CX, Engineering, Legal, and GTM. This is not a coordination role — you’ll drive strategy, build and deploy AI-powered workflows, and bring rigor, creativity, and a bias toward execution to problems that don’t yet have obvious answers.”
Connective tissue. Not a coordination role. Somebody else wrote my argument into a job posting.
So, the postings themselves are more interesting than the count.
Stripe was hiring a Design Program Manager, AI. The role is to “identify and document the highest-leverage workflow transformations within Design’s day-to-day work” and to “build custom tools, agents, automations, and skills tailored to Design’s specific workflows,” then “track individual and cohort progress rigorously against a defined maturity model.” Program coordination barely appears. That is an enablement job. Also a DesignOps engineering job.
Cisco was hiring a Design Program Manager, AI Transformation and Foundations, to “own program management for AI Transformation and Design Foundations initiatives, including AI methodology, AgenticOps, AI education, governance, adoption, and cross-portfolio design readiness.”
I also found a repost of the Figma role on Built In, since the original posting has closed. What I found there was a specific description of how DPM and TPM should work together. It is the first time I have seen a company spell it out, and they list it as a deliverable of the job: “Define our playbook for how DPMs operate alongside TPMs and other cross-functional partners” (Figma, 2025).
So where does the work go?
I’ve identified more than 30 typical DPM tasks in the next post. Beyond Coordination, I also created a worksheet so you can map them against your own role. Which tasks are being automated? Which are shifting to other teams? Which require more judgment?
Here’s a sample of the work and where it might fit. Your organization might take a different approach.
The traditional DPM role has been about making the design organization run smoothly. The evolving DPM role should be about making the organization better at working with design.
Tools won't do all of the DPM’s work. But I believe DPM responsibilities are shifting, as they are for most roles in tech right now. Many organizations have already changed the requirements.
So what does the DPM become when coordination is no longer the center of the job?
I see a combination of “old” and “new” responsibilities for the DPM role
designing cross-functional operating systems
improving how Product, Engineering, Research, and Design work together
identifying workflow friction
building AI-enabled workflows and tools
creating enablement beyond the boundary of “design”
establishing governance
improving organizational readiness
translating design practices for non-design partners
In my own work, I had always prioritized ResearchOps, ContentOps, and DataOps over a traditional DPM role. Partly because the company I worked for always had a large TPM practice that overlapped with many DPM tasks. For those organizations that have a large DPM team, the old way of doing operational work will be replaced, and it should be. But it opens new possibilities for operators.
The question for DPMs isn’t whether the role survives. It’s whether they continue to define their value through coordination, or through the systems, decisions, and capabilities they build.
The title may or may not stay. But the org will benefit from the expanded capability.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.