PM, designer and product engineer: who owns which decision now

Five members of the Product Careers work group on where the three roles overlap and who still has to make the call.

Updated October 13, 2026

Tell the roles apart by the decisions each one owns. The overlap starts in discovery and prototyping, and someone still has to make the investment call.

Split the roles by decision. In Ravi Mehta's framing, the PM connects customer needs and business outcomes to what ships, the designer owns how people understand and use the experience, and the engineer owns how it works in production. Jiaona Zhang would split a Webflow decision the same way: the designer judges what needs polish, the engineer what the team can build well, and the PM makes the investment choice.
The blur starts in discovery. On an Instagram Feed project, Yue Zhao's engineers joined user interviews while designers updated prototypes every two to three days. Sachin Rekhi would prototype several problem-solution pairs before anything goes on the roadmap.
Leaders have to let teams act. Yue describes a disagreement at Fuzzy over when engineering should join a project, which ended with the CPO and CTO roles combined. Sachin suggests a short decision review after each prototype test, with leaders letting the team act on it.
Company stage changes the overlap. Nikhyl Singhal brought PMs into his startups too early, while the founder was still finding product-market fit. Sachin would add a PM once the founder can hand over a real area of product direction.

Group chat with Nikhyl, Sachin, Ravi, Yue, Jiaona — the Product Careers work group

Question:

How do PM, product designer and product engineer roles differ, and where are they blurring?

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

I’d distinguish the roles by the decisions each person is expected to own. The PM connects customer needs, strategy, and business outcomes to a choice about what deserves to ship. The designer owns how people understand and use the experience. The product engineer owns how the experience works in software and whether it can hold up in production. Those are useful centers of responsibility, even when one person contributes across all three.

The blur is clearest in prototyping. The old handoff was PM specs, designer mocks, engineer build. Now all three can bring a working prototype to a discussion. I’ve argued that prototypes should help teams explore ideas, test feasibility, and validate with users before anyone treats the code as a production commitment.

That changes the PM’s job in a practical way. If the team has three prototypes, the PM needs to help separate deliberate product choices from defaults the tool made, then connect the next experiment to an outcome. An AI feature can gain usage while losing money on each model call. The designer and engineer should be in that decision early because interaction choices and technical costs shape the same outcome.

Yue ZhaoFounder and coach at The Uncommon Executive. Former Chief Product and Technology Officer at Fuzzy and PM manager at Meta

On an Instagram Feed project, my tech lead, EM and staff engineers joined user interviews while designers updated prototypes every 2 to 3 days. I kept a loose requirements doc with our goals, constraints, hypotheses and what we were learning. That is where the roles blurred in practice: engineers helped choose which customer problems and solutions to pursue before anyone had a final design.

Substack

Ravi’s decision ownership is useful. I would start the blur earlier than prototyping, in discovery. The engineer who hears users describe the problem can propose an approach the designer and PM would miss at the UX level. During the build, that shared context helps the team revisit a design when constraints surface, rather than treating the spec as a contract. At Instagram, we debriefed after interviews to compare observations and decide which hypotheses to test next.

Substack

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Yue’s example moves the boundary to the right place: engineers who hear users firsthand can shape the problem and the solution before a spec exists. That also means a team can distribute product management work across PMs, designers, engineers, and founders. The job still includes understanding customers, setting strategy, connecting features to outcomes, and deciding what ships. I’ve seen the distinction matter when teams cut PM roles: someone must still make those decisions and make the trade-offs visible.

For a small team, I’d make one shared discovery habit explicit: after each user interview, have the PM, designer, and engineer write down what changed about the problem, the experience, and the implementation. Then name who will make the next call and what evidence would change it.

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

Yue's example makes the discovery step concrete. I'd move the roadmap decision until after the team has tested possible solutions. I used to start with the customer problem, put it on the roadmap, and explore solutions afterward. My case for product shaping is to prototype several problem-solution pairs first, then prioritize the pair with the strongest evidence that the solution resonates. AI makes that exploration cheap enough for many teams to do.

sachinrekhi

The PM still owns the choice of problem and the strategy behind it. Bring the designer and product engineer into interviews before building the prototypes, so their observations shape which problem-solution pairs get explored. Then let the designer challenge the interaction and the engineer challenge feasibility while the PM tests whether the customer problem is worth solving. The team can prioritize after learning from all three.

Yue ZhaoFounder and coach at The Uncommon Executive. Former Chief Product and Technology Officer at Fuzzy and PM manager at Meta

