Operating Playbook

Commercial Productization.

Operating model for turning technical capability into packaged products, pricing, proof, POCs, and repeatable enterprise revenue.

The market does not buy capability. It buys a packaged path to a business outcome.
Evgeny Popov
Scope this playbook → Run the productization diagnostic
Fast read · Best for

Companies with strong capability but unclear product packaging, pricing, buyer narrative, POC path, or enterprise repeatability.

Evgeny Popov Evgeny Popov
playbook/commercial-productization Operating playbook
Not for
Teams looking for a superficial messaging refresh, a naming exercise, or a feature list cleanup.
Primary buyer
CEO, CRO, CPO, product marketing, GTM, partnerships, solutions, and revenue operations leaders.
Primary output
Offer architecture, package map, pricing logic, proof taxonomy, POC-to-production path, and sales-ready product narrative.
Main risk
Scaling sales before the product is commercially legible.
Best next step
Run the productization diagnostic or scope the operating model. →
Executive summary

Capability is not a commercial shape.

Commercial productization is the work of turning what a company can technically do into what a buyer can repeatedly buy. It connects product, GTM, pricing, proof, implementation, sales enablement, customer success, and expansion into one operating model.

Many companies have strong technology but weak commercial shape. They sell features, data, models, APIs, services, or bespoke workflows without a clear product frame. That creates long sales cycles, custom delivery, unclear pricing, weak proof, and POCs that never become production. Commercial productization turns capability into something the market can understand, buy, deploy, measure, and renew.

Plate 01 · Signature figure
Productization as a mint: raw capability struck into a commercial product A loose stack of raw blanks — feature, data asset, API, model, workflow, service, clean-room logic, AI agent, integration — waits beside a screw press, the productization system: buyer problem, offer architecture, packaging, pricing, proof, implementation, POC path, renewal logic. The product comes off as a true stack of milled coins: clear buyer, clear promise, clear SKU / package, clear value metric, clear proof, repeatable sales, production path, expansion path. A return chute underneath is the operating loop: sales feedback, usage data, proof, customer success, roadmap, pricing, renewal. Raw capability: feature Raw capability: data asset Raw capability: API Raw capability: model Raw capability: workflow Raw capability: service Raw capability: clean-room logic Raw capability: AI agent Raw capability: integration Raw capability Productization system: buyer problem, offer architecture, packaging, pricing, proof, implementation, POC path, renewal logic Productization system Commercial product: clear buyer Commercial product: clear promise Commercial product: clear SKU / package Commercial product: clear value metric Commercial product: clear proof Commercial product: repeatable sales Commercial product: production path Commercial product: expansion path Commercial product Operating loop: sales feedback → usage data → proof → customer success → roadmap → pricing → renewal Operating loop
Raw capability routed through a productization system into a commercial product, fed by an operating loop. Hover a block for detail.

This playbook is scoped to one capability — turning a single technical asset into one sellable, repeatable offer. Unifying several already-productized capabilities into one buyable story across a portfolio is a different job — see Commercial Architecture.

  • Start with the buyer problem, not the capability.
  • Decide whether the offer is a data product, software product, model product, workflow, API, service, native app, or outcome package.
  • Define the packaging before asking sales to scale it.
  • Build the POC-to-production path before running the POC.
  • Price against value, usage, outcome, or workflow ownership — not internal effort alone.
  • Create proof that the buyer committee can understand and reuse.
  • Separate what should be productized from what should remain bespoke.
A strong product is not just usable. It is explainable, buyable, deployable, measurable, and renewable.
Evgeny Popov
The operating system

The commercial productization system.

Productization is not a launch checklist. It is the operating system that connects buyer problem, product capability, package design, pricing logic, proof, sales motion, implementation, and renewal.

Commercial productization fails when sales is asked to scale a product the buyer cannot understand.

