The Planck Product Team

Disclaimer: This post, like the vast majority of my posts, is about small teams of fewer than 30 people. Projects with teams larger than that tend to bore me, so I avoid working on them, thinking about them, and—most importantly—writing about them.

In the past, product teams that I've been part of tended to have a fairly similar structure.

CEO: Kicked off the project, maybe built a visual mockup or two.

Technical Product Manager (me!): Wrote the initial proof-of-concept code, maybe got it all the way to MVP. Then hired the team required to take it further.

UI/UX Designer/Team: Made the product look like something people actually wanted to use.

Frontend Developer/Team: Took those designs and turned them into a website/mobile app/whatever.

Backend Developer/Team: Made the frontend function and set up the cloud infrastructure, databases, APIs, etc.

DevOps Engineer: CI/CD pipelines, environment management, security (because this is basically the same thing as DevOps, right?), etc.

For specific projects, the team would look slightly different, but this was the broad shape of it.

For a scalable enterprise project, this might be a five-person development team costing north of $1 million a year in salaries. In my experience, this was roughly the floor for building serious enterprise MVPs or production-grade consumer software.

There are a few inherent weaknesses with this setup.

The biggest one: it's slow to set up.

Assuming you're not willing to contract the whole thing out to a dev shop—and for mission-critical software, that's rarely the right call, for a myriad of reasons I'll get into in another post—the hiring sequence normally looks something like this:

1. Hire your technical PM (me!). About two months. Key stakeholders have to get on board, agreements have to be signed, gear has to get purchased, etc.
2. Have the technical PM build your MVP. An unknown amount of time, depending on the project. We'll exclude this from the timeline because useful development work is actually getting done.
3. Realize you need to grow the team. About a month. You'd be amazed how long it can take key decision-makers to acknowledge that more headcount is required.
4. Post jobs and run interviews. About three months, assuming the TPM and CEO/key executive are spending a minimum of 20 hours a week on recruiting.
5. Hire and onboard. About a month.
6. Get the new developer to the point where they're a net positive to the project. About another month.

So, excluding step two—where useful development work is getting done—this structure can create roughly eight months of organizational overhead between deciding to build a product team and actually having the team you need to take the product to production.

Until now, that hasn't necessarily been much of a competitive disadvantage.

Most software teams faced roughly the same constraints. If everyone has to pay the same eight-month organizational tax, it simply gets baked into everyone's expected timeline.

But AI creates another option, what I call a Planck product team: the smallest unit you can reduce the team to before it stops working. A five-person team has ten possible communication channels, plus handoffs, meetings, merge conflicts, and all the little coordination costs that simply don't exist when one person can own the whole stack. What if you can reduce that team down to the smallest possible headcount, one? You'd be able to get to market faster, cheaper, and (weirdly) with a higher-quality product.

It's the model I've been working on perfecting because it's substantially more profitable for both the end customer and for myself 😉.

With the coding environment I've built, I'm able to operate much more like a one-man product team. I've encoded my build philosophy, development process, preferred tools, architectural patterns, and specialized skills into the harness itself.

That means that when I start a new project—assuming it looks reasonably similar to projects I've built before—I can skip steps three through six above and simply do the work myself, to the same standard I'd otherwise expect from a team of specialists.

A few months ago, I don't think this would have been possible. With 5.6 Ultra plus my coding harness, I've now done it across four different projects. Here's what that looks like in practice.

A colleague of mine in the commercial real estate industry came to me with an idea a few months ago: What if we built a vertical agent for CRE developers?

There are $100M+ development projects today that are literally being managed out of Outlook inboxes, with no AI copilot watching for important items that are getting dropped.

And when one of those items gets dropped, it can cost a developer $2–3 million and delay a project by months.

So we got started.

Getting the engagement kicked off—the equivalent of step one above—took about two months.

As expected.

Then, nine days later, we deployed our MVP.

The vertical agent reused a lot of the knowledge-base infrastructure I'd already built for two other, non-competing projects.

And while every cloud microservice architecture is unique, they're not thatttt unique. I stood up the entire cloud stack in one night.

That's the advantage.

A competitor starting from scratch with the old model might spend the next several months recruiting the team required to build what we already have in production.

While they're hiring, we get to spend that time talking to customers, learning what works, improving the product, and winning more business.

I think this is the future.

Not for every project. Not for every industry. And certainly not forever—a successful product will eventually reach a level of scale where specialization starts making sense again.

But for early-stage projects where speed matters, I think the minimum viable product team is going to become dramatically smaller. Five years from now, I suspect one highly capable builder working with a fleet of AI tools will be the default starting point for a huge class of software projects. It's absolutely possible right now, but it'll take time for the majority of companies to catch up. Such is the way with disruption.

But there's very little reason to go back, and profit to be had by pioneering forward.