Scale the delivery system.
Keep the output true.
Capacity is a planning problem before it is a hiring problem. Map demand, productive hours, skills, handoffs, quality evidence, and contribution before adding more people to a workflow that cannot yet teach the work.
Four checkpoints from pressure to productization.
Select a checkpoint to inspect the operating intervention. The sequence is illustrative; your thresholds depend on work mix, ramp time, contribution, and the cost of a failed promise.
Prove the workload is real
Separate signed work, probability-weighted demand, recurring patterns, and pipeline optimism. Then locate whether the constraint is volume, skill, scheduling, rework, or a broken sequence.
forecast → bottleneck → demand qualityModel the constraint before you add the component.
A delivery organization fails at the interfaces: a sales promise without a capacity check, a handoff without acceptance criteria, a new hire without standard work, or a packaged offer that hides expensive exceptions.
Demand ledger
Record each work unit with customer, service type, required window, probability, skill, dependency, expected effort, contribution, and consequence of delay. Do not let a high-volume pipeline masquerade as a committed schedule.
Control output: a planning view that distinguishes contractual commitments from probability-weighted opportunities and recurring seasonal patterns. The question is not “How much could we sell?” It is “What must be delivered, when, by whom, and at what economics?”
Productive capacity model
Start with available hours, then remove management, selling, coordination, training, leave, support, review, and expected rework. Model capacity by skill and time window; total hours cannot substitute for the scarce capability that unlocks the job.
Control output: required hours plus a quality-preserving buffer compared with productive hours available after non-delivery work. Test a sequence change or flexible capacity option before committing to fixed cost when demand is uncertain.
Executable standard work
Define trigger, inputs, ordered steps, decisions, owner, acceptance criteria, evidence, and exception path. Attach the document to the job rather than storing it as a forgotten manual. Use examples when quality is hard to describe with words alone.
Control output: fewer avoidable questions, less founder translation, faster time-to-competence, and a defect log that improves the process instead of blaming the operator.
Productized core
Package the stable part of the service: common inputs, recurring sequence, predictable output, visible status, acceptance standard, and declared exceptions. Preserve human judgment where it creates value rather than forcing all cases into a brittle template.
Control output: clearer sales promises, easier onboarding, more predictable staffing, and better unit economics. Productization is a boundary around repeatability, not a denial that customers vary.
Use gates, not feelings, to decide when to hire.
A hiring decision should be traceable to demand quality, productive capacity, ramp time, contribution, and the cost of waiting. A full calendar is a signal to investigate; it is not the conclusion.
| Signal | Record | Decision implication |
|---|---|---|
| Demand certainty | Signed work, weighted pipeline, seasonality, forecast error | Choose fixed capacity only when the gap is durable enough. |
| Skill constraint | Hours by skill, queue age, dependency, approval latency | Target the bottleneck instead of adding general headcount. |
| Ramp economics | Recruiting time, training hours, time-to-competence, loaded cost | Hire early enough for ramp, but only with a credible contribution path. |
| Quality load | Rework, defects, escalations, late work, customer outcomes | Do not add people to a broken sequence without fixing the control. |
| Repeatability | Common inputs, delivery variance, exception frequency, margin by type | Consider packaging the stable core when variation is bounded. |
Then test whether the gap is caused by demand, skill, sequence, scope, or waste. The formula is a diagnostic starting point, not permission to assume every available hour can become customer-facing output.
What must be true before the next scaling move?
What is the best hiring trigger?
A recurring, economically healthy demand gap that remains after sequencing and process waste are addressed, with a role-specific bottleneck, a realistic ramp plan, and a workflow that can protect quality. If demand is uncertain, use a reversible capacity option first.
How much documentation is enough?
Enough for a trained operator to identify the trigger, gather inputs, make the next decision, meet the acceptance standard, record evidence, and escalate exceptions. Length is not the standard; executable behavior is.
Why does quality fall after hiring?
Because the organization added people faster than it added shared definitions of good work. The new operator receives an outcome expectation but no inputs, sequence, review rubric, or exception path. The result is more throughput at the front and more rework at the back.
When should a service become a product?
When the problem, inputs, sequence, output, timing, and acceptance criteria recur with enough consistency to define a bounded offer. Keep valuable judgment and unusual cases visible instead of hiding them inside the base promise.
What if the customer pipeline is growing faster than delivery?
Protect the promise with a cap, a later start date, narrower scope, higher price, flexible capacity, or a deliberate partner layer. Revenue that creates missed outcomes and remediation can destroy more margin than a delayed sale.
Which metric is most important?
No single metric is sufficient. Pair committed demand with productive capacity, utilization with quality, output with contribution, and hiring progress with customer outcomes. The correct dashboard exposes tradeoffs instead of celebrating one number.
Do not scale a mystery.
Make the demand visible, the bottleneck specific, the workflow teachable, and the repeatable core bounded before you turn growth into fixed capacity.
RUN THE CAPACITY TRACE