Plate 02 · The system
THE PRODUCTIZATION SYSTEM Buyer problem — answers: Why does this matter now, and who owns the budget? Breaks if missing: Sales chases interest, not buying intent. Ships: Buyer-problem brief. Buyer problem pain · urgency · budget owner · trigger · business outcome · decision committee Why does this matter now, and who owns the budget? Ships: Buyer-problem brief Capability — answers: What can we actually do that creates the outcome? Breaks if missing: The promise outruns what the product delivers. Ships: Capability map. Capability data · workflow · API · model · software · service · AI agent · clean-room logic What can we actually do that creates the outcome? Ships: Capability map Offer — answers: What is the buyable object, and where are its edges? Breaks if missing: Every deal is custom; nothing repeats. Ships: Offer architecture. Offer product · package · tier · module · use case · SKU · private offer · native app What is the buyable object, and where are its edges? Ships: Offer architecture Commercial — answers: How does the buyer justify it, and does the margin hold? Breaks if missing: Pricing follows internal effort, not value. Ships: Pricing + value-metric model. Commercial pricing · value metric · ACV · margin · term · usage · implementation fee How does the buyer justify it, and does the margin hold? Ships: Pricing + value-metric model Proof — answers: What evidence does each buyer need to believe it? Breaks if missing: The committee stalls on credibility. Ships: Proof taxonomy. Proof case pattern · benchmark · pilot metric · ROI model · incrementality · adoption proof What evidence does each buyer need to believe it? Ships: Proof taxonomy Delivery — answers: How does the buyer go live without solutions doing it by hand? Breaks if missing: Solutions becomes the product. Ships: Implementation blueprint. Delivery onboarding · integration · support · solutions · CS · documentation · training How does the buyer go live without solutions doing it by hand? Ships: Implementation blueprint Expansion — answers: How does the promise renew and grow? Breaks if missing: You win logos but lose them at renewal. Ships: Renewal + expansion path. Expansion renewal · upsell · cross-sell · marketplace · partner channel · enterprise standard How does the promise renew and grow? Ships: Renewal + expansion path Each layer answers a question · breaks the model if missing · ships an artifact.
  1. Buyer problem pain · urgency · budget owner · trigger · business outcome · decision committee Answers: Why does this matter now, and who owns the budget? Ships: Buyer-problem brief
  2. Capability data · workflow · API · model · software · service · AI agent · clean-room logic Answers: What can we actually do that creates the outcome? Ships: Capability map
  3. Offer product · package · tier · module · use case · SKU · private offer · native app Answers: What is the buyable object, and where are its edges? Ships: Offer architecture
  4. Commercial pricing · value metric · ACV · margin · term · usage · implementation fee Answers: How does the buyer justify it, and does the margin hold? Ships: Pricing + value-metric model
  5. Proof case pattern · benchmark · pilot metric · ROI model · incrementality · adoption proof Answers: What evidence does each buyer need to believe it? Ships: Proof taxonomy
  6. Delivery onboarding · integration · support · solutions · CS · documentation · training Answers: How does the buyer go live without solutions doing it by hand? Ships: Implementation blueprint
  7. Expansion renewal · upsell · cross-sell · marketplace · partner channel · enterprise standard Answers: How does the promise renew and grow? Ships: Renewal + expansion path
Commercial productization fails when sales is asked to scale a product the buyer cannot understand.
The failure modes

Why capabilities fail to become products.

