9.7 KiB
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.