Running Several Products With a Small Team

People are often surprised when we tell them how many products we run and how few of us there are. The usual assumption is that each product needs its own team, its own roadmap meetings and its own late nights. In our experience it does not, provided you are strict about a handful of habits. This post sets out how we keep several live products moving without letting any of them quietly rot.

It follows on from how we choose what to build next. That piece was about deciding what earns a place in the portfolio. This one is about what happens afterwards, once a product is live and needs looking after alongside everything else.

Accept that attention is the scarce resource

With a small team, the limiting factor is rarely money or technical skill. It is attention. Every product wants some of it every week: a support question, a bug, a small improvement a customer asked for, a renewal to check. If we let each of those land whenever it arrives, the day disappears into context switching and nothing meaningful moves forward.

So we treat attention as something to budget, in the same way a finance team budgets cash. Each product gets a clear share of the week, and we protect that share from the others. It sounds rigid, but it is what makes the whole thing work.

Give each product a rhythm, not a queue

Rather than working on whichever product shouts loudest, we run on a simple rhythm. Most weeks, one product is the focus: it gets the deep, uninterrupted work, whether that is a new feature, a rebuild of something fragile or a push on growth. The others are in maintenance mode for that week, which means support is answered, anything broken is fixed, and nothing new is started.

Over a month, focus rotates through the portfolio according to what matters most. A product with a busy season, such as Aisle Reply in the run-up to wedding season, gets more focus weeks at the right time of year. A product that is stable and doing its job gets fewer, and that is fine.

Why maintenance mode matters

Maintenance mode is not neglect. It is a deliberate promise that a product will keep working and customers will get answers, even when nobody is building anything new on it that week. Being honest with ourselves about which mode each product is in stops us pretending we are making progress on six things at once when we are really making progress on none.

Build the plumbing once

The single biggest reason a small team can run several products is that we do not rebuild the same foundations for each one. Sign-in, billing, email sending, hosting, backups, monitoring and the admin tools we use to support customers are built once and shared. We explained the thinking behind this in what a venture studio actually does.

The payoff shows up every day. When we improve how password resets work, every product gets the improvement. When we tighten security on the shared platform, every product is safer. When something breaks at the infrastructure level, we fix it in one place rather than six. The work that would normally be multiplied by the number of products is done once.

The trade-off

Shared foundations come with a cost: a change to the platform can affect every product at once, so we are more careful with it than we would be with a single app. We test shared changes more thoroughly and roll them out gradually. That discipline takes time, but far less than maintaining several separate stacks.

Write things down so nobody is a bottleneck

In a small team, knowledge easily ends up living in one person's head. That works until that person is on holiday and a customer of a product they built has a problem. We keep short, practical notes for every product: how it is deployed, where its settings live, what usually goes wrong and how to fix it. None of it is elaborate. It just needs to be good enough that anyone on the team can pick up an issue without a phone call.

The same goes for decisions. When we decide to change direction on a product, we write a few lines explaining why. Months later, those notes save us from reopening arguments we have already settled.

Automate the repetitive, not the judgement

We automate anything that is repetitive and predictable: deployments, routine reports, reminder emails, health checks that warn us when something looks wrong. That frees up the limited attention we have for the parts that genuinely need a person, such as talking to customers, deciding what to build and judging whether a change is worth making.

The rule of thumb is simple. If we find ourselves doing the same small task every week across several products, it is a candidate for automation. If a task needs taste or context, it stays with a human.

Be willing to put products on a shelf

Running several products well sometimes means running fewer of them actively. If a product is not earning its share of attention, we would rather move it into a long-term maintenance state, or retire it cleanly, than let it drain focus from the ones that are working. That is not a failure. It is the same discipline that decides what gets built in the first place, applied after launch.

What we would tell another small team

If you are thinking about running more than one product with a small group of people, our advice is short. Budget attention deliberately. Pick one focus at a time and keep the rest in honest maintenance mode. Share every foundation you can. Write down how things work. Automate the dull parts, and be willing to shelve what is not pulling its weight.

You can see how this plays out across the studio on our portfolio page, from Unavoidable CRM to our newer products. If you are running a small multi-product team yourself and want to compare notes, we would love to hear from you through our contact page.

← Back to the blog