Most companies do not lack capability. They lack commercial shape.

  • The buyer problem is too broad

    When the product solves "everything," no buyer can connect it to a budget, a trigger, or an owned outcome — so the sale has no center of gravity.

  • The offer is not packaged

    Without a buyable object — a SKU, tier, module, or package — every deal is scoped from scratch and nothing repeats.

  • Pricing follows effort, not value

    When price reflects internal cost and hours instead of buyer value, deals stall in procurement and margin erodes deal by deal.

  • Every POC is bespoke

    A custom pilot proves a custom result. If production is not designed before the pilot, a good readout still has nowhere to go.

  • Proof is trapped in delivery

    The evidence lives inside one delivery team’s heads and artifacts, so it cannot be reused to win the next, harder buyer.

  • Product marketing describes features

    Feature lists describe what the product has, not what the buyer gets. The committee cannot translate features into their own risk and value.

  • Solutions becomes the product

    When the only way to deploy is hand-built solutions work, the company has a services business wearing a product label.

  • Customer success cannot renew the promise

    If the value that was sold was never made measurable, CS has nothing concrete to renew or expand against.

The product is not productized until sales can explain it, solutions can deploy it, the buyer can measure it, and customer success can renew it.

The first decision

The productization ladder.

Not every capability should become a product in the same way. The first decision is what kind of commercial object you are building.

Plate 03 · The ladder
THE PRODUCTIZATION LADDER Repeatability increases ↑ Capability — rung 1 of 7. Higher rungs repeat more and require less custom work per deal. Capability Use case — rung 2 of 7. Higher rungs repeat more and require less custom work per deal. Use case Package — rung 3 of 7. Higher rungs repeat more and require less custom work per deal. Package Product — rung 4 of 7. Higher rungs repeat more and require less custom work per deal. Product Platform module — rung 5 of 7. Higher rungs repeat more and require less custom work per deal. Platformmodule Marketplace / API — rung 6 of 7. Higher rungs repeat more and require less custom work per deal. Marketplace/ API Enterprise standard — rung 7 of 7. Higher rungs repeat more and require less custom work per deal. Enterprisestandard Custom work decreases → The first decision is what kind of commercial object you are building.

  1. Capability

    A raw technical ability — a model, dataset, workflow, API, or service skill — not yet shaped for a buyer.

    RiskSold as potential; the buyer has to do the productization in their own head.

  2. Use case

    The capability aimed at one named buyer problem with a clear before/after.

    RiskOne use case can be too narrow to anchor a repeatable offer or pricing.

  3. Package

    A scoped, named bundle with a boundary, a price logic, and a defined buyer.

    RiskPackaging too early can freeze the wrong scope before the value metric is known.

  4. Product

    A repeatable, supported offer with promise, proof, implementation, and renewal.

    RiskProductizing the wrong thing locks engineering and GTM into a low-leverage path.

  5. Platform module

    A product that plugs into a broader platform and composes with other modules.

    RiskModule sprawl and unclear boundaries make the platform harder to buy, not easier.

  6. Marketplace / native app / API

    A self-describing object a buyer can discover, procure, and deploy through a marketplace, native app, or API.

    RiskListing before the offer is legible exposes a weak product to a high-visibility surface.

  7. Enterprise standard

    A product the buyer adopts as a default standard across teams or the organization.

    RiskBecoming a standard raises the bar on support, security, and roadmap commitments.

The canvas

Offer architecture.

Offer architecture defines what is sold, who it is for, how it is scoped, what the buyer receives, what the seller commits to, and how the value is measured.

Plate 04 · Offer architecture canvas
OFFER ARCHITECTURE CANVAS Buyer — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 01 Buyer Trigger — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 02 Trigger Business outcome — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 03 Business outcome Use case — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 04 Use case Inputs — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 05 Inputs Product promise — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 06 Product promise Package boundary — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 07 Package boundary Value metric — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 08 Value metric Proof — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 09 Proof Implementation — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 10 Implementation Success metric — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 11 Success metric Expansion path — a field on the offer architecture canvas. Fill it before you ask sales to scale the offer. 12 Expansion path Buyer → trigger → outcome → package → proof → production → expansion One canvas defines what is sold, to whom, how it is scoped, and how value is measured.
Buyer
Who specifically buys this, and who owns the budget?
Trigger
What event makes them act now instead of later?
Business outcome
What measurable business result are they paying for?
Use case
What is the concrete job the product does?
Inputs
What capability, data, or access does it require?
Product promise
What does the seller commit the buyer will get?
Package boundary
What is in scope — and explicitly out of scope?
Value metric
What unit scales with the value the buyer receives?
Proof
What evidence makes the committee believe it?
Implementation
How does the buyer go live without bespoke heroics?
Success metric
How will the buyer know it worked?
Expansion path
How does it renew, grow, or spread from here?
Packaging + pricing

