What is a Product Engineer?
In the last few years, I’ve increasingly heard the term “Product Engineer” in the context of software development. This role isn’t new - it’s just that our understanding of the intersection between product development and software engineering has improved. In reality, we’ve always been product engineers; we’re just making it more explicit now.
How is this different from regular software engineering?
It isn’t.
This is what software engineering should have always been about. And as you become more senior, the expectation to think beyond just writing code increases. Staff+ engineers focus on solving high-value problems - problems that:
Directly impact customer experience or revenue.
Expand market reach.
Improve internal efficiency, so the team delivers more value, faster, with fewer misfires.
A Product Engineer is still a technical role. You still write code, design systems, and architect solutions. Adding “Product” to the title is simply a reminder of why you’re building software: to deliver the most value to users and the business. Product Engineers bring engineering expertise into the entire product development lifecycle, ensuring technical feasibility aligns with business needs.
How?
Talk to real customers. Product Engineers engage directly with end users, gathering feedback to iterate quickly and build solutions that truly matter.
Design Thinking
So far I’ve mentioned three players: customer, product (team), engineering (team).
To illustrate how Product Engineers fit into this equation, let’s look at Design Thinking, a framework that connects these three perspectives.
In Design Thinking, there are three aspects and each relates to one of the three parties that I described above:
- Desirability - this is where the Customer Focus comes in. Find a solution to a real problem that your target market needs to be solved and is prepared to pay to have solved. The solution needs to be desirable by the customer because it solves an actual problem, or creates new opportunities for them.
- Feasibility - this is where Technology Focus starts to come in. The solution to the problem needs to have a realistic way of being solved with technology. It is no good if a solution is beyond your ability to produce or acquire it.
- Viability - once you have found one or more feasible solutions to the problem then they need to be evaluated for profitibility. This is about being in business. It is no good if a solution is technically possible but beyond the means or desire of your customer to pay for you to produce that solution, whilst leaving you a decent profit margin. You are in business after all.
The product team, engineering team, and business stakeholders all contribute to Design Thinking from different perspectives, but the end goal is the same: building a valuable, usable, and sustainable product.
The key takeaway
It’s ALL product. You are in the business of developing a product to meet customer needs. Pretty much everyone in a company is.
Like many engineering processes, it is iterative.
Product Lifecycle
Are you scaling a core business, expanding into new markets, or investing in disruptive innovation?
It matters. Understanding where you are in the product lifecycle influences your priorities and risk tolerance. The Three Horizons Framework helps businesses balance short-term execution with long-term growth while managing risk.
Horizon 1: Core Business & Scaling - This is the stable, revenue-generating foundation of a company, where processes, compliance, and governance ensure efficiency, minimise risk, and defend market position. Heavy on operational excellence, regulatory adherence, and incremental improvements.
Horizon 2: Emerging Opportunities - A bridge between stability and innovation, where startups push for scale and established companies take calculated risks on emerging products and markets. Governance must be flexible enough to support experimentation but disciplined enough to maintain credibility and compliance.
Horizon 3: Disruptive Innovation - Focused on new ideas, unproven markets, and moonshot projects where traditional governance and compliance would be wasteful or even counterproductive. Most ideas will be discarded, and speed matters more than structure - businesses that impose H1-style controls too early kill innovation before it starts.
Hypothesis-driven development
In Horizon 3, most ideas will be discarded because, as much as we hate to admit it, we are wrong more often than not when it comes to assumptions about what works for customers.
Hypothesis-driven development (HDD) is a process where teams are more rigorous and explicit about their hypotheses. They then run experiments to validate their hypotheses. It is heavily influenced by scientific methods, Lean Startup principles, and Continuous Delivery.
It is not all that different from the scientific method that most learn at school:
- Define a hypothesis - formulate a clear, falsifiable, hypothesis based on user needs (Desirability), business goals (Viability) or technical assumptions (Feasibility).
- Define an experiment - develop a minimal test (e.g. A/B test, prototype), probably using feature flags to validate the hypothesis.
- Measure - run the experiment and collect data from real users and environments using metrics and/or feedback.
- Learn and Iterate - If the hypothesis is validated, scale the solution; if invalidated, pivot, refine or discard.
Wrapping up: It’s about solving real problems
If you’ve heard companies talk about “customer obsession,” this is what they mean. The focus isn’t just on empathy - it’s about solving real problems so customers are willing to pay for the solution.
At the end of the day, Product Engineering is about bridging technology and business. It’s about identifying problems, developing solutions, and making sure those solutions are worth building - both for users and for the company.
P.S. If you’re a platform engineer, your customers are right inside your company. Internal Developer Platforms as a product? It’s a thing. 😉