Product thinking for engineers

Most of an engineer's week is output: tickets closed, PRs merged, services deployed. Product thinking is the habit of asking whether that output creates outcomes — users succeeding, the business growing, a risk retiring. You do not need a PM title. You need a mental model of what good product work is, who owns which risks and how to interrogate every ticket with three questions: what problem, for whom, and how will we know?

Teams that optimize for shipping velocity while ignoring whether anyone uses what they shipped end up in the build trap: busy roadmaps, rising headcount and flat results. The pages below unpack that trap, the four risks every bet carries and how engineers practice the craft without becoming project managers.

Concepts in this section

Read them in order. Each one builds on the one before.

Step	Concept	What it answers
1	Outcomes vs output	Are we measuring shipping, or change in user and business behavior?
2	Four product risks	Will they use it, can they use it, can we build it, does the business work?
3	The product trio	Who owns discovery vs delivery, and what product management is not?
4	Product-minded engineers	What do I ask on every ticket, and how do I cut scope without cutting the outcome?

Discovery continues in problems worth solving, jobs to be done, user research and continuous discovery. Strategy, metrics, growth and shipping sit in the later groups. Startups covers whether the business around the product works. AI product strategy covers what is worth building with models.

Expect friction. Some orgs punish questioning the backlog. Start with curiosity and bring evidence: a support theme, a funnel drop, a quote from a call. In interviews, product thinking shows up as clarifying the user and success metric before jumping to architecture — see product sense interviews.

Common mistakes

Dual ownership with no discovery. PM writes tickets, engineering estimates, design polishes — and nobody talks to a user. The trio owns learning, not a handoff chain.
Treating delivery speed as the product metric. Velocity belongs on an engineering ops dashboard. Customer-value metrics belong on the product scoreboard.
Engineers who only speak feasibility. You become an order-taker. Push on value and viability with evidence, not taste wars.

Key takeaways

Product work is outcomes over output; the build trap is optimizing for shipping while nothing improves.
Cagan's four risks — value, usability, feasibility, viability — are the checklist for every bet.
The trio shares discovery; delivery alone is not enough.
On every ticket ask: what problem, for whom, how will we know?