Packaging and pricing.

Packaging decides what the buyer can understand. Pricing decides what the buyer can justify.

Packaging choices

  • Starter / pilot package
  • Use-case package
  • Platform module
  • Enterprise tier
  • Private offer
  • Marketplace listing
  • API / usage package
  • Managed workflow
  • Outcome-linked package

Pricing models

  • Subscription
  • Usage-based
  • Data volume
  • Seats
  • Workflow volume
  • API calls
  • Media / spend-linked
  • Implementation fee
  • Performance / outcome-linked
  • Hybrid
Plate 05 · Pricing and the value metric
PRICING + VALUE METRIC MAP Buyer value — the outcome the buyer is paying to reach. Buyer value
the outcome the buyer is paying to reach
 Value metric — the unit that scales with that value. Value metric
the unit that scales with that value
 Pricing model — how the metric becomes a price. Pricing model
how the metric becomes a price
 Renewal proof — evidence the value recurred. Renewal proof
evidence the value recurred
 Renewal proof feeds the next value-metric decision Packaging decides what the buyer can understand. Pricing decides what they can justify.
Pricing models
Pricing modelBest whenWatch-out
SubscriptionPredictable, recurring value the buyer consumes steadily.Can decouple price from realized value if usage swings.
Usage-basedValue scales with consumption and usage is easy to meter.Hard to forecast for the buyer; can punish adoption.
Spend-linkedThe product sits on top of media or platform spend.Ties your revenue to the buyer’s budget cycles and cuts.
Implementation feeMeaningful onboarding or integration creates real upfront work.Can read as a services bill and stall the recurring deal.
Outcome-linkedThe outcome is attributable and both sides trust the measurement.Attribution disputes and long proof windows slow cash. Selecting this model is where this playbook stops and Outcome Underwriting starts.
HybridA platform fee plus usage or outcome matches mixed value.Complexity can make the offer hard to explain and compare.
Show all 6 rowsShow fewer rows
Worked example · the P&L bridge

From bespoke delivery to a productized offer.

Productization is a margin-structure decision before it is a packaging one. The same capability, sold two ways, produces two different P&Ls. The bridge below walks one capability from services-heavy bespoke delivery to a repeatable productized offer — holding revenue constant to isolate what actually changes: the cost structure.

Show this sectionHide this section

Illustrative Your numbers will differ. The point is the method, not the figures — every value is explicit, every formula is shown, and the arithmetic is exact.

1 · The gross-margin lift

Bespoke · services economics
  1. Bespoke revenue$1.20MOne capability, services-heavy, long cycle.
  2. − Bespoke COGS−$0.78MDelivery + solutions + bespoke integration — every deal scoped from scratch.
  3. = Bespoke gross profit$0.42M
  4. Gross margin = (Rev − COGS) ÷ Rev = 0.42 ÷ 1.2035%Services economics — capped by headcount.
Productized · software-style
  1. Productized revenue$1.20MSame capability, repeatable, shorter cycle — held constant to isolate the margin structure.
  2. − Productized COGS−$0.26MHosting + support + light onboarding — cost no longer scales 1:1 with each deal.
  3. = Productized gross profit$0.94M
  4. Gross margin = 0.94 ÷ 1.2078%Same capability. Different cost structure.
  1. = Annual gross-margin lift = $0.94M − $0.42M+$0.52M+43 margin points on the same top line.
