Building a Product-Minded Engineering Team

Whether your engineers care about outcomes or just output shapes what your team ships more than your roadmap, your process, or your tooling. The industry has a name for the ones who care: product-minded. Gergely Orosz popularized the term for developers with real interest in the product itself, the ones who want to understand why decisions get made, how people actually use what they build, and who want a hand in shaping it. Sherif Mansour at Atlassian and Jean-Michel Lemieux, then head of engineering at Shopify, pushed the stronger “product engineer”: a developer who engages with the “why” actively, reaches for technology to leapfrog real human problems, and has the empathy to build something genuinely good to use.

I lead product at CopilotKit. I own the product vision and strategy and translate it into the specs engineers build from. The best engineers I work with push back on a spec when it is solving the wrong problem. That instinct, far more than raw coding skill, is what makes them the best, and it is the thing I most wish every engineering org knew how to grow.

If you lead engineers, growing that instinct across your team is the highest-leverage move available to you right now, and you can coach it. Most orgs treat product sense as something you either hire or you don’t, and they miss that you can build it in the people you already have. What follows is how I would do that from the product side of the table using the thinking I have learned from the best product people I know.

Code got cheap. Judgment is your edge now.

I have written about how execution is collapsing in cost, and about the limits on your switching capacity that show up once it does. I am now able to rapidly prototype new working features, create PRDs, and translate them into Linear projects and tickets with Codex and Claude Code with little to no friction. Even a year ago that was science fiction.

When a model can turn a clear description into working code, throughput stops being scarce, and the moment it stops being scarce it stops being your advantage. What decides whether your org wins now is judgment: knowing what to build and being able to tell whether it worked. Andrew Ng put it plainly in his AI Startup School talk: as software engineering gets faster, the work of getting user feedback and deciding what to build becomes the bottleneck. Lee Robinson, who led product at Vercel and is now at Cursor, argues that in an AI-first world, product engineering is close to the only thing left. PostHog, which structures its whole engineering org around product engineers, claims that in a world where anyone can generate piles of mostly-working code, code is not enough on its own to create an advantage.

A team of fast coders who ship whatever they are handed is becoming a commodity. A team that owns outcomes is a moat. That moat gets built slowly, through how you lead, which is what the rest of this piece is about.

Outcomes over outputs is a leadership choice

If you take one idea from this piece, take this one, because it is the one you control most directly. You get what you celebrate. Celebrate shipping for the sake of shipping and you get what John Cutler named a feature factory, where work is applauded at launch, nobody runs a retro comparing the benefit you expected against the benefit you got, and, in his words, “you have no idea if your work worked.” Melissa Perri calls the same failure the build trap: measuring success by features shipped instead of value created.

Shipping a feature is output. Moving the number that feature was meant to move is outcome. If you want your team to care about the second one, you have to change what “done” means, what earns applause in a demo, and what gets discussed in a retro. Those three things are the daily signal your team reads to work out what you actually reward. Everything below is a way to send that signal on purpose.

Hand out problems, not just features

You want engineers who challenge the spec. You will not get them if every ticket arrives as a fully specified solution with no context attached. Marty Cagan, whose Silicon Valley Product Group writing is the closest thing product has to a canon, argues that strong teams are handed problems to solve, not features to build. He is blunt that most companies waste their engineers. Use them only to write code and you capture maybe half their value, because the best source of innovation is usually the engineers themselves, but only when you share the problem instead of dictating the solution. He splits teams into missionaries and mercenaries: mercenaries build whatever they are told, missionaries believe in the problem enough to fight for the right answer. Your job is to create the conditions, meaning context, safety, and the actual problem, that let the missionaries show up.

In practice that means bringing your engineers the customer problem and the metric, not just the ticket. Make “why are we building this?” an expected question in refinement rather than a threat to the plan. And teach the reframe I reach for constantly, from Jobs to Be Done: rewrite a solution-shaped ticket as a job. “When my payment fails, I want to know why immediately, so I can fix it without contacting support” surfaces the real requirement (clear messaging, self-service recovery) that “add an error toast” was hiding. Some of the best product decisions I have seen started with an engineer doing exactly that in a planning meeting.

Teach your team to see the four risks

Give your team a shared vocabulary for what makes ideas fail. Cagan’s four risks are a great starting point:

• Value: will people actually use or buy it? (Usually the deadliest, and the most often skipped.)
• Usability: can they figure out how to use it?
• Feasibility: can we build it with the time, skills, and technology we have?
• Business viability: does it work for the rest of the business, meaning legal, finance, sales, brand, and support?

Feasibility is where engineers naturally live, and left alone they will answer that one and stop. Your job is to pull them into the other three, and to get their feasibility read into discovery early, while the idea is still cheap to reshape, instead of at the end when it is expensive. Watch for the trap: teams test what is comfortable, usually usability and feasibility, while value goes unexamined, and value is what kills most products.

Get your engineers into discovery

Teresa Torres, whose continuous discovery work I recommend to every leader who will listen, has a line worth putting on the wall: “every idea is a stack of assumptions.” She is also explicit that engineers belong in the room, not just the designer and the PM.

