The Minimum Viable Team
Jan 17, 2026 • 3 min read
The minimum team I'd hire if I were serious about building something great: PM, designer, developer.
Listen to this post in the author's own voice
Over the many years building, I’ve noticed a consistent pattern in most early stage startups led by first-time founders:
Hire a developer. We’ll figure out the details as we go.
Not a product manager.
Not a product designer.
Just someone to build it.
On paper, that sounds lean. Maybe some pull it off. Don’t get me wrong, I’m all about developers. But every time I’ve watched the developer-only approach play out, it has failed — and it fails the same way every time.
How it actually goes
The founder becomes the product manager by default. Priorities change weekly. The developer stops building toward anything and starts reacting.
Nobody owns the question “what do we not build right now?” So everything gets built.
Meanwhile the developer absorbs everything else — product management, UX design, QA, release management. Jobs they weren’t hired (or wired) to do. Quality collapses first. The developer collapses next.
Somewhere in there, something ships. It might even be technically fine. Nobody uses it, because nobody validated the problem it was supposed to solve.
Then comes the rewrite. The v1 is unsalvageable, and whoever is left starts over.
Frustrated founder. Burned-out developer. Failed product.
“Can’t AI do the other two jobs now?”
Fair question. LLMs write PRDs and user stories. They generate flows and screens. I use them for product output myself, not just code.
But AI amplifies a role — it doesn’t replace the judgment behind it. A generated PRD still needs someone who knows which problem is worth solving. A generated flow still needs someone who knows where users get stuck. A human still needs to own each deliverable, or it just got faster to build the wrong thing.
The Team
The trifecta below is the minimum team I’d hire if I were serious about building something great. One of each. Not two people wearing three hats.
Product Manager
They own:
- Problem definition
- User research
- Prioritization
- Scope control
- Success metrics
- Turning ideas into clear user stories
They answer:
- Who is this for?
- What pain are we solving?
- What does “done” look like?
- What do we not build right now?
Product Designer
They own:
- User flows
- Interaction models
- Information hierarchy
- Edge cases
- Accessibility
- Usability validation
They answer:
- Can someone actually use this?
- Where do people get stuck?
- Does the flow make sense before we build?
- Can users find what they need?
Developer
They own:
- Architecture
- Code quality
- Performance
- Infrastructure
- Security
- Deployment
- Maintainability
They answer:
- Will it hold up?
- Can we ship it and maintain it?
- What do we build vs. buy?
- Is it secure?
Before hiring anyone
The product manager’s questions need answers first. Who is this for? What pain are we solving? What does “done” look like? If nobody on the team can answer those, the first hire isn’t a developer — because the developer can’t answer them either.
Get the trifecta right first. Then scale.