The Product Engineer
What separates a Product Engineer from a developer who waits for instructions: the three questions, senior thinking, and why flexibility is an architecture decision.
The previous post ended with a lesson from DoubtNut: a technically elegant solution failed because it was designed without knowing the user. That kind of failure is avoidable. The engineers who avoid it most consistently have developed specific habits around three questions.
The Product Engineer: A New Kind of Role
Silicon Valley has a term for the kind of engineer who naturally thinks in these terms: Product Engineer.
A product engineer can code. But they also understand users, business context, and the three central questions of product development:
- What to build: which problem is worth solving
- How to build it: the technical approach that fits the constraints
- When to build it: sequencing decisions so the most critical thing ships first
ExpandThe three questions that define how a product engineer thinks: what, how, and when to build
These roles are among the highest-paid in the industry. They eliminate the gap between product thinking and engineering execution.
A product engineer does not wait to be told what to build. They come with a problem and two possible solutions, already sized for effort.
For engineers who want to go deeper on the systems side of these decisions, high-level system design covers how to reason about architecture at scale.
What Makes a Senior Engineer Different
Technical expertise is the entry ticket. It gets you into the room. But it does not determine how fast you grow once you are there.
Research from Microsoft's developer efficiency team found that the qualities distinguishing senior engineers from good engineers are not primarily technical. They fall into four areas:
Problem Solving splits into two parts: analytical thinking (which problem actually matters, and with what data) and creative problem solving (what solutions exist within the constraints). The DoubtNut case is exactly this -- the team solved the wrong problem because they skipped the first part.
Attention to Detail goes beyond the code. In code, it means catching edge cases before they hit production. In product, it means understanding how users behave at the edges -- not just the happy path.
The CrowdStrike/Windows outage in 2024 started as a missed edge case in a software update. It ended with cancelled flights, grounded hospitals, and visa offices offline.
Adaptability is the willingness to test assumptions rather than defend them. The Firebase SDK seemed like the right solution until production data said otherwise. The team that can roll back, read the signal, and try again fast is more valuable than the team that defends its original decision.
Communication determines whether good technical insight ever reaches the people who can act on it.
"I believe we should solve A before B, and here is why, and here is my proposed solution" -- a developer who can say that is more valuable than one who waits to be told what to build.
A/B Testing: Code That Learns
One of the most important practical concepts in product development is A/B testing: showing different variants of a feature to different user groups and measuring which one performs better.
Swiggy does not show every user the same restaurant ordering. It shows James one ordering and shows Neal a different one, and measures which ordering leads to more purchases. Under the hood, these systems use prediction models that learn which patterns in past order data correlate with a purchase.
This has a direct implication for how code should be written.
If you build a feature as a static, single-path implementation, introducing a variant for testing requires rebuilding it. If you build for experimentation from the start -- feature flags, configuration-driven behaviour, modular A/B surfaces -- adding variants is a config change, not a rewrite.
Internationalization (i18n) is the same pattern. Google Pay shows English and Hindi side by side when a user enters an incorrect PIN. That UI does not appear outside India.
If the team had not built the language layer into the architecture from the beginning, supporting a second locale would require a new Android release. Users who do not update would be stuck with the wrong behaviour indefinitely.
The product engineering principle: when you build a feature, ask whether it will need to be localised, personalised, or A/B tested in the next year. If yes, that changes the architecture you should choose today.
The next post looks at why product management exists as a formal function: how companies like Google and early-stage startups structure product decisions differently, and what that means for the engineer who wants to grow into a leadership role.
The Essentials
- The Product Engineer role: Engineers who combine coding ability with product judgment are among the highest-paid in the industry. They answer what, how, and when to build, and they come with options already sized for effort.
- Build for flexibility from day one: Features that will be A/B tested, localized, or personalized need the right architecture from the start. A config change is not a rewrite.
- Technical expertise is necessary but not sufficient: It gets you in the door. Problem solving, communication, attention to detail, and adaptability determine how fast you grow once you are there.
Further Reading and Watching
Keep reading