So put them there. One customer interview a month, a support rotation, a habit of watching session replays. It changes how an engineer reads a ticket more than any process you can install. Then normalize cheap assumption tests before expensive builds: a prototype, a fake door, a hard-coded version behind a flag, a single query against production to check whether the usage you are assuming even exists. Engineers can build the cheap test faster than anyone on the team. Make that the default reflex on your team.

Coach where the craft goes

Not every task deserves your team’s best work, and part of your job is helping them tell the difference. Shreyas Doshi’s LNO framework is the tool I hand people: sort work into Leverage (disproportionate impact, bring everything you have), Neutral (necessary, do it well enough and move on), and Overhead (automate, delegate, or delete). Gold-plating (polishing an internal tool like it is a flagship, or handling edge cases no user will ever hit) is a coaching problem. Name it kindly and often.

While you are at it, reward the trait Doshi calls high agency: finding a way to get what you want “without waiting for conditions to be perfect.” The engineer who goes and finds the missing context instead of waiting for a flawless spec is your next tech lead. Point it out, promote it, and model it yourself.

Grow business fluency

This is the one most engineering orgs skip, and it is what separates your senior engineers from your staff-plus pipeline. Cutler only half-jokes that engineers should go meet the CFO. Gibson Biddle offers a faster lens with his DHM model, which asks three questions of any product bet:

• Delight: does this genuinely delight customers, not just satisfy them?
• Hard to copy: does it build an advantage a competitor cannot easily replicate, like a brand, a network effect, or hard-won technology?
• Margin-enhancing: does it improve the economics of the business over time, rather than just buying short-term growth?

A strong bet answers yes to all three; a weak one usually delights customers in a way anyone can copy. Biddle credits that lens for Netflix pulling its monthly cancel rate from 10% down to 2%.

This is worth your investment because engineers are often the only people in the building who can see the hard-to-copy technical advantages: the latency win, the data moat, the piece of infrastructure a competitor would need two years to match. An engineer who also understands how the company makes money connects those two things and makes sharper calls than anyone. Share the revenue and margin context you are tempted to keep at the leadership level. It pays for itself.

Make measurement non-negotiable

Your team cannot care about outcomes it never sees, so instrumentation has to be part of the definition of done: a feature ships with the events to tell you whether it worked, or it does not ship.

For deciding what to build, the common tool is RICE, created by Sean McBride at Intercom:

Reach times Impact times Confidence, divided by Effort.

Your engineers own the Effort term and heavily shape Confidence, so pull them into the scoring rather than handing them the output. Anchor Impact to a single North Star metric that captures real value. From there, coach the team on which metric to chase: Julie Zhuo’s rule is to favor retention over raw volume, because sign-up and usage counts can be inflated with top-of-funnel tactics, while people coming back is hard to fake.

Build the reps for product sense

Product sense is a prediction skill. Lenny Rachitsky defines it as generally being right about which product changes will have the intended impact, and like any prediction skill, it sharpens with reps and feedback. As a leader, you create those reps. Ask engineers to write down what they expect a change to do before it ships, then revisit it together. Run product sparring sessions where the team critiques product decisions the way they already critique code. Get them in front of users. None of this is expensive. It just has to be a habit you protect.

What this looks like in practice

Principles are easy to agree with and hard to install. Turning these into how your team actually works comes down to a few concrete moves.

Redefine “done.” Add to your definition of done the intended outcome, the metric it should move, and the instrumentation to measure it. This single change drags most of the other behaviors along with it.

Put the questions into your rituals. In refinement and design review, the team answers: what problem does this solve and for whom, what should change if it works, what is the riskiest assumption and can we test it cheaply first, and is there a simpler version that captures 80% of the value. Before shipping: analytics verified, scope did not drift, and a quick pre-mortem (if this fails in production, why?). After shipping, the step almost every team skips: did the number move, if not why not, and what did we learn. Make the after-ship review a standing agenda item.

Change what you reward. Demos report metric movement and learnings, not just shipped scope. Retros ask whether the last thing actually worked. What you applaud in those rooms is what your team optimizes for the rest of the week.

Calibrate by seniority. Juniors ask why and check the metric after shipping. Mid-level engineers own the four-risk framing and propose scope cuts. Seniors and tech leads join discovery, run pre-mortems, and mentor the rest.

Be honest about the timeline. Cutler’s own estimate is that moving a team from feature factory to genuinely outcome-oriented takes 12 to 18 months of steady coaching. It moves at the speed of culture change. Expect it to feel slow, and protect it anyway.

You will know it is working when every ticket names an outcome and a metric, features ship instrumented, demos discuss movement, engineers propose scope cuts on their own, and post-launch reviews happen without you asking. You will know you are still stuck when demos are pure feature theater, “done” still means merged, and nobody on the team can tell you the metric a given feature was supposed to move.

The payoff

The goal of all of this is a team you can hand a problem instead of a spec, and trust to come back with something better than what you would have written. That is the difference between an organization that scales its judgment and one that only scales its output. In a world where output is racing toward free, that judgment is close to the whole game.

If you have grown this on a team, I would like to hear what actually moved the needle for you, and what turned out to be a waste of time. It is a hard problem, and most of what I have learned about it came from comparing notes with other people trying to do the same thing.