Geoff Charles, CPO at Ramp, recently described three paths for product people: the technical PM, the tastemaker PM, and the GM. Lenny shared it, and it made me reconsider how we hire.

I had read those as variations of one job. A PM could be more technical, more design-minded, or more commercial. But each path calls for different skills and evidence. A generic PM interview can miss those differences.

What AI changes

Agents can help PMs draft specs, summarise customer calls, and track decisions. Someone still has to check the work and resolve disagreements.

I would put less weight on coordination when hiring and more on the decisions a person can make and the results they can own.

I read Geoff's framing as three responsibilities. Someone must own outcomes, someone must make design decisions, and someone must make releases safe. Everyone in those roles needs to understand what AI can do and where it fails.

Three seats

Outcome owners. They decide which customer problems the team will address and what success means. They make commitments about scope and dates, track the results, and decide what the team will refuse to build. This is closest to the GM path.

Tastemakers. They make decisions about how the product works for the person using it. They decide what an empty state should explain, how an agent should ask a question, and when it has enough information to act. Their work needs to hold up in use.

Factory builders. They build the checks and tools that make releases safe. For example, a team might require an agent to pass a set of customer scenarios before a new version goes live. A change to the agent's permissions might also need a person's approval. Someone has to design those checks, keep them useful, and make them part of the release process. That is what I mean by the factory.

These responsibilities can overlap. A technical PM might work on both the product's behaviour and its release checks. Name that scope when hiring. The title "AI PM" tells a candidate little about the job.

What this changes in hiring

I would ask candidates which of these responsibilities they have already held and what happened as a result.

Look beyond job titles.

  • A founder or account owner who was responsible for revenue and made difficult choices about customer requests may be a strong outcome owner.
  • A designer or design engineer who can explain decisions they shipped under real constraints may be a strong tastemaker. Ask what users did and what they changed after release.
  • An engineer who helped a team release safely with less manual intervention may be a strong factory builder. Ask how the process worked when that engineer was away.

Ask an outcome owner what they would refuse to build and why. Ask a tastemaker to explain when an AI feature should ask for help. Ask a factory builder how they would catch a bad change before customers saw it.

Ask for evidence of how the candidate made a decision, tested it, and dealt with the result.

The title matters less

These jobs may still carry a PM title. They may also belong to general managers, designers, or product and platform engineers.

Some people can cover more than one responsibility. That does not mean a team should assume one hire can cover all of them. I would make the scope explicit and look for evidence that the person can handle it.

The useful question is what the person will be accountable for.

What I would change in a team

Give each area a clear outcome owner. Decide who can commit the team to a result and who can change its priorities. Start with the decisions that need an owner before deciding how many PMs to hire.

Keep designers close to the work. The people making design decisions need access to customers, engineers, and the product as it changes. An occasional review at the end is too late.

Make release decisions explicit. Write down what people and agents may change, which checks a release must pass, and when someone must approve it. Name who maintains those rules.

The test

I would judge this structure by whether the team can make sound decisions and ship useful changes without its leader in every discussion.

Customers still need a reason to use the product and renew. Adding more PMs is only useful if it helps the team deliver that.