How Product Engineering Shortens the Learning Loop

Most product organizations split the path from customer problem to solution across several roles. A customer talks to sales or support. Their request reaches a product manager, who turns it into requirements. A designer creates a solution, an engineer implements it, and someone else brings it back to the customer.

That makes sense if you think of engineering as a feature factory. At the same time, they create many dependencies, long waiting time and distributed context. The engineer receives a description of the problem instead of experiencing it. When new information appears during implementation, it has to travel back through the same chain.

At Kombo, product engineering is our attempt to shorten this loop:

Customer → product engineer → customer

The engineer who understands the problem stays responsible until the solution works for the customer.

How We Started Working This Way

When we hired our first engineers, we started working the way many product organizations do. We created tickets, made mockups in Figma, and tried to write down all the context they needed.

We were not happy with the results. Engineers were implementing what we had described, but they were not solving problems the way we wanted them to. The process was slow, and eventually one of my co-founders spent half his week managing our ticket backlog.

So we went back to how we had worked before. We talked to customers, discussed what we learned, and built what they needed. Instead of trying to transfer all the context through tickets, we brought engineers into the customer conversations.

Seeing a customer experience a problem gives you a different sense of responsibility for it. There may be many ways to solve the problem technically, but hearing it firsthand makes what the customer actually needs much clearer. It is the same lesson behind YC’s advice to talk to your users.

The Loop Ends With Adoption

A product engineer starts an initiative by talking to customers. Depending on their seniority, a product manager and/or senior engineer supports them. Together, they try to understand the underlying problem, not just the requested feature.

The engineer then writes an RFC. The team challenges the assumptions, adds missing context, and reviews the approach. Once the direction is clear, the engineer designs the solution, implements it, deploys it, and helps the first customers adopt it.

We are done once the feature is used by customers, not when it’s merged to production.

One Owner, Many Collaborators

End-to-end ownership does not mean working alone.

Product managers bring context from other customers, connect an initiative to the longer-term product direction, and help engineers approach discovery. Senior engineers help with difficult technical decisions and make sure a local solution fits the wider system. Other engineers share knowledge and challenge the RFC before expensive decisions are made.

The product engineer remains responsible for moving the problem forward (whatever it takes, pair program with other engineers, talk to customers, call a meeting).

Changes for Product Managers

As AI makes implementation faster, some companies expect to need more product managers per engineer. That may increase output, but it can also turn product managers into specification factories.

What if engineers do most of the product work in their initiatives? Product managers can then focus on the work that benefits from a wider view: finding patterns across customers, deciding which problems matter most, shaping longer-term direction, and helping engineers become better at product discovery.

Designing for Short Cycles

This model only works when the surrounding system system supports it. Our customers are engineering and product teams. We use TypeScript across the frontend and backend, work in a monorepo, and use trunk-based development. An engineer can change a feature across the stack and deploy it end-to-end without waiting for another team or release cycle.

We make company context accessible by default. Design documents, RFCs, meeting recordings, and transcripts are available to everyone. RFCs bring relevant knowledge to an initiative before implementation begins.

Autonomy Needs Support

Engineers do not receive specced tickets, but that does not mean they work without support. Depending on their seniority, a product manager and/or senior engineer helps them build the context and judgment they need.

Teams prioritize their own initiatives and decide how they work. Within them, engineers take on larger ownership as they gain experience. Asking for help is part of ownership. I don’t want a senior people to stay close to the work of junior people, just to make sure they can engage when junior people are about to make a mistake. I want everyone at Kombo to develop the right judgment to decide whenever to pull someone else in.