Are you a Product Builder or a Product Architect?

Product management still has no agreed job description. Ask five leaders what a senior PM does differently from a mid-level one and you get five answers, most of them adjectives. That vacuum is why promotion conversations turn into vibes, and why "I want to grow" is such a hard sentence to act on.

The closest thing I have found to a real definition is Ravi Mehta's competency model. Mehta is a former CPO at Tinder and a product leader at Meta, Tripadvisor and Xbox, and the model came out of work he and his colleagues did at Tripadvisor. It codifies 12 competencies across four areas, and it is as close to mutually exclusive and collectively exhaustive as product management gets.

I have used it in coaching sessions and in the "Level up your career" workshop I ran at the Product Management Festival, and the same thing happens every time. People come in wanting a score. They leave with a shape.

The four areas, and the twelve underneath them

Mehta's four areas, in his words:

• Product Execution - the ability to build exceptional products. Feature specification, product delivery, quality assurance.
• Customer Insight - the ability to understand and deliver on customer needs. Fluency with data, voice of the customer, user experience design.
• Product Strategy - the ability to drive business impact via product innovation. Business outcome ownership, product vision and roadmapping, strategic impact.
• Influencing People - the ability to rally people around the team's work. Stakeholder management, team leadership, managing up.

Read that list slowly and notice what is not on it. There is no "writes good tickets". No "runs a tidy backlog". Mehta's framing is that peak PMs don't just ship features, they do whatever it takes to deliver valuable outcomes for their users, their team and their company. Every competency on the list is in service of that, which is also why defining the job by its artifacts fails.

Two shapes, over and over

Score yourself honestly across all twelve and a chart appears. In practice it almost always leans one of two ways.

If your chart leans towards execution, you are a Product Builder. In Mehta's blunt phrasing, you like to get shit done, and you're good at it. Things ship. Deadlines hold. Engineers like working with you because you unblock them instead of adding process.

If your chart leans towards strategy and insight, you are a Product Architect. You can see the product that should exist and explain why it matters commercially. What you may lack is some of the skill to bring it to life.

Neither shape is the good one. That is the whole point of having two axes instead of a single seniority ladder.

If you lean Builder, learn to build the right thing

The Builder's failure mode is velocity without direction. You are very good at getting a thing out of the door, so nobody questions whether it was the right thing, least of all you. Six months of clean delivery later, usage is flat and the retro blames the market.

The fix is not to ship less. It is to put a discovery step in front of the shipping, so you find out what to build before you code it. Start with the cheapest habit available: talk to customers about the problem rather than the feature, and test the risky assumption before it costs a sprint. If you want the mechanics, this is what product discovery actually involves, and the honest version takes less time than the rework it prevents.

Strategy is the other half. A Builder who learns to say what the team is not going to do stops being a very fast order-taker. That is the shift from output to a strategy that actually rules things out.

If you lean Architect, get closer to the build

The Architect's failure mode is a beautiful deck and a stalled roadmap. The vision is right. The commercial logic holds. But the thing does not exist, because turning it into something a team can ship on Tuesday needs competencies that sit in the other half of the chart.

Mehta's advice here is worth taking literally: invest in your strengths, and pair yourself with a strong Builder. Product Architecture competencies are of outsized importance right now, and you should not sand them down to become a mediocre generalist. You should find the person whose chart mirrors yours.

That pairing is easier to arrange than most people assume, because it is already how good product teams work. The trio exists precisely so no single person has to be excellent at everything.

Why this is more useful for the team than for you

The individual version of this exercise is mildly interesting. The team version is the one that changes decisions.

Put four PMs' charts side by side and you can see, in about a minute, what your product org is structurally bad at. If every chart leans Builder, you have a delivery machine with no one asking what it is for, and you will keep shipping features nobody uses. If every chart leans Architect, you have a lot of strategy documents and a slow roadmap.

That is also the honest way to write a job spec. "Senior PM, 5+ years" tells a candidate nothing. "We are strong on execution and weak on business outcome ownership, and this role owns that gap" tells them everything, and it filters correctly.

It is worth saying what the model does not give you: authority. Influencing People is a competency, not a mandate. Even a PM who scores well across all twelve is still working through other people, which is why product managers are not mini-CEOs no matter how good their chart looks.

How to actually run it

Three steps, one hour.

Score yourself across the twelve. Be specific about evidence. "I own business outcomes" is a claim; "I set the activation target for this quarter and reported against it" is evidence. If you cannot name the evidence, the score is lower than you think.

Get your manager to score you separately. The gap between the two charts is the actual output of this exercise. It is usually one or two competencies, and it is usually the reason a promotion conversation has stalled.

Pick one competency, not four. Attach it to real work already on your plate rather than a course. If the gap is voice of the customer, the development plan is five customer interviews this month, not a certificate.

Product success requires both vision and execution. Almost nobody arrives with both, and that is fine - the job is to know which one you are short of, and either close it or hire it. If you are trying to work out which gap your team has and who should own it, that is the kind of thing our product advisory work is for.