2 · The investment and the break-even
  1. Productization investment — engineering (one-time)$0.48MPackage the capability, harden it, instrument it.
  2. + Productization investment — GTM (one-time)$0.12MOffer architecture, pricing, proof, enablement.
  3. = Total one-time productization investment$0.60M
  4. Monthly margin delta = annual lift ÷ 12 = $0.52M ÷ 12$43K / mo
  5. Break-even = investment ÷ monthly margin delta = $0.60M ÷ $43K≈ 14 moMonths to recoup the build from the margin structure alone.
  6. Rule of 40 = revenue growth % + contribution margin %risesBespoke 22% growth + 12% margin = 34 (below 40). Productized 22% + 30% = 52.

Productization is a margin-structure decision, not a packaging exercise. The capability did not change — the cost of delivering it did, and that delta funds the build in about a year and lifts the company over the Rule of 40.

If the margin delta does not pay back the productization investment in a defensible window, the capability is a candidate to keep bespoke — not to productize.

Conversion path

The POC-to-production path.

A POC is not a science project. It is a commercial conversion path. If production is not designed before the pilot starts, the POC will often die after a successful readout.

The POC is only successful if the buyer knows what production looks like before the pilot ends.

Plate 06 · POC to production
POC → PRODUCTION PATH Pilot — scoped test with a production hypothesis. 1 Pilot
scoped test with a production hypothesis
 Proof — the metric that earns the conversion. 2 Proof
the metric that earns the conversion
 Production — designed before the pilot starts. 3 Production
designed before the pilot starts
 Renewal — the value recurs and is measured. 4 Renewal
the value recurs and is measured
 Expansion — next use case, team, or account. 5 Expansion
next use case, team, or account
 A POC is not a science project. It is a commercial conversion path.
  1. 01

    Qualify

    • Named buyer problem and budget owner
    • Production hypothesis stated up front
    • Success criteria the buyer agrees to
  2. 02

    Scope

    • Pilot boundary and timeline
    • Data, access, and integration requirements
    • What production looks like if the pilot works
  3. 03

    Prove

    • The metric that earns the conversion
    • A readout the committee can reuse
    • Proof captured outside one delivery person’s head
  4. 04

    Convert

    • Commercial terms tied to the proven value
    • A defined path from pilot to contract
    • Internal sponsor armed to sell up
  5. 05

    Operationalize

    • Implementation and onboarding plan
    • Support, documentation, and ownership defined
    • Success metric instrumented for renewal
  6. 06

    Expand

    • Next use case, team, or account identified
    • Renewal and expansion logic in place
    • Reference and proof pattern reusable
Evidence

Proof taxonomy.

Different buyers believe different proof. A technical user, economic buyer, procurement lead, and executive sponsor do not need the same evidence.

Plate 07 · Proof taxonomy
PROOF TAXONOMY Expansion proof — for the partner / GM. Proves: it grows beyond the first deal. Expansion Proves: it grows beyond the first deal partner / GM Risk proof — for the legal · security · procurement. Proves: it is safe to deploy. Risk Proves: it is safe to deploy legal · security · procurement Adoption proof — for the operator / champion. Proves: people actually use it. Adoption Proves: people actually use it operator / champion Commercial proof — for the economic buyer. Proves: the economics work. Commercial Proves: the economics work economic buyer Operational proof — for the solutions / ops. Proves: it runs in their environment. Operational Proves: it runs in their environment solutions / ops Technical proof — for the technical buyer. Proves: it works as claimed. Technical Proves: it works as claimed technical buyer A technical user and an executive sponsor do not need the same evidence.
Proof taxonomy
Proof typeWhat it provesBest forWeak versionStrong version
TechnicalIt works as claimed.Technical buyerA demo on ideal data.A test in the buyer’s environment with their constraints.
OperationalIt runs in their operation.Solutions / opsA diagram of how it would integrate.A working integration with real workflow and SLAs.
CommercialThe economics work.Economic buyerA generic ROI slide.An ROI model built on the buyer’s own numbers.
AdoptionPeople actually use it.Operator / championA login count.Active usage tied to the workflow it was bought for.
RiskIt is safe to deploy.Legal / security / procurement"Trust us, we’re compliant."Documented controls, security review, and references.
ExpansionIt grows beyond the first deal.Partner / GMA hopeful roadmap.A second team or use case already live.
Show all 6 rowsShow fewer rows
The committee