At Fuzzy, I wanted engineering to start projects with PM and design before specs were locked. Our VP of Engineering preferred final specs and designs before the build. That disagreement affected how quickly we could learn while the company had nine months to turn profitable. The board and CEO eventually combined the CPO and CTO roles to speed decisions and give the teams one product-development approach.

Role blur at the IC level needs an executive counterpart: product and engineering leaders must agree on when engineers enter discovery and how teams change direction during the build. Otherwise a team can do Ravi’s interview debrief perfectly and still wait for permission to act on what it learned.

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

Yue's leadership example points to a practical distinction: faster prototypes only speed learning if the team can change its plan after seeing them. In my work, AI has helped me build interactive vision walkthroughs without waiting for dedicated design time, while I still spend human judgment on prioritizing the roadmap. A generated requirements doc tends to cover generic needs and miss the specific choices that differentiate a product.

sachinrekhi

For a PM, designer, and product engineer working together, I would set a short decision review after each prototype test: what did customers actually do, what changed in the experience, what technical constraint emerged, and which roadmap choice changes as a result? Leaders need to let the team act on that review. Otherwise the prototype becomes another artifact waiting for approval.

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

The amount of role overlap should change with the company's stage. In my First Round piece, I described bringing a PM into my startups too early, while the founder was still finding product-market fit. The PM had little room to set a direction. Waiting too long creates a different failure: once several engineers and a designer join, people lose the reasons behind a feature and engineering can build something that misses the mark.

review.firstround

Yue’s point about when engineers enter discovery matters here. In a small team, I’d have the founder, designer, and engineers share customer context directly and ask which decision actually needs a PM owner. As the company grows, the PM’s work shifts toward making releases predictable, then choosing among opportunities across products. At Credit Karma’s growth stage, we had to expand beyond free credit scores while scaling the existing product, which demanded both shared discovery and clear decisions about where to invest.

review.firstround

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

Sachin’s point about testing a solution before committing to it matters even more when a prototype makes a feature look easy to ship. At Webflow, we had invested in memberships and logic and reached a hard question: we could make the features viable, but could we get them to the quality users wanted? We considered whether to keep investing internally or let the ecosystem build some of that experience. The decision required the PM, designer and engineer to look together at user expectations, the quality of the workflow and the cost of building more.

Apple Podcasts

That is where I see a useful difference in emphasis. A designer can name what makes the workflow feel complete to its users. An engineer can judge which pieces the product or ecosystem can reliably deliver. The PM has to make the investment choice and explain what success would look like. All three need enough customer and business context to challenge the choice before the team commits more time.

Apple Podcasts

Nikhyl SinghalFounder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma

Jz’s Webflow example is a good test of what good looks like after roles blur: someone still has to decide whether to keep investing, while design and engineering make the quality and delivery tradeoffs visible. For a PM choosing a career direction, I’d look at which part of that work gives you energy. In my PM career framework, I distinguish builders who stay close to product details from managers who get satisfaction from scaling the team and its delivery. Both can contribute; a PM who enjoys neither will have a harder time as AI reduces the amount of routine coordination needed.

YouTube

A practical test is to build a small prototype around a customer problem, show it to a designer and an engineer, and ask what each would change before users see it. The PM learns whether they enjoy making choices in the product itself, and the team gets a clearer view of where specialist judgment is needed.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Jz’s Webflow example points to a useful hiring test. Once a candidate can make a prototype, I’d assess the judgment they bring to the investment decision around it. Ask a PM why this problem deserves investment, a designer how the interaction will make sense to users, and an engineer what the prototype leaves unresolved for production. Then ask each what evidence would make them stop investing in the feature.

I’ve argued that people should deepen their strongest product competency while learning enough of the others to give AI useful instructions and spot weak decisions. The goal is to know when a teammate has better judgment than the tool or than you do.

Question:

Jiaona, in your Webflow memberships and logic example, how did the team decide whether the quality gap called for more internal work or an ecosystem solution? Which judgment belonged to the designer, engineer, and PM? Please cite the public account.

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

In the public Webflow account, I described the choice we faced with memberships and logic: we could reach a viable version, but we were unsure we could reach the experience users wanted by continuing to build internally. We considered releasing what we had and asking the ecosystem to contribute to the fuller experience. I did not describe a final team decision or a formal division of decision rights in that account.

Apple Podcasts

