Should a Small Team Build a Product and Run Client Work?

Four people. Three retained clients, one of them loud. And a product that has been “about six weeks from beta” for most of a year. If that description lands, the diagnosis you have been given is almost certainly wrong, and the wrong diagnosis is why nothing you have tried has worked.

The usual explanation for a failing agency product split is focus. Split attention, half-finished work, the old line about serving two masters. It sounds correct and it is useless, because focus has no lever attached to it. Nobody can decide to be more focused on a Tuesday morning when a client’s checkout has stopped taking payments.

The actual conflict is urgency asymmetry. Client work carries a date and a person who will ask about it. Your product carries an intention. Week after week, the thing with the date beats the thing with the intention, and it wins for entirely reasonable reasons, chosen by sensible people, one borrowed hour at a time.

That reframing is worth something, because asymmetry has levers and focus does not. You can attach dates. You can move who is allowed to interrupt whom. You can change what a week is made of. None of that requires anybody to be more disciplined than they already are.

The agency product split is not a focus problem

Two kinds of work sit on one calendar. One of them has a client, a scope, an invoice and a person who notices when it slips. The other has none of those things. It has a founder who cares about it, which is a real force but a slow one, and it competes against a fast one.

Notice that this has nothing to do with how interesting the work is. Teams in this position usually find the product more interesting than the client work, and the product still loses. Interest does not schedule anything. A date does.

Client work has a date on it. Your product has an intention. Intentions lose, quietly, for excellent reasons, every week.

What the asymmetry does to an ordinary week

The borrowed hour

Nobody ever cancels product work. That would require a decision, and a decision would be visible. What happens instead is borrowing. Two hours on Tuesday because a scope question came in. Wednesday morning because the staging environment broke. Thursday because the call ran long and there was no point starting anything after it. Every one of those choices is defensible on its own, and none of them is ever repaid, because there is no ledger recording that a debt was taken.

The absence of that ledger is the mechanism. Client hours are counted because somebody bills them. Product hours are not counted at all, so a week can lose all of them without producing a single number anybody has to explain.

The deadline that does not exist

Internal deadlines are not deadlines. Nothing happens when they pass. No client calls, no penalty applies, no relationship cools. So an internal date is a preference wearing a calendar entry, and everybody in the team knows it, including the person who set it.

This is why “we will finish it between projects” never happens. There is no between. There is a gap that gets filled by the next enquiry, and filling it is the correct commercial decision every single time you look at it in isolation. The fix is not willpower. The fix is to change what the product is, structurally, so that it stops being the only work on the calendar with nothing attached to it. That is what the three models below do, and it is worth reading them against your own delivery approach rather than in the abstract.

Three models that actually work

These are not stages of maturity and they are not a spectrum. They are three different bets, and choosing between them is mostly a question of how many people you have and which risk you are least able to absorb.

One: the fenced team

A named group works on the product and is not staffed on client delivery. Not “mostly not”. Not “only in emergencies”, because every week contains an emergency if you are willing to call it one. The fence is a rule about who may be asked, and it is enforced by the person who would otherwise do the asking.

This is the model that produces the most product per month, and it is the most expensive one to hold, because it removes flexibility exactly when a client peak arrives. It needs enough people that losing two from the delivery pool does not put a deadline at risk. Below about six or seven people, the fence gets breached in month two and then nobody believes in it again.

Two: the calendar split

The same people do both, but never on the same day. Product weeks and client weeks, or a fixed pair of days each week that are as unavailable as a holiday. The unit has to be large. A morning is not a unit, because context switching eats the first hour and the anticipation of the afternoon eats the last one.

This is the model most small teams should choose, and it is genuinely slower than fencing. Momentum resets at every boundary, and you will re-read your own code more than you would like. What it protects is cash, which is the thing that kills more products than slow progress ever did.

Three: the product as a client

The product gets treated exactly like an engagement. A brief, a defined scope, a start date, a delivery date, a named person accountable for it, and a slot in the schedule that was allocated the same way a paying project’s slot is allocated. Someone inside the team plays the client and is allowed to be unreasonable about the date.

This sounds like theatre and it is the model we would reach for first with a team that keeps missing its own dates, because it borrows the one thing client work has and product work lacks: a person who notices. It also forces the scope conversation early, since a brief with no end is not a brief. If you have run a product launch for someone else, you already own the process. Point it at yourself.

