Files
BusinessNotes/wiki/concepts/productized-service.md
EugeneTes 60176d2fdc all
2026-07-30 11:15:52 +02:00

75 lines
9.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 **23 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 **714 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 23 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 714 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 23 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.