# Productized Service

#concept #offer-design

## Summary

Selling a named, fixed-scope, fixed-price outcome delivered by a repeatable method — instead of selling your hours to be spent however the client directs. Nearly every source in this vault treats productization as the central move of a service business, and all frame the alternative (custom hourly work) as economically fatal. [[2026-06-15-17-ways-first-client]] (AB Analytics) calls it "the single biggest change to his client acquisition."

## Current Understanding

A productized service keeps the same underlying delivery work but changes what is *sold*: an outcome with a method behind it, rather than labor with a rate attached.

**Why the hourly model fails**, per the two sources' distinct arguments:

- *Margin argument:* ~90% of service businesses sell time; netted out per real hour, owners earn below minimum wage — "could make more cash working at McDonald's" ([[2026-07-17-design-the-perfect-offer]]).
- *Substitution argument:* the buyer now has a ~$200/mo AI alternative, so competing on rate zeroes the margin ([[2026-06-15-selling-development-services-in-the-ai-era]]). *(The substitute premise is now empirically contested — [[ai-productivity-evidence]] finds AI's measured effect modest and uneven; the margin argument above stands on its own regardless.)*

These are different arguments for the same conclusion, arrived at from different traditions — which is the main reason to hold this concept with confidence.

**When to productize.** The two sources answer differently and the difference is practical:

| Source | Trigger | Implied posture |
|---|---|---|
| [[2026-07-17-design-the-perfect-offer]] · [[2026-07-23-make-my-first-100k-in-month]] | Immediately — derive the offer from a revenue target and market conversations, sell it, *then* build delivery ("do the marketing before you build the thing") | Offer-first |
| [[2026-06-15-rodenko-selling-development-expensively]] · [[2026-06-15-17-ways-first-client]] | After **2–3 identical projects**, then fix price, fix scope, name the package | Delivery-first |

The delivery-first trigger is the more conservative and more defensible one, and it remains the majority *independent* view (Rodenko, AB Analytics, Tony all say productization *follows* niche/repetition): you can only fix a scope you have actually shipped repeatedly. The offer-first camp gained a second source on 2026-07-23 — [[dan-martell]]'s $100K blueprint, whose whole thesis is sequence (offer → demand → close → *only then* build), backed by his one before/after pair (product-first Maritime Vacation died; marketing-first Flowtown didn't) — but the 07-17 source is plausibly the same author (see [[dan-martell]]), so the camp may still be one voice. Reconciliation: *productize the offer early, productize the delivery contract only once the work repeats.* `Status: tentative` — this is synthesis, not a claim any source makes.

**The format triage** ([[2026-07-23-make-my-first-100k-in-month]]) — the sharpest statement of *why* productized service is the starting format: custom services sell hours (no leverage); products (apps, SaaS, courses) are expensive, slow, and risky to build first; a productized service prices like a product while needing nothing built — and **customer cash funds the eventual product**. The productized service is not the end state but the bridge to one.

**Pre-sell before building — now three traditions.** Martell's mechanic: landing page + waitlist before a line of code; offer a **$50 "top of the waitlist"** slot; money in = validated demand *plus* build capital, no money = don't build. This is the same discipline [[2026-06-15-making-money-with-ai-2026]] states from the RU side ("validate market and pain before writing code"; "most AI projects die from idea → code → launch") — with the useful addition that the validation signal is **paid**, not verbal. **Since 2026-07-26 a third tradition supplies the full toolkit:** [[oskar-hartmann]]'s "sell first, then build" ([[2026-07-26-main-principle-of-successful-business]]) — signal hierarchy (click < waitlist < payment < **pre-payment**), cheap-experiment menu (AI-mockup blast, payment-screen tests, Wizard-of-Oz manual delivery for the first 10 clients), and the sharpened bar: an *unpaid* waitlist doesn't count, which makes Martell's paid-slot variant the load-bearing detail. The discipline now has its own page — [[sell-before-build]].

**The leverage ladder** (DIY → DWY → DFY): Done-For-You is the highest-leverage rung — primary source [[2026-06-15-17-ways-first-client]] (echoed by the distillation). This is about *who does the work*; it is a different axis from the price ladder in [[offer-ladder]], which is about *how much is done*.

**Build fast, benefit first.** [[2026-06-15-making-money-with-ai-2026]]: MVP in **7–14 days**, usefulness over features, and templatize repeated solutions into a reusable "library." Validating market and pain *before* writing code is the whole discipline — "most AI projects die from idea → code → launch."