Buyer committee and sales narrative.

Commercial productization only works when every buyer in the committee understands the product through their own risk and value lens.

Plate 08 · The buyer committee
BUYER COMMITTEE + NARRATIVE One product narrative — problem, stakes, product, proof, path — translated into each buyer's lens. One product narrative six lenses Economic buyer — reads the narrative through: ROI · payback. Economic buyer ROI · payback Technical buyer — reads the narrative through: fit · integration. Technical buyer fit · integration Operator — reads the narrative through: workflow · adoption. Operator workflow · adoption Legal / security — reads the narrative through: risk · compliance. Legal / security risk · compliance Procurement — reads the narrative through: terms · price. Procurement terms · price Executive sponsor — reads the narrative through: strategy · outcome. Executive sponsor strategy · outcome Narrative spine: problem · stakes · product · proof · path.

  • Economic buyer

    Cares aboutROI, payback, margin, risk to the number.

    NeedsA business case in their own numbers.

  • Technical buyer

    Cares aboutFit, integration, security, control.

    NeedsEvidence it works in their environment.

  • Operator / workflow owner

    Cares aboutAdoption, effort, day-to-day workflow.

    NeedsProof their team will actually use it.

  • Legal / privacy / security

    Cares aboutCompliance, data handling, exposure.

    NeedsDocumented controls and a clean review.

  • Procurement

    Cares aboutTerms, price, comparability, leverage.

    NeedsA package they can compare and negotiate.

  • Executive sponsor

    Cares aboutStrategy, outcome, organizational risk.

    NeedsA narrative that ties to a priority they own.

Sales narrative spine

Problem
What is broken, for whom, and why now?
Stakes
What does it cost to leave it unsolved?
Product
What is the packaged path to the outcome?
Proof
Why should each buyer believe it?
Path
How do they buy, deploy, measure, and expand?
Access + deploy

Distribution path is part of productization.

A product is not fully productized until the buyer knows how to access, deploy, procure, and expand it.

Plate 09 · Distribution paths
DISTRIBUTION PATHS Product package — the productized object that must reach the buyer through a path they can access, deploy, and procure. Product package Direct enterprise sale — one route to the buyer, each with its own required artifact and risk. Direct enterprise sale Marketplace listing — one route to the buyer, each with its own required artifact and risk. Marketplace listing Private offer — one route to the buyer, each with its own required artifact and risk. Private offer Native app — one route to the buyer, each with its own required artifact and risk. Native app API product — one route to the buyer, each with its own required artifact and risk. API product Partner / channel package — one route to the buyer, each with its own required artifact and risk. Partner / channel package Managed workflow — one route to the buyer, each with its own required artifact and risk. Managed workflow Distribution path is part of productization, not an afterthought.
Show this sectionHide this section

  • Direct enterprise sale

    Best whenHigh ACV, committee buying, custom security and terms.

    Watch-outLong cycles; demands real sales and solutions capacity.

  • Marketplace listing

    Best whenBuyers procure through a cloud or platform marketplace.

    Watch-outListing exposes a weak offer; take rates and rules apply.

  • Private offer

    Best whenNegotiated terms through a marketplace for a known buyer.

    Watch-outStill needs a legible package behind the custom terms.

  • Native app

    Best whenThe buyer wants the product inside a platform they already use.

    Watch-outPlatform constraints and review cycles shape the roadmap.

  • API product

    Best whenDevelopers integrate the capability directly.

    Watch-outRequires docs, support, and pricing for programmatic use.

  • Partner / channel package

    Best whenA partner resells or embeds the product.

    Watch-outMargin sharing and enablement can dilute control.

  • Managed workflow

    Best whenThe buyer wants the outcome run for them.

    Watch-outDrifts back toward services if not productized tightly.

