Priority Rules for a Small Team Running Several Products at Once

What Breaks First When You Add More Products

When a team goes from one product to three, the first thing to break is not development speed. It is consistency of judgement. A decision made last week on one product starts to contradict a decision made this week on another, and the contradiction only surfaces weeks later. Context breaks before code does.

Every product has its own users, its own definition of a good signal, its own deployment path and data model. Spending the morning on attendance rules in a workforce tool and the afternoon on search ranking in a job board costs more than the clock time between them. The intuition you were just building on the first task disappears. Rebuilding that intuition never appears as a line item on any schedule, which is exactly why teams never learn how much it costs them.

The second thing to break is response time. With one product, anyone can answer an incoming question. With three, the set of people who can answer narrows to one, and if that person is deep in another product, the answer slips by a day. A late answer does not stay merely late. The same question comes back, the user concludes the service is unattended, and the support load returns heavier than it started.

The third thing is the written record. With one product, thin documentation can be patched with memory. With several, memories start blending. Pushing a build to production when it should have gone to staging usually is not a skills problem. It happens because three separate procedures were being stored in one person's head.

There is a simple way to check whether your team is already at this point. Ask each person separately what they are working on this week. If the answers differ, the problem has started. Then ask which product matters most right now. If two or more people name different products, no priority order exists. This is where the stretch begins in which everyone works hard and nothing finishes.

We went through the same stretch. Yeowubie Interaction runs onSpots for attendance management, Langtori for matching and mapping between people learning Korean and people teaching it, Job Connect VN for hiring in Vietnam, and Winnie for helping small merchants run their shops, while also delivering client work. The problem was never a shortage of people to build things. It was the attempt to hold several different sets of judgement criteria in one head at the same time. So instead of adding people first, we set rules first.

There Is a Ceiling on How Many Products You Can Run at Once

The number of products you can run in parallel is not set by headcount. It is set by the number of live decision lines. A decision line is any stream of work that requires someone to make a call every week. Adding people does not help if one person still carries more than two decision lines. Quality of judgement drops there, and that is where the ceiling comes from.

A product is not a codebase. It is a standing load. Even if you ship no new features at all, the load never reaches zero. Store review policies change, an operating system update breaks an old approach, a dependency gets a security patch, certificates and domains come up for renewal, questions arrive, and the infrastructure bill recurs monthly. This load belongs to keeping a product alive, not to building it. Adding a product is therefore not a decision to extend a development schedule. It is a decision to carry one more fixed weekly load indefinitely.

This is where slots become useful. Divide the positions your team has into three kinds, active development, maintenance, and experiment, then fix how many of each you allow. Active development is where new features and improvements actually land. Maintenance is where a product stays alive but receives no new features. Experiment is where something runs on a fixed clock for the sake of learning. The important part is capping the number of active development slots. To move a new product into active development, an existing one has to move down to maintenance. Without that forced trade, the active list keeps growing, and a list that long is eventually a list where nothing moves.

Capping work in progress is not a new idea. It has been used for a long time in manufacturing and in software alike. It works particularly well for small teams because the fewer the people, the higher the chance that one person sits across several streams, and the larger the loss from switching between them.

Maintenance mode does not hold if it lives only in conversation. Write it down. The work permitted in maintenance is incident response, security updates, store and platform policy compliance, and anything that prevents data loss. New features are out. The requests that erode maintenance mode are the ones that sound smallest: just change this label, just add one screen. Small requests do not stay small. Testing follows, deployment follows, regression checking follows. When you define maintenance mode, define the exit condition alongside it. If everyone knows what would justify moving the product back into active development, the owner can wait without breaking the rule.

Set the ceiling from records rather than instinct. Track actual hours per product for two or three weeks and the weekly fixed cost that has nothing to do with new features becomes visible. If that fixed total exceeds half of the hours your team actually has, there is no room for another product. Done by estimate, this calculation always comes out optimistic. It has to be measured.

Three Axes for Setting Priority: Survival, Learning, Upkeep

Ranking products by revenue outlook alone gets it wrong most of the time. Three axes have to be read together. First, the chance the product survives. Second, what can only be learned from that particular product. Third, the upkeep that accrues even when nobody touches it. The goal is not a score. It is an order.

The first axis, survival, is judged from signals rather than hope. The trouble is that most teams decide what counts as a signal at the moment they need to read results, not at the moment they start. Decided then, the choice becomes whichever number happens to look favourable. Decide at the start instead. Are there users who come back repeatedly, are incoming messages complaints or feature requests, is anyone finding their way in without being guided there. Feature requests are usually a better sign than complaints, because they imply the user intends to keep using the thing. Whenever you define a signal, write the observation window next to it. Without a window, the judgement gets deferred forever.

The second axis, learning, matters more to small teams than to large ones. Even when a product is not yet earning, the investment is recovered if the capability built along the way transfers elsewhere. Do multilingual and locale handling properly once and the next product gets designed differently from the first sketch. Pass store review a few times and you start avoiding rejection reasons before they happen. Handle time zones and formatting conventions for a service that spans two countries and that experience does not evaporate. That said, any product kept alive on learning grounds needs an expiry date attached. Learning without a deadline is just neglect.

