Your next product team could be a single person

Something is replacing the product trio. It’s not a new framework or a reorganization. It’s a single person who can now do what three used to — and the tools to make that real are already here.

The product trio: a product manager, designer, and software engineer, has been the default building block of empowered, successful product teams for more than a decade. In the 2010s, it became the default operating model of empowered product teams across the industry and spread wide and far through Marty Cagan’s Inspired and Empowered.

The product trio was needed because it was nearly impossible for any single person to be proficient in product, design, and engineering simultaneously. Let alone take on the responsibility of value, viability, feasibility, and usability. Of course, solopreneurs and other lone builders have always existed and built successful businesses, but the ceiling on the scale and quality of what a single person can do has always been there.

Recently, it’s become clear to me that the advancements in LLMs are enabling another model that might make more sense, especially for startups and scaleups.

The product engineer

A product engineer, to me, means someone who is proficient enough in all three roles and is thus capable of

• figuring out what problems are worth solving,
• finding the best solution,
• designing the user interactions and interfaces,
• and delivering the technical solution.

For pre-PMF startups, you can add GTM to the list.

That’s no easy task. It takes years of practice to develop the taste, judgment, and skills that are needed. It requires a person with high agency, a growth mindset, and curiosity. Execution requires plenty of time and effort, too.

But don’t let that stop you, or make you believe there are no such people. While it’s extremely rare to find someone who is world-class in all these areas, the truth is you don’t have to. There’s an old saying that goes, “A jack of all trades is a master of none, but oftentimes better than a master of one”. I’ve witnessed countless times that skills can be learned. It’s the mindset that matters.

If this is true, why haven’t we really seen product engineers in companies before? Why now?

The LLM compression

As an engineer and founder, I’ve worked with countless businesses and lived and breathed agentic coding, and nothing is clearer to me than that the use of LLMs accelerates both learning and execution.

I recently repositioned Zero, a CMS for Astro that I’m building, as an AI-native CMS. The process was roughly as follows:

1. Get feedback and input from customers and people with hands-on domain expertise

2. Feed that knowledge as context into an LLM (Claude Code in my case)

3. Use agents and agent teams to

   • help identify the gap
   • research market data and competitors
   • synthesize discussions and threads from forums such as Reddit or Discord
   • clarify and challenge my own thinking
   • refine product strategy
   • think through the distribution

4. Prototype the key user interactions and features with the help of LLMs

5. And finally, use agents to build the actual features and refine the messaging, using my taste and judgment as guidance.

The result:

I gained new market insights, identified distribution challenges, and learned user interaction patterns I would not have discovered on my own. Without them, I’m sure I would have made costly mistakes, only to notice them later down the road.

Luckily, I had also invested heavily in testing infrastructure and test coverage, so I felt that what had previously taken a week to ship now took a day. I’m old enough to remember what writing all that code used to take before the AI.

All of this means just one thing. If one can now learn and execute at a much higher pace than before, then the role of product engineer is suddenly much more accessible. Again, it’s the mindset that matters, and no LLM will help you there.

Also, when people like Nan Yu from Linear suggest that LLMs are already better than 90% of PMs in many cases, why not have an engineer take on that responsibility?

That said, product engineers need specific conditions to be successful.

Where it fails

Let’s be honest. The product engineer model is not for every company. It only works when the engineer can fully own outcomes and feels trusted and empowered. They also need to talk directly with customers and end users. In many regards, this is similar to what a founder would do.

Anything less than that won’t work. Give a roadmap of features to build, and the product engineer will shrink back to a demotivated developer who will deliver you output, not outcomes.

For any decently sized company, and for those working with multiple product engineers, there are two additional questions to be addressed. How to make sure that each product engineer has the skills it takes? And how to make sure they’re aligned with business goals and product strategy, and can deliver a consistent user experience?

Which brings us to the…

Role of product managers and designers

Even with the product engineer model, there’s a place for experienced product managers and designers — but in fewer numbers and doing different work. Most companies running this model end up with fewer PMs and designers than the trio model would suggest. Companies such as Linear and Stripe had operated for years before hiring their first PM.

The ones who remain serve a different purpose at a higher level: upskilling, alignment, building frameworks, and hiring. They’re still very much involved with the product and its customers, but their work now spans the whole company and the entire product, not just a single team or feature.