What each model protects, and what it costs

Pick by what you cannot afford to lose, not by what sounds most professional. The column that should decide it is the second one.

The last row is not a joke. Running no model is a choice, it is the most common one, and its cost is paid in a product that absorbs attention for eighteen months and never reaches anyone. Naming it as a model at least makes it comparable to the others.

The failure mode nobody plans for

Scope with nobody to say no

Client scope is bounded by someone who will not pay for more. Product scope is bounded by nothing except taste, and taste expands when a team is talented and unsupervised. So the product grows a settings page, then a second user role, then an integration somebody was excited about on a Friday, and the beta recedes at roughly the rate you approach it.

Narrow scope is what makes a product shippable by a team that also has clients. Not a smaller version of a big idea: a genuinely narrow idea, done properly. Nichevio is deliberately built this way, assembling mobile-first profile sites from structured widgets rather than trying to be a general website builder, and that constraint is the reason it is a product rather than a project. Every feature you decline is a week you get back, and the weeks are the whole game.

Watch, too, for the request that is not really a request. When an early user asks for a feature, the honest read is often that they cannot tell what the product is for. We wrote about that pattern in when a feature request is actually a positioning problem, and it matters doubly here, because building the request costs you the one scarce thing you have.

The public surface goes last, and it shows

Agencies that would never ship a client site with a slow first paint and three placeholder pages will happily do exactly that for their own product, because nobody invoices them for it. The site, the documentation and the onboarding are the parts a stranger meets first, and they get whatever attention is left. We set out the minimum in what a SaaS website needs before the product is ready, and the case for treating documentation as a channel rather than a chore in documentation as a growth channel. Hold your own product to the standard you sell: useful content written for a reader, and page performance you would be willing to show a client.

Signals you are already in trouble

None of these is fatal alone. Three at once means the model you think you are running is not the model you are running.

• The product date has moved three times and nobody remembers what the original one was.
• Product work only happens after hours. That is not commitment, it is a scheduling failure being paid for with somebody’s evenings.
• Nobody can name this week’s product outcome without opening a board and reading it.
• The demo is always “nearly ready”. A thing that is nearly ready for six months is not nearly ready.
• You have never shown it to a stranger. Internal enthusiasm is not evidence, and it is remarkably durable.
• The product has no owner, only a founder who is also the person most likely to be pulled into a client escalation.

What the product has to earn to keep its slot

A product that takes capacity from paying work should be answerable in the same way paying work is. Run this at the end of every cycle, out loud, with the whole team present.

1. Did anyone outside the team use it this cycle? Not saw a demo. Used it, unaccompanied, on their own machine, for their own reason.
2. What did we learn that we could not have guessed? If the answer is nothing, you spent a cycle confirming your own assumptions at full cost.
3. What did we remove? A cycle with no deletions is a cycle where scope grew, and growing scope is how the date moves without anyone deciding to move it.
4. Can a new user reach the point of the product alone? The first ten minutes decide whether anything else you built gets seen at all.
5. Would we spend this capacity again, knowing what we now know? Answer it honestly once per cycle and the decision to stop, if it comes, arrives early enough to be cheap.

Question four deserves its own attention, because teams building alongside client work systematically underinvest in it: the first ten minutes of onboarding are where most of the value of everything else is decided. And on question one, you do not need a research programme to get an answer. The argument for a small number of watched sessions against shipping and measuring is laid out in testing with five users or shipping and measuring; either is fine, and neither is what you are doing now.

What we would do with four people

Calendar split, two fixed days a week, treated as unavailable. One named owner for the product who is not the person handling client escalations. A written non-goals list. A cycle of four weeks with a demo at the end, to somebody outside the building. That is the whole system, and it fits on an index card because it has to.

Here is the concession, and it is a real one. This costs money you can see and delivers value you cannot yet see, and there will be a month where that trade looks stupid. Some months it will be stupid. The answer is not to abandon the split when a large project lands, but to pause it explicitly, with a restart date, so that the pause is a decision rather than the beginning of a drift nobody ever names.

And the option most teams refuse to price: do not build the product. If it exists mainly because the team wants something of its own, that is a reasonable want and a poor business case, and the same capacity spent on improving what you already run may return more. Our parent company has written on the same tension from the other side in client work and product work. If you are trying to choose a model this quarter, tell us how your weeks are made and which of the two you are least able to lose.