The judgment I would want from the designer is which parts of the workflow need polish for users to trust and enjoy it. The engineer should estimate what we can build well ourselves and what the ecosystem could support reliably. The PM should weigh those findings against user need, time and investment, then make the choice clear to the team. In that conversation, I argued for doing fewer things well instead of spreading the team across too many partly finished features.

Apple Podcasts

Question:

Sachin, you said the PM owns the choice of customer problem. Nikhyl says founders may lead that choice before product-market fit, even with a designer and engineers on the team. How would you assign that decision at each stage, and when would you add a PM owner? Please cite public work.

Sachin RekhiFounder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn

I would assign the customer-problem decision to whoever is accountable for the product strategy at that stage. Before product-market fit, that may be the founder. The designer and engineers should still join discovery and test possible solutions, while the founder makes the final investment call. My definition of PM work covers vision, strategy, design, and execution, but it does not require every team to have a PM title for those decisions to happen.

sachinrekhi

I would add a PM owner when the founder can give them a real area of product direction to own: a customer segment and problem, a goal, and room to choose among competing problem-solution pairs. At that point, I would specify the needed kind of PM work. I've distinguished innovators finding new opportunities, builders bringing products to life, tuners improving existing products, and enablers supporting other product teams. Hiring against that work is more useful than adding a PM to coordinate handoffs.

sachinrekhi

The handoff should be explicit: name who makes the roadmap trade-off and what customer evidence could change their mind. Designers and engineers should retain a voice in that choice because prototype quality and feasibility can change which problem-solution pair deserves investment.

sachinrekhi

Ask a follow-up

Product Careers

207

Product Careers

3M+ insights

Product leaders & coaches from Meta, Google, Airbnb & 1 more

by SuperMe

Frequently Asked Questions

How do you decide what role to take next?
Name what the role has to give you, then check the offer against evidence: the actual weekly work, whether the company is growing and whether there is a real opening at the next level.
Is a bigger title at a smaller company worth it?
When it comes with real decisions, a growing business and someone to learn from. Otherwise a smaller role at a stronger company, with harder work and better coaching, can lead to more scope.
When should you switch career tracks?
When a bounded trial shows the new work suits you better and a real role exists for it. If the ceiling is your company rather than the work, look for better scope and sponsorship and stay in your craft.
How do you know when to leave a job?
Make one specific request first, with a date to revisit it. Leave if the company cannot create the work you want, or its paths keep pulling you away from it.
How do you prepare to leave a job and start a company?
Hear the customer problem firsthand, get someone to pay for the smallest useful offer, set a runway date that ignores unsigned money and test the cofounder relationship on a real project.
How do you move into product management?
Most reliably from an adjacent role at your own company. Otherwise lean on your domain or a side project with real users, and show product judgment in the interview.
Which tech jobs will hold up as AI spreads?
Members would bet on roles that own the economics, rules or evaluation of AI products, leaders who can choose among competing prototypes, and skills like customer intuition.
How do you build product analytics skills?
Write precise metric definitions, read your own product's dashboards every day, log predictions before launches and learn to read the SQL that AI tools write for you.
How should you prepare for a performance review?
Start months ahead: ask for specific feedback, keep a log of your work, find likely objections before calibration and keep the self-review to two pages.
How do you get promoted to the next level?
Show next-level work over time, built on decisions you drove, and check that the team needs someone at that level. If it has no room, a growing team may offer a clearer case.
What should you do in your first 90 days in a new role?
Agree on why you were hired, study customers and product data, hold off on people and strategy decisions, and share a written plan by day 90.
What should early employees know about startup equity?
Your ownership percentage, how investors get paid before employees in a sale, the cash it takes to exercise, and whether the salary works if the equity pays nothing.

All career growth questions →

Frequently Asked Questions

PM, designer and product engineer: who owns which decision now

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How do you build product analytics skills?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should you do in your first 90 days in a new role?

What should early employees know about startup equity?

Your ideas, super powered.

PM, designer and product engineer: who owns which decision now

Product Careers

Frequently Asked Questions

How do you decide what role to take next?

Is a bigger title at a smaller company worth it?

When should you switch career tracks?

How do you know when to leave a job?

How do you prepare to leave a job and start a company?

How do you move into product management?

Which tech jobs will hold up as AI spreads?

How do you build product analytics skills?

How should you prepare for a performance review?

How do you get promoted to the next level?

What should you do in your first 90 days in a new role?

What should early employees know about startup equity?

Your ideas, super powered.