The third axis, upkeep, should not be counted in money alone. Infrastructure cost is visible because it prints on an invoice, but attention is the more expensive resource. Each product adds one more dashboard to check weekly, one more policy change to absorb, one more body of background knowledge you need in order to trace a failure. Attention differs from money in that you cannot go earn more of it later. When you look at upkeep, look past this month's bill to the share of human attention the product will take every week from here on.

The real decision point arrives when the three axes disagree. Weighting the axes and adding them up is not something I would recommend. Scoring tends to slide into picking the conclusion first and tuning the weights to match. Define the response for each combination instead. Weak survival signal but strong learning goes down to a time boxed experiment. Strong signal but heavy upkeep means reducing that upkeep becomes the quarter's assignment. Weak signal, nothing left to learn, and upkeep still flowing out is the case the next section is about. Strong signal and strong learning is what earns an active development slot.

Once the order exists, write it somewhere the team can see. A priority order that lives only in someone's head gets replaced by whoever speaks loudest in the next meeting. Written down, changing it requires a reason, and requiring a reason cuts the number of impulsive changes sharply.

Why One Person Should Own One Product End to End

Splitting a product across several part time contributors produces worse results than one owner, even when the total hours are identical. The cost of rebuilding context multiplies by the number of people involved, and decisions keep getting postponed. When one person carries a product from requirements through build, release, and follow up, judgement gets faster and responsibility has an address.

Start by defining what ownership covers. It covers clarifying requirements, building, releasing, taking first line questions from users, and keeping that product's documentation current. Define it narrowly and ownership becomes a title with nothing behind it. If one person builds while another handles support, the supporter has to ask every time and the builder has to stop every time. Both lose.

The obvious objection arrives immediately: what happens when that person is away. It is a fair objection and not a reason to abandon the model. Three measures cover it. Name a backup for each product whose only standing duty is to stay able to read the documentation. Keep release and recovery procedures in documents and scripts rather than in memory. And once a quarter, have the backup actually perform a release. You cannot tell whether documentation is correct by reading it. You find out by running it.

The leader's job is to genuinely hand the decision rights over. Declaring ownership while approving every decision leaves the owner as a messenger and the bottleneck exactly where it was. Draw the line in advance for what an owner decides alone. Screen composition, implementation approach, and the order of small improvements can normally sit with the owner without trouble. Only the hard to reverse items, pricing structure, data retention policy, timing of public release, need to move upward. Without that line, every decision travels up and the leader ends up adjudicating the details of every product in operation at once. Decisions made from that seat are rarely good ones.

Some things should not be split by owner at all. Authentication, security standards, the deployment pipeline, design tokens and shared components are all worse when each product does them differently. Pull them into a shared layer, decide once, and have everyone follow it. Built per product, you maintain three copies and patch three places when a security issue lands. Overextend the shared layer, though, and you kill the flexibility individual products need. The boundary test is simple. If a mistake only hurts one product, keep it inside the product. If it spreads across products, lift it into the shared layer.

The weakness of ownership is that knowledge gets trapped. When everyone only watches their own product, the team's technical level rises unevenly. Run a short recurring session for sharing. One place you got stuck and one way you got past it is enough content. Require slide decks and it stops happening, so keeping the format light is what makes it last.

You Need a Rule for Deciding to Stop

A team with starting rules and no stopping rule keeps accumulating products. Write the stopping conditions when the product starts and you can decide later without emotion in the way. Stopping is not a declaration of failure. It is an operational act that frees a slot, and freeing a slot is what lets the next thing begin.

Stopping has three levels, and discussions go to extremes whenever those levels are not separated. The first is a move to maintenance: the service keeps running and only new development halts. The second is suspension: new signups or new inbound are closed while existing users are kept. The third is shutdown: the service comes down and data gets handled. Most situations call for the first or the second, but because the word stop is heard as the third, the conversation becomes hard. Naming each level separately makes it much easier to talk about.

When a product starts, write down three things. How long the observation window runs, what you would need to see within it to keep going, and which of the three levels the product drops to if that signal does not appear. Writing those three lines at the start costs very little. Left until the moment you need them, attachment and sunk cost are already attached and no criterion survives agreement.

Once you decide to stop, treat stopping itself as a piece of work. Simply walking away is neglect, not stopping. Tell users in advance what changes and when, leave a path for them to take their data, tidy the store listing status, check domain and certificate expiry, shut down the remaining infrastructure, and if reopening is plausible, leave a document describing what reopening would require. Skip that closing work and the stopped product keeps drawing cost and attention. This is exactly how a team ends up receiving monthly invoices for something it believed was already shut down.

To keep this judgement from becoming impulsive, put it on a schedule. Once a quarter, lay out every product in operation, reread the three axes, and adjust the slot assignments. Some quarters nothing changes as a result. Keep the session anyway. Without a schedule, stopping only gets discussed after the problem has grown, and by then shutdown is the only option left on the table.

The stopping rule described here is an operating instrument, not a procedure aimed at any particular product. It is a different thing from announcing that something will be discontinued. The purpose of writing the rule in advance actually points the other way. When a way to stop exists, starting something new gets easier. Teams delay starting when they feel there is no way back, and start small and fast when a way back is defined. Priority rules and stopping rules are not there to make a team timid. They are the minimum instruments for keeping judgement sound while a small group keeps several products running.