Distribution paths
Distribution pathBest fitRequired artifactRisk
Direct enterprise saleHigh-ACV, committee dealsOffer architecture + proof taxonomyCost and length of the motion
Marketplace listingCloud / platform procurementListing-ready package + pricingExposing an illegible offer
Private offerNegotiated marketplace dealsPackage + custom terms templateCustom terms hiding a weak product
Native appIn-platform deploymentApp package + platform fitPlatform roadmap dependency
API productDeveloper integrationAPI docs + usage pricingSupport and reliability burden
Partner / channel packageResell or embedPartner package + enablementMargin and control dilution
Managed workflowOutcome run for the buyerWorkflow SLA + scope boundaryReverting to services
Show all 7 rowsShow fewer rows
The operating question

What should be productized — and what should stay bespoke.

Not every custom request should become product. Not every bespoke delivery is bad. The operating question is whether the work repeats, creates strategic value, and can be delivered without breaking the model.

Plate 10 · Bespoke or productized
BESPOKE → PRODUCT DECISION Bespoke request — a custom ask that may or may not deserve to become product. Bespoke request Evaluate — frequency · margin · strategic value · buyer urgency · implementation complexity · data dependency · roadmap fit · repeatability · proof value · expansion value. Evaluate 10 criteria Productize — repeats · margin · strategic · scalable. Productize repeats · margin · strategic · scalable Package as service — valuable but not yet product-shaped. Package as service valuable but not yet product-shaped Keep bespoke — high value, low repeat, strategic account. Keep bespoke high value, low repeat, strategic account Reject — one-off · low margin · breaks the model. Reject one-off · low margin · breaks the model Not every custom request should become product. Not every bespoke delivery is bad.
Show this sectionHide this section
Productize when
it repeats, carries margin, is strategic, and can be delivered without breaking the model.
Package as service when
it is valuable and repeatable but not yet product-shaped, or needs heavy but standardizable delivery.
Keep bespoke when
it is high value, low frequency, and tied to a strategic account worth the custom effort.
Reject when
it is a one-off, low-margin, off-roadmap, and would break the operating model to deliver.
Bespoke vs productized decision matrix
CriterionProductizePackage as serviceKeep bespokeReject
FrequencyRepeats oftenRepeats sometimesRareOne-off
MarginStrong, scalableAcceptable with effortHigh but labor-boundThin or negative
Strategic valueCore to the thesisAdjacentKey account onlyNone
Buyer urgencyBroad, pressingReal but narrowAccount-specificLow
Implementation complexityStandardizableHeavy but repeatableHigh, customUnbounded
Data / integration dependencyManageableSignificantDeep, bespokeBlocking
Roadmap fitOn the lineNear itOff itAgainst it
RepeatabilityHighMediumLowNone
Proof valueCreates reusable proofSome proofAccount proof onlyNo proof
Expansion valueOpens expansionLimitedAccount-boundDead end
Show all 10 rowsShow fewer rows
Deliverables

What ships.

The work is not a workshop. The work is a commercial productization system a team can use.

  1. 01
    Productization diagnosis

    Where the company is on the ladder and what is blocking repeatability.

    Used byCEO / CPO / CRO

  2. 02
    Offer architecture canvas

    The 12-field definition of what is sold, to whom, and how value is measured.

    Used byProduct / GTM

  3. 03
    Packaging and tiering model

    The package map, boundaries, and tier logic.

    Used byProduct marketing / GTM

  4. 04
    Pricing and value metric map

    The value metric and the pricing model that scales with it.

    Used byCRO / Finance

  5. 05
    POC-to-production blueprint

    The six-step path that converts pilots into production.

    Used bySales / Solutions

