Product Manager Skills Should Center on Strategy While Engineers Ship the Code

Product managers are being told to become builders. But that doesn’t mean shipping code. Their skill set was, and should remain, setting and executing product strategy. They shouldn’t be the ones owning and shipping code. That was Ethan Cole's argument when he joined me on Stacked Sessions. Ethan is president of the Product Manager Association Los Angeles, a community of 5,000 product people, and he has run product at the NFL, NBC and DirecTV.

He's watching PMs pick up Claude Code and ship to production and thinks they are training the wrong muscle by taking features through to production. 

Why product manager skills are changing now

For most of product management's history, engineering capacity was the constraint. You could start a sprint with half of the work defined and still stay a ticket or two ahead of the developers. Nobody liked admitting it, but it worked, because building was the slow part.

That flipped in the last six to twelve months. Development is fast, which put more pressure on product to define the next thing. But that meant more untested ideas were being sent along that someone has to own and maintain. 

"Just because you can build it doesn't mean you should build it. In a world where capacity was the constraint, there was a limitation on the roadmap... Now it's really important to keep an eye on what you want to build, even though you can build more, because everything you build still has to be maintained."

He gave an example I keep coming back to. Jill builds an agent, then Jill leaves the company. Someone now has to maintain that agent, decide where it lives, and confirm it still does its job six months later, and nobody planned for any of it. Ethan expects that bill to come due for a lot of companies around the middle of next year, as fast-built software meets the maintenance nobody planned for.

I've lived this. In one of my first product jobs at Microsoft, we were deciding what belonged up front in the new Office ribbon. I don't remember the exact number, but well under 10% of the features in any given Office app were in regular use. The other 90% still had to be secured, patched, and carried forward. Software rusts. Every extra feature widens the surface someone has to defend.

At the WeAreDevelopers World Congress this year, I lost count of the people who told me some version of the same story. They had used agents to build out a pile of software, and now it was so bloated they didn't know what to do with it.

Just because building the thing is fast and cheap, does not mean that it is cheap. That puts pressure on the decision-makers to decide on what is worth building and maintaining.

Why Ethan says product managers shouldn't push code to production

Near the end of our conversation, I asked Ethan what most people in product management are wrong about right now. He didn't hesitate.

"I don't think that product managers should be doing the coding. I don't think that they should be pushing to production. I think that the specialization that they should have is what to build and not how to build."

He went further. Companies move faster when a developer owns the build, and the product manager owns the strategy. Some PMs are doing themselves a disservice by learning to code at a level below how well they already know strategy.

"Take that energy and double down on the strategy. Because I think strategy is gonna win out over how to build."

I agree with where he draws the line, and the line is production. A PM spinning up a throwaway prototype to test an idea with a customer is doing product work, the kind AI prototyping opened up to everyone. A PM shipping features into the codebase is doing a second job badly while the first one goes unattended.

There's a second reason his point lands. Marty Cagan has long drawn a line between the product owner and the product manager, and warned about PMs who end up administering a backlog instead of setting direction. Ethan's take is that the profession drifted there partly because the paperwork forced it. AI is now absorbing the ticket writing. The time it hands back is the most valuable thing a PM gets out of this shift, and spending it on learning to ship code throws the dividend away.

I made a related case in Should Product Managers Code?. Code literacy, knowing how the system fits together, belongs on the list. Production code belongs to engineering.

Every product manager now needs technical fluency

None of this lets anyone off the hook on technical depth. Ethan was blunt about it.

"For anyone who's out there who's kind of saying, 'Hey, I'm a non-technical product manager,' that's okay. That was okay seven years ago. In the world we're in, everyone needs to be technical."

Part of the pressure is competition. Ethan sees more engineers with 15 years of experience moving into product roles at PMA LA, looking to get product skills fast. Engineers have always moved into product, but the PM role itself is getting more technical, so the bar for everyone else is rising.

The roles are blending in both directions. Ethan pushed back on me when I described the PM as the only person in the pod who owns the problem. Developers can't just write code anymore, he said, and designers can't stop at aesthetics and usability. Everyone has to think about what the work does for the user and the business. We've written about the engineering half of that shift, where AI pulls engineers into product decisions.

The good news, in his words, is that it has never been easier to learn. The same AI that's raising the bar lets you skill up faster than any PM generation before you.

So the floor is technical fluency. You should understand your stack, your architecture and your constraints well enough to have a real conversation about them. Writing the code sits above that floor, in a lane Ethan thinks belongs to engineering.

Hiring managers want every listed product manager skill plus one or two more

The most useful framing in the episode came from a recruiter at Activision who spoke at a PMA LA event. Ethan and the group asked what it takes to get to the top of the pile. His answer was "you plus one or plus two."

You need every skill the job post lists. Then you need one or two more on top, because the market is hard right now. Layoffs haven't fully stopped, job growth is slower than people hoped, and more candidates are competing for each role.