Upskilling happens mainly through coaching. Taking frequent 1-on-1s with the product engineers to identify the gaps in competence and helping them fill those gaps, be it through practical work, reading, or encouragement to talk with more customers, for example.

Alignment brings clarity. What are our goals, what is the vision, what’s important, and specifically what’s not important? Are there common rules or guidelines that everyone should follow? While many of these are business-level decisions, the PMs and designers are responsible for ensuring every product engineer is aligned and understands how their work contributes to the whole. And not just that, but they’re also responsible for making sure learnings from individual engineers travel back to benefit everyone.

Frameworks are needed for consistency. By framework, I mean common building blocks such as a design system, component library, tooling, and other ways to standardize how the company operates in certain areas. When built well, they provide clarity and make everyone more productive.

The operating model in practice

Let’s say you’ve found your product engineers. They’ve got your trust and support, and they’re aligned on goals and strategy. They have a great product sense and frequently talk with customers. What can you expect?

I experienced this firsthand when I started working for a startup 10 years ago. I was their first tech hire and effectively served as a product engineer. In just a few months, we had identified their most pressing problem, and I had designed and built a product to solve it. It became the backbone of their operations and was often referred to as their most successful product, even years later.

Here’s what I think made it work, and what I’ve seen repeat in similar setups since:

Customer problems get solved faster. Because there are no layers between the problem and the person who can fix it, no time is wasted in coordination, management, or waiting for others to finish their upstream work.

Ownership compounds. When product engineers are responsible for solving a problem end-to-end and the communication that entails, they take pride in what they’ve built. That feeling of ownership compounds in several ways. Engineers are more motivated, so customers receive better, faster service. If something doesn’t work as it should, it gets fixed or improved, not added to the backlog as a bug.

Learning rate increases because a single person owning the outcome now understands the full picture, can reflect on why each decision was made, and can learn from their own mistakes. A product trio gives an excuse to think there might be others to blame. Being the solo engineer forces honesty.

Innovations start popping up. A product engineer deeply understands the business and customer problems, knows how people interact with the product, and what the latest technology enables. Because they understand both the tech and the user, they’re often the ones who see a genuinely new angle nobody else does. They’re also the first to notice when something isn’t working — when customer behavior shifts, or the product no longer fits. While this can also hold true for product trios, I’ve seen this more frequently from product engineers.

This all takes courage to pull off and needs the right kind of people and the environment to work out. If you have it, I think the benefits are totally worth it.

Guardrails

Giving the product engineers autonomy and freedom to build as they like comes with a few risks that are less of a problem in traditional product trios or development teams. That’s why you probably want to build a few guardrails as protection.

The first risk is technical. The engineer might rush through the implementation, neglecting important aspects such as proper software architecture, maintainability, or security. With less external control, formal review, or pressure from peers or the trio, the bar is held high by the engineer’s own internal standards.

That said, smart teams acknowledge this and set up guardrails to protect against it. With tools such as Claude Code or OpenAI Codex, it’s now possible to create skills and commands that run automatically either on developer machines or the CI server to catch and enforce quality issues like these, providing invaluable feedback for the engineer. It’s exactly the same reason I built pre-publish checks for Zero: to automatically catch content quality issues, such as broken links or missed SEO opportunities, before the content goes live.

The second risk is human. Unless we plan for it, working independently can cause the quality and direction of work to drift without anyone noticing. This is why the 1-on-1s and upskilling are so important. It’s also important to regularly bring everyone together, share lessons learned, and celebrate wins. To make everyone feel like they belong to a team despite the independent nature of the work.

Conclusion

The product trio was never the ideal model, at least not for every company. It was a workaround for a real constraint: no single person could learn and operate fast enough across product, design, and engineering to own the full problem. LLMs have compressed that enough to change the equation.

What makes this shift structural, not cosmetic, is that the benefits compound. A product engineer who owns the full loop — from customer problem to shipped solution — builds context that doesn’t need to be transferred, alignment that doesn’t need to be managed, and judgment that sharpens with every cycle. The trio fragments all of that across three people and then spends coordination effort trying to stitch it back together.

That said, this model is not for everyone. It needs high-agency people with genuine curiosity, leadership willing to grant real autonomy, and a product surface that one person can meaningfully own. Without those, you’re just removing structure and calling it empowerment.

Shifting the mindset is the hard part. But for teams where the mindset already exists, the remaining barriers are falling fast.

← All writing