Show all 10
  1. 06
    Proof taxonomy

    Proof by buyer type, with weak-vs-strong versions.

    Used bySales / CS / Product marketing

  2. 07
    Buyer committee narrative

    One narrative translated into six buyer lenses.

    Used bySales / Product marketing

  3. 08
    Distribution path recommendation

    Which paths fit, the artifacts they need, and their risks.

    Used byGTM / Partnerships

  4. 09
    Bespoke vs productized decision model

    The rule for what becomes product, service, bespoke, or reject.

    Used byExec / Product / Sales

  5. 10
    30/60/90 productization plan

    The diagnose-design-launch-scale operating plan.

    Used byExec / CRO / Founder

Each artifact is part of the broader Artifact Library — the canvases, taxonomies, and operating models this playbook produces.

The motion

30/60/90 operating plan.

Diagnose, design, launch, then scale — concrete outputs by phase, not a vague roadmap.

  1. 30

    Diagnose

    • Buyer problem and trigger
    • Capability and ladder position
    • Current packaging and pricing audit
    • Bespoke-vs-product audit
    • Proof inventory
  2. 60

    Design

    • Offer architecture canvas
    • Package and tier map
    • Pricing and value metric
    • Proof taxonomy
    • POC-to-production blueprint
    • Buyer committee narrative
  3. 90

    Launch

    • Sales-ready narrative and enablement
    • First packaged deals or pilots
    • Distribution path decision
    • Proof captured and reusable
  4. Beyond

    Scale

    • Distribution and marketplace paths
    • Renewal and expansion motion
    • Enterprise standard positioning
    • Repeatable revenue engine
Show the plan as a diagram
Plate 11 · 30/60/90 operating plan
30 / 60 / 90 OPERATING PLAN 30 days — Diagnose: buyer problem · capability · bespoke audit. 30 days 1 Diagnose
buyer problem · capability · bespoke audit
 60 days — Design: offer · packaging · pricing · proof · POC path. 60 days 2 Design
offer · packaging · pricing · proof · POC path
 90 days — Launch: narrative · enablement · first packaged deals. 90 days 3 Launch
narrative · enablement · first packaged deals
 Beyond — Scale: distribution · renewal · expansion · standard. Beyond 4 Scale
distribution · renewal · expansion · standard
 The work is a commercial productization system a team can use — not a workshop.
Diagnostic

Is your product commercially ready?

Eight questions. The result surfaces your biggest gap first — what to fix, the artifacts that fix it, and where to go next.

Run the 8-question diagnostic Hide the diagnostic
01 Can you state the buyer problem in one sentence — pain, urgency, and budget owner?
02 Is the offer packaged into a buyable object (SKU, tier, module, package)?
03 Does pricing follow a value metric the buyer can justify — not internal effort?
04 Is the path from POC to production designed before the pilot starts?
05 Can the buyer committee get proof in the form each member believes?
06 Can sales explain the product without solutions or founders in the room?
07 Have you decided what should be productized vs. stay bespoke?
08 Does the product renew and expand on a clear path?
Where to go next

Where this connects.

Market references last validated: June 7, 2026. Revalidate before pitch use.

On the operator’s shelf285 books
Cover of Zero to One by Peter Thiel
Cover of The Sales Acceleration Formula by Mark Roberge
Cover of Influence by Robert B Cialdini PhD
  • Zero to One · Peter Thiel
  • The Sales Acceleration Formula · Mark Roberge
  • Influence · Robert B Cialdini PhD
Next step

Ready to turn capability into a product the market can buy?

The playbook maps the buyer problem, offer architecture, package, pricing logic, proof, POC path, and operating model needed to move from custom selling to repeatable enterprise revenue.

Scope this playbook → Run the productization diagnostic See related operating playbooks