What is a Product Engineer?
A product engineer is someone with foundational knowledge across the core activities of product development: discovery, design, implementation, and impact measurement. They can take a product problem and tackle it end to end, understanding what’s important to build, working on the user experience, implementing it technically, and measuring impact.
This doesn’t mean product engineers do all these activities every day or at all times. It’s contextual and depends on the company’s needs. Like a jazz ensemble where each musician has a primary instrument but can play others, product engineers have foundational knowledge across all domains. Everyone has an area they’re strongest in, but they can contribute across all activities when needed.
Why This Matters
Here’s the problem we keep seeing: when you have three specialized roles (PM, designer, and developer), it’s almost inevitable that people start working in parallel on different things that may not be related to each other.
The PM talks with customers. The designer works on designs. The developer does implementation.
Even with tight feedback loops, when these three activities happen in series, translation gets lost. There are hand offs. Delays. Things that fall through cracks.
You could try making specialists work together in the same room on the same problem simultaneously. But in practice, specialists require more coordination. They’re optimizing for their individual job descriptions. And organizationally, this kind of tight ensemble working is rarely accepted as standard practice.
The Ensemble Model
The natural question becomes: how do product engineers work together as a team?
The answer draws from ensemble programming practices that already exist in software development. But instead of applying it just to code, we’re extending it across the entire product development process: discovery, design, implementation, and impactmeasurement.
Each team member is still a product engineer with foundational knowledge across all domains, but each brings their own deeper specialty:
- UX-oriented product engineers
- Engineering-oriented product engineers
- Discovery-oriented product engineers
Working in ensemble, they collaborate on all activities, contributing their expertise where it’s strongest while maintaining the ability to work across all domains. It’s co-architecting the product, not just co-writing code.
How Knowledge Develops
Product engineers develop their capabilities through exposure and practice. Most real knowledge in our industry comes from working on actual problems in the field. This creates a repertoire of experiences to draw from.
At startups, when a founder gives them a feature to develop, it’s their responsibility to challenge it. “Why is this important?” They take it from there, coming up with design solutions and technical solutions together. They prototype, implement, measure, and iterate. With AI tools, this is even faster now, though foundational knowledge remains essential.
At bigger companies, someone in the team takes responsibility for discovery if necessary. Once the problem is defined, the team starts prototyping together. People with diverse skillsets bring their knowledge. One person becomes the “initiative lead,” coordinating with stakeholders and other teams, making sure initiative goals don’t go astray.
Discovery and good design are skills that can be taught and practiced, even in pairs. The key is having people who’ve practiced them enough to know what good looks like.
The Resilience Advantage
Here’s what makes this model different: an ensemble of specialized roles is fragile. It has multiple points of failure.
- Designer leaves? Design work stops.
- PM on parental leave? Discovery stops.
- Engineer sick? Implementation stops.
A team of product engineers with overlapping foundational skills is more resilient:
- Anyone can pick up most tasks
- Momentum is not disrupted
- Knowledge doesn’t live in single heads
- The team can self-organize around whoever is available
Working in an ensemble also means multiple perspectives from different people. That reduces the risk of individual bias. The UX-oriented product engineer catches design problems. The engineering-oriented product engineer sees technical constraints. They’re all in the conversation from the start. No hand offs. No translation loss.
The “Good Enough” Question
How do product engineers know when their work is good enough versus when they need deeper expertise?
This is where tight feedback loops matter. “Good enough” is a mix of gut feeling and best practices, validated by observing what users do and how customers react. The trick is keeping increments small so the time lag between shipping and learning stays minimal.
More importantly, it’s a team effort. Who cares about individual attribution? In a team ensemble, there are always multiple perspectives. Someone with more experience in one domain can review the work. The team succeeds or fails together.
And in an ensemble, people with diverse skillsets naturally complement each other. The design expert, the tech expert, the discovery expert, they all bring their knowledge to prototyping and implementation.
How This Scales
At startups (10-50 people), a single product engineer might handle everything. At bigger companies, you’d have 3-4 product engineers with different specializations working in ensemble on independent product problems.
The organizational structure at 200 or 500 people is still being explored. But the hypothesis is that small, autonomous teams working on independent product problems remain effective. Each team is an ensemble of product engineers with complementary depths.
Some product engineers will naturally specialize more deeply as teams grow. A “UX-oriented product engineer” at a 200-person company might spend most of their time on design work. But they still have the foundational knowledge to jump into discovery or technical conversations when needed. They’re not siloed the way a pure specialist would be.
The Core Trade-Off
This model optimizes for resilience and velocity over peak quality in any single domain.
For many products (especially early-stage, high-uncertainty work), this is the right trade-off. The cost of coordination overhead and translation loss between specialists outweighs the benefit of specialized excellence.
The current problem is that everyone works in silos. They might create amazing solutions in their own domains, but on a system level those solutions aren’t as useful as they should be. They’re over-engineered or over-designed because the system view was missing.
Product engineers maintain that system view. They prevent siloed optimization that creates poor overall outcomes.