**The commodity test.** Remove the word "development" and your stack name from the offer. If nothing remains, you're a commodity — the category must be pain + result, not technology ([[2026-06-15-rodenko-selling-development-expensively]]). Tony's version: stop marketing the stack ("excellent .NET developer"), target the audience the stack implies ([[2026-06-15-more-clients-dev-agency]]).

**Team size is no longer the productization signal.** A productized shop can be small: a 4-person squad at ~$7M/yr ([[2026-06-15-rodenko-selling-development-expensively]]) or a solo founder at $293k/mo ([[2026-06-15-making-money-with-ai-2026]]) — see [[future-of-engineering-work]].

## Evidence

- "Productize — same delivery, but framed and sold as a specific outcome with a repeatable method" — [[2026-07-17-design-the-perfect-offer]]
- "~90% of service businesses get paid for time, not outcomes"; owners net below minimum wage — [[2026-07-17-design-the-perfect-offer]]
- "Hourly development is dead"; ~$200/mo AI alternative; commodity test; "category = pain + result"; productize after 2–3 identical projects — [[2026-06-15-rodenko-selling-development-expensively]]
- DIY → DWY → DFY as the leverage ladder and "single biggest change to client acquisition" — [[2026-06-15-17-ways-first-client]]
- Niche → productization → team scaling; don't market the stack — [[2026-06-15-more-clients-dev-agency]]
- Benefit before feature; MVP in 7–14 days; validate before coding; templatize into a library — [[2026-06-15-making-money-with-ai-2026]]
- Format triage (custom/product/productized), "customer cash funds the product," marketing-before-building, $50 paid-waitlist validation — [[2026-07-23-make-my-first-100k-in-month]] ([[dan-martell]])
- Condensed restatement of the above — [[2026-06-15-selling-development-services-in-the-ai-era]]

## Related Pages

- [[outcome-based-selling]] — what a productized offer sells
- [[sell-before-build]] — the validation discipline that precedes packaging (signal hierarchy, experiment toolkit)
- [[offer-ladder]] — how productized offers get tiered
- [[methodology-as-moat]] — why the repeatable method is the defensible part
- [[pricing-from-value]] — productization is what makes value pricing possible
- [[solution-vs-staff-augmentation]] — the model choice that productization commits you to
- [[future-of-engineering-work]] — why a productized shop can now be tiny
- [[ai-productivity-evidence]] — the empirical test of the substitution premise this page leans on
- [[overview]]

## Contradictions / Uncertainty

- **When to productize** is genuinely disputed (see table above): three delivery-first sources vs. two offer-first — but the two offer-first sources are possibly one author ([[dan-martell]]), so on independent voices it may still be 3:1. **Update (2026-07-26): the offer-first camp gains its first genuinely independent voice** — [[oskar-hartmann]]'s "sell first, then build" ([[sell-before-build]]) is offer-first stated as a categorical rule, from outside the Martell corpus. Careful with scope, though: Hartmann argues *demand must be proven by payment before building*, which the delivery-first camp doesn't deny — their claim is about when to **fix scope/price** on work you've shipped, not about building on spec. Read precisely, the camps may answer different questions (validate-before-*build* vs standardize-after-*repetition*), and both can hold at once — that reading would dissolve the dispute entirely, but it is the vault's synthesis, not any source's. On raw voices: now roughly 3 delivery-first vs 2–3 offer-first.
- The "90% / below minimum wage" claim is uncited and rhetorical in tone.
- **No source examines where hourly billing *works*.** Regulated/legacy/high-liability domains plausibly still command healthy hourly rates — and [[2026-07-06-sebastian-interview-ai-and-software-engineering]] notes COBOL/enterprise holdouts persist, a hint the vault otherwise lacks. Every productization source is advocacy from the same school. **Update (2026-07-18):** the vault now *has* an adversarial source ([[ai-productivity-evidence]]), but it contests the **AI-capability premise** this page leans on (the substitution argument), **not** the productization *model* — so a genuine productization-failure source is still the specific missing piece here.

## Next Questions

- What breaks first when you fix the scope of work that isn't actually repeatable yet?
- Does the ~$200/mo AI substitute really threaten mid/high-end dev contracts, or only the commodity floor?
- Is there a domain where the productized model is known to fail? The vault's first adversarial source ([[ai-productivity-evidence]]) tests the AI-capability premise but not the productization model itself — a productization-failure source remains the gap.