Think product first: the questions I ask before writing code

A product engineer is a software engineer who cares about the outcome, not just the output. You still write the code, but you also make sure it is the right code.

Over the years, as a consultant building products from scratch and now as a product engineer at a scale-up, I've collected a short list of questions I ask before writing a single line of code.

Who is this for, exactly?

"Users" is not an answer. Is it a first-time user, a power user, an admin, a support agent helping a customer? Each one needs something different. Naming a specific person changes the design immediately.

What problem are they trying to solve?

Users describe solutions ("add a button that…"). Our job is to find the problem underneath. Ask "why?" until you hit something real: they are losing time, they are confused, they are afraid of making a mistake.

How will we know it worked?

Define success before you build. Fewer support requests? Faster task completion? Higher retention? If you can't measure it, at least decide how you'll observe it, even if that is just asking five customers.

What is the smallest thing we can ship to learn?

Most features can start much smaller than the first proposal. Ship the core, watch how it's used, then decide what to add. Products grow best in small, informed steps.

What does it cost to maintain?

Every feature has a running cost: code to maintain, tests to update, edge cases to support, documentation, translation. A feature that saves users a little time but costs the team every sprint may not be worth it.

What happens when it fails?

Network down, device offline, invalid data, a user doing things in the "wrong" order. Product thinking includes the unhappy paths, because that is where users decide whether they trust your product.

Why engineers should ask these questions

Because engineers see things nobody else sees: the technical shortcut that makes a feature ten times cheaper, the edge case that will flood support, the reuse opportunity that saves a month. When engineers only implement tickets, that knowledge is wasted.

Product-first doesn't mean engineers become product managers. It means the whole team shares one goal: building something people actually want to use.

A simple habit to start with

Next time you pick up a ticket, write one sentence at the top before you start: "This helps [who] to [do what] so that [outcome]." If you can't write it, go ask. It is the cheapest bug fix you will ever make.