Product thinking for engineers

I spent most of my career to date on the business and product side before taking a gap year to learn full stack development. That context shapes how I see engineering. When you already understand what the code is supposed to do, and why, the gap between good engineering and great engineering becomes hard to ignore.

Engineering is often framed as a purely technical discipline. You write clean code, design scalable systems, and ship reliable software. All of that matters. But it's only part of the job.

The most effective engineers I've worked with don't just ask how to build something. They ask why it should exist at all.

They think about users, outcomes, and tradeoffs, not just implementations. This is called product thinking, and it's increasingly essential for engineers who want to build software that matters.

What product thinking means for engineers

Product thinking is the ability to understand a feature or system in context: who it's for, what problem it solves, why it matters now, and how success is measured.

For engineers, this doesn't mean becoming a product manager. It means expanding your scope of responsibility from "build what's specified" to "build the right thing, well."

A product-thinking engineer treats code as a means, not an end. They understand the user journey, not just the ticket. They optimize for outcomes, not correctness alone. And they see tradeoffs clearly, including speed versus quality and flexibility versus simplicity.

Why it matters

Code without context is expensive.

Features that are technically sound but poorly aligned with user needs create hidden costs such as rewrites, feature flags that never get cleaned up, complex systems no one uses, and “temporary” solutions that become permanent.

These costs compound. Understanding why a feature exists helps engineers make better decisions about scope, architecture, and where to invest long-term effort instead of taking pragmatic shortcuts.

Amazon's "working backwards" approach is a clear example of this. Teams write a press release for the customer before any code is written. That forces early clarity on who the user is, what problem is being solved, and what success looks like. Architectural choices, performance tradeoffs, and scope all follow from there. It also pushes you to identify which decisions are hard to reverse before you've already made them.

The best technical decisions are product decisions.

Many of the most important technical decisions aren't about correctness or performance. They're about fit.

Should this be configurable or opinionated? Should we optimize for performance or clarity? Is this abstraction worth it?

These questions depend on who the users are, how often the feature is used, and how quickly the product needs to evolve. Product thinking gives engineers the context to make these calls with confidence.

Notion is a good example. Its core model, where everything is a block, pages can be databases, and databases can relate to each other, isn't just an implementation detail. It's a product decision about how people should think and organize work. The choice to expose relational properties to non-technical users while hiding the query logic, or to let you switch between table, board, and calendar views on the same underlying data, reflects a belief about how much complexity users can handle. Those decisions are baked into the architecture from the start.

Product thinking increases leverage.

Engineers who understand the product spend less time going back and forth with PMs and catch misalignment before it gets locked into the system. That leads to fewer rewrites and better solutions. Over time, this is the difference between task execution and ownership.

How to practice it

Start with the problem, not the solution.

Before writing code, ask: What problem is this solving? For whom? What does "better" actually look like?

Even a five-minute clarification can prevent weeks of misaligned work :)

Understand the user journey.

You don't need to be a UX expert. But you should know where this feature sits in the workflow, what users are trying to accomplish, and what frustrates them today.

Join customer calls when you can. Watch demos or usability tests. Use the product yourself. Proximity to users changes how you build.

Design for tradeoffs, not perfection.

Product thinking often means less engineering, not more. What's the simplest thing that solves the core problem? Which decisions are hard to reverse once shipped? Where can you afford to be wrong?

Shipping something good and learning from it usually beats waiting for something perfect, especially when decisions are reversible.

Treat experiments as first-class work.

Product thinking means finding one high-leverage moment and nailing it, not building ten features at once and hoping one lands.

When Spotify built Discover Weekly, they didn't try to solve music discovery in one shot. They identified a single habit worth owning: every Monday, open Spotify and press play! Engineers shipped one focused playlist powered by a few key signals, watched how people used it, and evolved from there. That restraint was a product decision as much as a technical one.

Product-thinking engineers are comfortable with ambiguity. They ship as a way to learn, tracking features, observing behaviour, and iterating on real usage rather than assumptions.

In AI-heavy systems, this matters even more. Model behaviour is probabilistic, user trust is fragile, and failures can be hard to diagnose after the fact. Product thinking pushes engineers to ask not just "does this work?" but "how does this fail, and how will we notice?"

What changes

Product thinking doesn't replace strong engineering fundamentals. It sharpens them.

Engineers who understand the "why" write simpler code, move faster, design more resilient systems, and avoid the kind of costly mistakes that only surface in production.

The goal isn't to turn engineers into product managers. It's to build engineers who can see the full picture and make better decisions because of it.

The rise of the product engineer

"Product engineer" isn't a widely used title yet, but I believe it's where the industry is heading. It describes engineers who don't just execute tickets but take ownership of outcomes, ask the hard questions before writing code, and move fluidly between technical implementation and product judgment.

As AI handles more of the implementation layer, that judgment becomes the differentiator. Writing code is getting cheaper. Knowing what to build, and why, isn't. The engineers who will matter most won't be defined by how much code they push. They'll be the ones who decide what's worth building at all.