Product Engineers (probably) aren't the cure

22 Dec 2024

What if every engineer could own the roadmap, talk to customers, and ship features as fast as they did on the day you first launched your product? That’s the pitch for the Product Engineer. A software engineer who wears a product hat, owning the roadmap, talking to customers, and writing the code to bring their vision to life. It sounds like an incredible opportunity for software engineers who have a passion for building great products, not just writing great code.

In the ideal version of the story, the builders (engineers) are freed to do their best work by eliminating the bureaucracy that traditional product management and design bring. If you unleash the builders, they will build the best version of your product by using their own product sense and their technical skills to iterate and ship faster than any traditional product team could ever hope to achieve. The heroic narrative goes beyond the 10x engineer to the lone wolf engineer who not only writes the best code faster than anyone else, but has the vision to deliver the greatest product ever seen.

This is an appealing story for engineers and engineering leaders, many of whom have encountered frustrating red tape and bad ideas from product management and design who do not produce anything but PRDs, impossible to implement mocks, and never-ending meetings and process without ever figuring out how to ship value to customers.

“Let builders build” and get out of the way is hard to maintain when product engineers in the let builders build model meet reality.

The reality

First, get rid of product management (or never hire PMs to begin with) and tell engineers they are product engineers now. They choose what to build, how to build it, and they are now responsible for the success of their product. Also, they should keep writing the code too, because their core responsibility is to ship value personally. Projects that engineers had not been able to get approved suddenly start moving. Barriers break down and work starts hitting production. Bugs that annoyed engineers but never made it up the priority queue are smashed. There are early wins that feel energizing.

This initial burst of positive movement is a mirage.

After the honeymoon

After the initial burst, things slow down.

Newly minted product engineers learn that figuring out what to build and why is more complicated than they imagined and takes more time than expected.

Talking to customers is hard: Finding the right customers, scheduling calls, and conducting meaningful interviews takes time and energy, even for those already comfortable with the work.

Design is hard: Things don’t look quite as polished as expected and the user experience feels off. Pinpointing why takes time and energy, and often leads to cut corners and rough edges.

Managing internal stakeholders is hard: Customer support needs bugs fixed, sales needs 5 new features to meet their quota for this quarter. Success has a QBR that won’t go well if you can’t ship the feature you promised the client last quarter. Every executive has a pet project that needs to ship tomorrow.

Managing all of the above, and still writing code is hard, at best.

Doing all of that, writing code, and communicating what you are building to the other product engineers so the product maintains a coherent direction is not happening for any team that has grown beyond a few people in a room.

When it can work

The product engineer model is so appealing to many engineers and technical founders because it transports them back to the beginnings of a startup, when the founders could sit in one room, come up with a hypothesis, talk to customers, and ship the solution in hours. There was no process, there were no guardrails or meetings, there was just forward progress.

If you don’t have product market fit yet and you are rapidly iterating and need to prioritize speed over all else then the product engineer model is great. Talk to customers, ship, evaluate, and iterate all on your own.

Don’t create process, don’t slow down. There’s nothing else to do yet, so let the builders build.

The takeaway

The reality of product engineers is a lot like the reality of a poorly run product management organization. What gets built is determined by whoever has the most influence in the room, the voice of the customer is not well represented, product innovation stalls, and the product is less than the sum of its parts.

While the product engineering model works fine for very small startups — at that stage the founder should be running product anyway — as the organization grows it will struggle to deliver results.

If your organization is struggling with process overload, shipping slowly, empire building or other symptoms of a dysfunctional product organization, it is unlikely that you are still in the stage of growth where product engineers are the correct solution.

Instead, try:

• Eliminate unnecessary process: Regularly audit team workflows to identify and remove needless approvals, status meetings, and checklists that don’t serve customers.
• Connect engineers with customers: Engineers should regularly join customer calls. There is no reason to keep them disconnected from customers, but the conversations should be facilitated by product people so that engineers can learn and build empathy without losing focus on their core role.
• Revisit organizational priorities: Your product roadmap should be outcome focused and aligned towards delivering value to customers. If it isn’t, whichever executive owns the roadmap must solve this and align the entire product organization towards shipping value to customers in a way that moves the product towards the company’s long term vision.

There are no magic bullets in product development. A new structure won’t solve systemic issues, and letting builders build, while attractive in theory, is unlikely to survive contact with reality. Building great products requires more than just great builders. It demands a balanced, collaborative organization where every role is optimized to deliver customer value efficiently and effectively. This can include a “product engineer” role, but as companies that have tried the “no product managers, ever” approach usually find out, a thoughtful balance of roles and responsibilities is the inevitable path if you want to maintain a great product as you scale.

The path forward lies in crafting a high-functioning product organization that connects every member of the product organization to customers, streamlines processes, and empowers every team member to do their best work.