Productised-services delivery quality at scale

The productised-services growth curve has a predictable inflection at customer 50-80, where the founder stops being able to personally touch every delivery. If quality stays high through this transition, the business compounds; if quality drops, the brand erodes and acquisition costs to replace churning customers go up. Here's the operational shape that holds quality through the inflection.

The three failure modes during the transition

1. Quality drift. New team members deliver work that's technically correct but not in the brand's voice / depth / specificity. Customers notice; refunds rise.

2. Founder bottleneck. Founder still reviews every deliverable. Throughput caps at founder's hours; team grows but velocity doesn't.

3. Variable customer experience. Customer A's engagement is great because they got the senior person; Customer B's is mediocre. Word-of-mouth becomes inconsistent.

Each requires different controls.

The SOP that holds quality

1. A delivery playbook. Every productised offer has a documented step-by-step playbook: research phase (X hours, deliverable Y), production phase (X hours, deliverable Y), review phase (X hours, deliverable Y). New team members follow it for their first 5 engagements.

2. Template assets that ship 60-80% of every deliverable. Email scripts, slide layouts, code modules, design templates. The team isn't starting from a blank canvas; they're customising templated work.

3. A QA gate before every delivery. Senior team member reviews each engagement's deliverable before client sight. This is the founder's role at scale: not delivering work, but reviewing it.

4. Customer feedback captured systematically. Every engagement closes with a structured feedback form. The aggregate data tells you where playbook gaps exist.

5. A monthly playbook refresh. As the team learns, the playbook gets better. The team member who shipped the last 5 engagements knows things the playbook doesn't. Their tacit knowledge gets converted to explicit playbook content.

The role transitions at each stage

Founder + 1: founder delivers most; new hire shadows for first 3-5 engagements, then takes on the 80% repeatable work. Founder reviews everything.

Founder + 2-3: founder delivers 20-30% (the harder / strategic engagements); team delivers 70-80%. Founder still reviews everything but selectively (sample 50% of deliverables, focus on first engagement per new client).

Founder + 4-5: founder doesn't deliver, only reviews. A delivery lead emerges from the team — most-experienced contributor takes responsibility for quality, founder does final sign-off on customer-facing materials.

The transition between each stage is the dangerous moment. Founders who don't promote the delivery lead by team-of-4 end up as the bottleneck and the team plateaus.

The QA pattern that actually works

For each engagement, a two-tier review:

• Producer review (the team member who built it): self-checks against playbook + checklist.
• QA review (founder or delivery lead): independent sample-check of finalised deliverable. Catches voice / depth / accuracy issues the producer missed.

QA review takes 20-30% of the engagement's production time. Founders try to skip it; that's how quality drifts.

The QA reviewer's job is not to perfect the deliverable; it's to identify what to fix and route the work back. Don't fix it for the producer — that prevents the producer from learning.

What kills quality at scale

• Hiring fast without playbook discipline. New team members produce work that drifts from brand voice. The playbook gap shows up as customer complaints 4-6 weeks later.
• Skipping QA to ship faster. Speed kills quality kills retention. A 15% delivery-time increase from QA gates produces 30%+ better customer outcomes.
• Letting clients dictate scope mid-engagement. Every "can you also do this?" without a Change Request degrades the productised shape. Hold the line.
• Different team members using different tools. Standardise on one stack for each engagement type. Five team members each in their preferred CMS is unmaintainable.

What to instrument

• Deliverable rejection / revision rate. What % of deliverables come back for changes after QA? Above 25% means your playbook is broken; below 5% means QA isn't catching enough.
• Customer-reported quality issues per engagement. Track per team member. Outliers identify training needs.
• Time-to-delivery vs scoped time. Engagements consistently going long mean scope is too vague or the playbook is missing steps.
• NPS at engagement close. Per team member. The data is noisy but trends are real.

What to do today

1. Audit your current playbook. Is it written down, or in the founder's head? If the latter, your team-of-3 problem is approaching.
2. Pick one productised offer and write the full delivery playbook this month. 8-12 hours of focused work.
3. Add a QA gate. If you don't have one, you're shipping inconsistent work.
4. Identify your future delivery lead from the current team. Start handing them more review responsibility now, before you need them at team-of-4.