We have a team of around 30 people across product, design and engineering. Like many teams, we follow a fairly standard process: the product manager defines the problem, the designer creates the experience, the tech lead plans the approach, frontend and backend engineers build it, and QA tests it before UAT and release.
Our process is lighter than what you would find at a large company, but a project still passes through several people before reaching a customer.
That structure brings predictability and helps maintain quality. It also comes with a cost.
Every handoff takes time. Context gets lost. People interpret requirements differently. Small decisions wait for the next meeting. By the time something ships, it can look quite different from what we originally intended.
I’ve been wondering: in a world where LLMs help one person do much more, is this still the best way to operate?
The boundaries between roles are becoming easier to cross. An engineer can create a reasonable interface. A product manager can build a working prototype. A designer can explore data, frame a problem and propose priorities.
Many everyday tasks can now be handled by someone outside the role that traditionally owned them. Our process should make room for that.
I suspect a few small, autonomous teams with clear goals can accomplish more than much larger teams working through a long chain of dependencies.
The benefit goes beyond speed. When people understand the customer’s problem and own the result, they can question assumptions, notice gaps and change direction sooner. They have a reason to think beyond their part of the ticket.
As building becomes cheaper, clarity about what to build becomes more valuable.
What I mean by Überengineers#
How about engineers who can take a customer problem, understand why it matters, propose an approach, design it, build it and follow through after release.
That means asking better questions before writing code. Making sensible product and design decisions within their scope. Knowing when to seek specialist help. Checking whether what they shipped actually solved the problem.
Technical depth still matters. So does understanding users, communicating tradeoffs and taking responsibility for the outcome.
What we’re going to try#
We’re starting with a small internal experiment:
- Help a few engineers grow into product engineers. They’ll own well-scoped problems from discovery through release and validation. Even five engineers working this way could let us pursue more problems in parallel.
- Give product and design more room to cross boundaries. For most of the tasks, designs are no longer the bottleneck. Product and design can spend more time understanding customers, framing problems and setting direction.
- Keep product focused on the what matters most. Product teams should spend more time understanding customers, choosing opportunities and setting direction, while engineers take greater ownership of simpler, well-understood problems.
This transition will need coaching. Some engineers have good product sense already, but despite that as well, we’ll need to help them grow into the role. We plan to pair each engineer with a product manager and designer to help them adapt quickly.
I don’t know how far this model will work for us yet. But the tools have changed enough that it feels worth questioning the process around them.
Let’s see how it goes.