The interesting question is which plus to pick. Given everything else Ethan said, coding to production is the weakest choice for most PMs, because it pulls you toward a lane engineering already covers. The stronger picks are the ones that make you better at deciding what gets built. He kept returning to business fluency.

Learn the voice of the wallet

Ethan said this might get him some flak, and he said it anyway. For roughly a decade, product management chased growth and engagement at all costs and lost its way. Since 2023, leadership has refocused on profitability, and he thinks that correction is warranted.

"A lot of product management was dedicated to the voice of the customer, but it was not always geared towards the voice of the wallet or purse of the customer."

At many of the companies he worked at, most people couldn't tie their work to specific revenue. There were KPIs and targets, but rarely a sentence like "we're building this because it moves the business in this specific way." That sentence is becoming a requirement for everyone in a tech company, PMs first.

I shared a story with him that still makes me wince. At one company, we were solving a painful problem for a specific user. Then we ran a product marketing exercise where you plot buyers by money and influence on one axis and pain on the other. Our user landed at high pain and no money. When I talked to that user's management about the fix, the response was roughly this: I don't care, if they burn out I'll hire another one.

That conversation changed what we built. We moved the work toward a problem someone with budget actually cared about.

Ethan put a name on the pattern. Product teams talk constantly about pain but rarely about types of pain.

"Are you solving the problem for an IC who, it's kind of a little annoying for them, and maybe they could speed up their processes by a couple seconds? Or is it a business pain where, hey, if you implement this new feature, you can help them generate 10 million more dollars?"

Each type deserves a different approach and a different priority. A PM who can sort requests that way, and explain the sorting to a stakeholder, has a plus one that no coding agent replaces.

Understand the code without writing it

Ethan's line leaves one practical gap. If PMs stay out of the codebase, they still need to know what the code allows before they commit to anything. Feasibility, dependencies, and what already exists all shape what's worth building because they determine potential impact, timing, and costs.

Allstacks Code Engine (ACE) closes that gap. ACE runs inside Allstacks Product Studio and acts like a dedicated senior engineer for the product manager. It answers questions about how your product's code works, helps assess technical feasibility, and checks requirements against the code that's already there.

Product Studio is an AI workspace where product teams and AI execute together. Each PM works with agents that hold their context, from customer voice and strategy to what's shipped and whether it worked. The agents do the research, analysis, and writing, and surface the decisions you need to make.

The PM makes the call, the agents turn it into technical details and work items, and the team reviews them before anyone commits. PMs get effort back to spend on deciding what's worth building, and the head of product gets decisions the whole team can see and trust. Engineering keeps the build.

If you're thinking about how this changes team shape, Jeremy Freeman's piece on rethinking the PM-to-engineer ratio picks up where this leaves off.

What to work on this week

1. Tie your last five shipped items to money. For each one, write a single sentence on how it changed revenue, cost or retention. The ones you can't finish are the ones to question before you build their sequels.
2. Sort your open requests by type of pain. Mark each as an individual annoyance or a business pain, and note who holds the budget. Bring that sort to your next prioritization conversation.
3. Pick your plus one. If you've been spending evenings learning to ship code, move a few of those hours to sitting in on sales calls or reading your company's financials.

‍

See what your code allows before you commit to building it. Product Studio gives your team one shared workspace for discovery, prioritization, and defining work, grounded in your code. Start for free.

‍

Frequently asked questions

What skills does a product manager need now?

The full set the job post lists, plus one or two more. Ethan Cole, president of PMA LA, argues the most valuable additions are strategic: deciding what's worth building, tying work to revenue, and telling business pain apart from individual annoyance. Technical fluency is now expected of every PM.

Do product managers need to be technical?

Yes. Ethan's view is that calling yourself a non-technical PM was acceptable seven years ago and isn't today. Technical here means understanding your stack, architecture and constraints well enough to make sound product calls. Production code stays with engineering.

Should product managers code or push to production?

Ethan argues they shouldn't push to production. Companies move faster when developers own the build and PMs own strategy. Prototyping to test an idea is still product work. For a deeper take, see Should Product Managers Code?

What does "you plus one or two" mean for product managers?

It's a hiring framing from an Activision recruiter who spoke at a PMA LA event. You need every skill the role requires, plus one or two extra strengths that put you at the top of a crowded candidate pool.

What is the voice of the wallet in product management?

It's the business side of customer feedback. Voice of the customer tells you what users want. Voice of the wallet asks whether solving it changes what the customer or your company spends or earns.

How can product managers understand the codebase without coding?

Sit in on code reviews, ask engineers how the system fits together, and use AI that can answer questions grounded in your actual code. Or use Allstacks Product Studio to answer questions about how the product works and to assess feasibility before committing to work.

‍