Product-minded engineers

A product-minded engineer treats the product as part of their craft. You do not need to become a PM. You need enough literacy to push back on bad bets, amplify good ones and avoid building elaborate solutions to imaginary problems.

Gergely Orosz describes people who understand the user and business context of their area, ask questions that reshape the solution, cut scope to preserve the outcome when time is short, instrument what they ship and partner with PM and design instead of waiting for a perfect ticket.

The big idea

Before you estimate or open a branch, force a short answer to three questions:

1. What problem does this solve? Prefer a user or business problem ("ops spends 40 minutes reconciling invoices by hand") over a solution ("add CSV export"). If the ticket is only a solution, ask for the problem — or go find it in problems worth solving.
2. For whom? "Users" is not an answer. Which persona, segment or job? A feature that delights power users and confuses new users can hurt activation.
3. How will we know? What metric, qualitative signal or experiment result would change if this works? If nobody can name one, you are shipping output for its own sake.

Write these three lines in the PR description or design doc. It takes two minutes and surfaces misalignment early — the PM thought this was for enterprise admins; design thought it was for end users; you built for neither.

Walking through it

Ticket: "Add dark mode."

Weak answers: problem = "users asked for it"; whom = "everyone"; know = "ship it."

Stronger: problem = "night-shift support agents report eye strain and switch to competitors' tools after 10pm"; whom = "support agents on night shifts (~8% of MAU but 30% of tickets)"; know = "increase in dark-mode preference set among that cohort, and no drop in task completion time in usability tests."

You might still ship dark mode for brand reasons — but now you know whether it is a value bet or a viability/brand bet.

Early Facebook growth engineers obsessing over activation loops, Stripe engineers treating documentation and API design as product surfaces, teams that kill their own feature after data shows no lift: the pattern is ownership of impact, not just of code. That literacy compounds. Seniors who can say "this solves a real job for a segment that will pay" get trusted with ambiguity.

At work this week: pick one ticket in flight and write the three questions in a comment. If the answers are vague, ask the PM or designer for ten minutes — not to block, but to align. Start with curiosity ("help me understand the problem so I scope the right thing") rather than opposition ("this is pointless"). Bring evidence: a support theme, a funnel drop, a quote from a call.

Common mistakes

• Waiting for a perfect ticket. Product-minded work is asking the three questions, not refusing to start.
• Cutting the outcome instead of the scope. When time is short, preserve the user result and drop polish, not the other way around.
• Shipping uninstrumented. "We'll look later" usually means never.

Check yourself

1. A ticket says "add CSV export." What are stronger answers to the three questions than "users want export"?

Problem: ops spends 40 minutes reconciling by hand. Whom: finance ops at mid-market accounts. Know: time-to-reconcile drops, or they stop using the spreadsheet workaround.

2. Time is short and dark mode is half-done. What does a product-minded cut look like?

Ship the preference for the night-shift cohort and measure task time; drop extra themes and marketing splash until the outcome is real.

Key takeaways

• Product-minded engineers reshape solutions, cut scope to keep outcomes and watch metrics after ship.
• On every ticket: what problem, for whom, how will we know?
• Evidence (support, funnels, quotes) beats opinion tournaments.

Further learning

Gergely Orosz on what product-minded engineers actually do day to day, with concrete behavioral tells.

The Product-Minded Software Engineer (Pragmatic Engineer)Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. The…The Pragmatic Engineer

Back to the map: product thinking.