Meta now expects engineers to own product decisions. WTF does that really mean?
Meta's IC/EM leveling guidelines now include "drive product decisions, design reviews, and data analysis," and it's not just Meta. So... are Engineers PM's now?
The “product engineer” concept that used to be a startup quirk, is now becoming the default expectation. At PostHog and Linear, there are no traditional product managers, instead engineers own the roadmap, talk to users, and make product calls. Meta’s IC7 expectations now include “expand beyond code into product thinking, data literacy, and cross-functional leadership,” and variations of this exist at all levels from IC3 to Managers and beyond.
But why?
Because AI made writing code cheaper. When code is cheap, companies need fewer engineers, AND need the ones they keep to justify their cost in more ways. And this goes both ways - PMs are getting asked to ship code, build prototypes, or absorb marketing scope.
Andy Jassy was pretty direct when he told Amazon employees the company will need “fewer people doing some of the jobs that are being done today” and urged them to figure out how to “get more done with scrappier teams.”
So all engineers become PMs?
No. God, no. But everyone's scope will have to increase in some direction. Companies want more from you, and “product sense” is only one version of that more.
Meta is building teams with a 50:1 engineer-to-manager ratio, so some of those engineers will absorb what a manager used to do. Others will expand into data science, ML, production support. “Product engineer” is just one archetype, and it’s the one we’re talking about today.
What the f’k is product sense for engineers?
Someone hands you a ticket: “Add export to CSV.” An engineer without product sense builds the export, but an engineer with product sense asks: who’s exporting, what are they doing with the data, and is CSV actually what they need or are they copying it into a Google Sheet because we don’t have a dashboard?
That’s it. That’s the whole skill in miniature. In practice, someone with strong product sense can:
Take a vague goal (“improve engagement”)
Break it into meaningful user problems
Propose solutions
Anticipate risks
Choose a direction with clear reasoning
Are “product decisions” really that big of a deal?
The most common rookie mistake I see from both engineers and new PMs is that they assume they are the customer, and their wishlist is a product roadmap.
I’ve led multiple consumer-facing teams at Meta and Amazon, running experiments for millions of users, and I can tell you that new PMs often stumble in like toddlers at a construction site. MBA degree in the back pocket, hard hat on backwards, pointing at load-bearing walls going “have we thought about removing that?”
Sometimes they haven’t had their first 1:1 yet, and have insights about a product that a billion people use. Some very smart people spent years getting that product to a billion+ users, they were not sitting around waiting for your shower thought. Everyone gets humbled by their first A/B test… turns out a billion users don't care about your insightful thesis.
The 3 things VS Code can’t help you with
So why don't more engineers just… do this? Because product decisions come with three things that your IDE can't help you with.
Accountability with incomplete information. In engineering, the solution is provably correct or incorrect. In product, you’re choosing between options that all look reasonable, the data supports multiple directions, and the real answer only shows up six months later in retention. You still have to make the call now.
Constraints you can’t engineer around. Legal says no, design says it breaks the system language, but the VP wants it because a board member mentioned it. Product sense is a more than knowing what to build - it’s knowing what to build given everything you can’t control.
Politics. In any org of meaningful size, product decisions are negotiations. That other team whose metrics your feature will hurt? They have a VP too. Navigating that without caving or bulldozing is a skill, and most engineers haven’t had to develop it because someone else was doing it for them. That someone is increasingly not there.
How to build product sense? (no, you don’t need a course)
You don't need to become a PM, and you probably don't need a product strategy course either. But you do need a new habit. Experienced engineers and good managers tend do some of this instinctively, but if you’re not there yet…
Start here
Before you write code, answer three questions: What user pain does this reduce? How will we know it worked? What are we choosing not to do by doing this? If you can’t answer them, ask. The fact that you asked already puts you ahead of most engineers in the room.
In design reviews, argue from user outcomes. “This is a cleaner architecture” is an engineering argument. “This cuts the most common user flow from five steps to two” is a product argument.
After you ship, pull up the dashboard yourself. Don’t wait for the PM to present results in a review. The gap between “I built it” and “I built it and here’s what happened” is where product sense actually develops.
Build the muscle
Every annoying product behavior you encounter is a tradeoff someone made deliberately - start asking why. Read post-mortems for killed features, talk to real users instead of the one in your head, sit in reviews even when your code isn't on the table. The engineers who will develop product sense fastest would be the ones paying attention more broadly.
Learn faster, you have AI.
And yes - use AI to do all of this faster. Draft the one-pager in ten minutes with Claude or ChatGPT. Have it pull patterns from user feedback you’d never read manually. Ask it to stress-test your assumptions before you pitch them in a review. You’re already using AI to write code, use it to compress the learning loop.
Finally, if your manager told you to 'show more product sense' in your last perf review and you nodded while having no idea what that means differently from 'be more strategic' - I wrote a separate breakdown of how product sense differs from execution skill, strategy, technical depth, and leadership judgment - that’s here.