Operating Playbook

Commercial Productization.

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

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.

The market does not buy capability. It buys a packaged path to a business outcome.

COMMERCIAL PRODUCTIZATION Raw capability — the technical assets a company can do: features, data, APIs, models, workflows, services, clean-room logic, AI agents, integrations. RAW CAPABILITY featuredata assetAPImodelworkflowserviceclean-room logicAI agentintegration Productization system — the operating layer that turns capability into something buyable: buyer problem, offer architecture, packaging, pricing, proof, implementation, POC path, renewal logic. PRODUCTIZATION SYSTEM buyer problem offer architecture packaging pricing proof implementation POC path renewal logic Commercial product — what the market can understand and buy: a clear buyer, promise, SKU, value metric, proof, repeatable sales motion, production path, and expansion path. COMMERCIAL PRODUCT clear buyerclear promiseclear SKU / packageclear value metricclear proofrepeatable salesproduction pathexpansion path OPERATING LOOP sales feedback → usage data → proof → customer success → roadmap → pricing → renewal ↺ The market does not buy capability. It buys a packaged path to a business outcome.
Raw capability routed through a productization system into a commercial product, fed by an operating loop. Hover a block for detail.
Scope this playbook → Run the productization diagnostic → See the operating model →
Executive summary

Capability is not a commercial shape.

Fast read
Best for
Companies with strong capability but unclear product packaging, pricing, buyer narrative, POC path, or enterprise repeatability.
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.

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.

  • 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."

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.

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.

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.

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. 01

    Capability

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

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

  2. 02

    Use case

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

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

  3. 03

    Package

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

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

  4. 04

    Product

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

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

  5. 05

    Platform module

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

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

  6. 06

    Marketplace / native app / API

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

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

  7. 07

    Enterprise standard

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

    Risk Becoming 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.

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.
01Buyer
Who specifically buys this, and who owns the budget?
02Trigger
What event makes them act now instead of later?
03Business outcome
What measurable business result are they paying for?
04Use case
What is the concrete job the product does?
05Inputs
What capability, data, or access does it require?
06Product promise
What does the seller commit the buyer will get?
07Package boundary
What is in scope — and explicitly out of scope?
08Value metric
What unit scales with the value the buyer receives?
09Proof
What evidence makes the committee believe it?
10Implementation
How does the buyer go live without bespoke heroics?
11Success metric
How will the buyer know it worked?
12Expansion 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
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 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.
HybridA platform fee plus usage or outcome matches mixed value.Complexity can make the offer hard to explain and compare.
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.

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.

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.
01

Qualify

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

Scope

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

Prove

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

Convert

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

Operationalize

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

Expand

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

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

Evidence

Proof taxonomy.

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

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

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 about ROI, payback, margin, risk to the number.

Needs A business case in their own numbers.

Technical buyer

Cares about Fit, integration, security, control.

Needs Evidence it works in their environment.

Operator / workflow owner

Cares about Adoption, effort, day-to-day workflow.

Needs Proof their team will actually use it.

Legal / privacy / security

Cares about Compliance, data handling, exposure.

Needs Documented controls and a clean review.

Procurement

Cares about Terms, price, comparability, leverage.

Needs A package they can compare and negotiate.

Executive sponsor

Cares about Strategy, outcome, organizational risk.

Needs A narrative that ties to a priority they own.

Sales narrative spine

1Problem
What is broken, for whom, and why now?
2Stakes
What does it cost to leave it unsolved?
3Product
What is the packaged path to the outcome?
4Proof
Why should each buyer believe it?
5Path
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.

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.

Direct enterprise sale

Best when High ACV, committee buying, custom security and terms.

Watch-out Long cycles; demands real sales and solutions capacity.

Marketplace listing

Best when Buyers procure through a cloud or platform marketplace.

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

Private offer

Best when Negotiated terms through a marketplace for a known buyer.

Watch-out Still needs a legible package behind the custom terms.

Native app

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

Watch-out Platform constraints and review cycles shape the roadmap.

API product

Best when Developers integrate the capability directly.

Watch-out Requires docs, support, and pricing for programmatic use.

Partner / channel package

Best when A partner resells or embeds the product.

Watch-out Margin sharing and enablement can dilute control.

Managed workflow

Best when The buyer wants the outcome run for them.

Watch-out Drifts back toward services if not productized tightly.

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

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.
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
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.
Deliverables

What ships.

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

Productization diagnosis

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

Used by CEO / CPO / CRO

Offer architecture canvas

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

Used by Product / GTM

Packaging and tiering model

The package map, boundaries, and tier logic.

Used by Product marketing / GTM

Pricing and value metric map

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

Used by CRO / Finance

POC-to-production blueprint

The six-step path that converts pilots into production.

Used by Sales / Solutions

Proof taxonomy

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

Used by Sales / CS / Product marketing

Buyer committee narrative

One narrative translated into six buyer lenses.

Used by Sales / Product marketing

Distribution path recommendation

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

Used by GTM / Partnerships

Bespoke vs productized decision model

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

Used by Exec / Product / Sales

30/60/90 productization plan

The diagnose-design-launch-scale operating plan.

Used by Exec / 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.

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.

30 — Diagnose

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

60 — Design

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

90 — Launch

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

Beyond — Scale

  • Distribution and marketplace paths
  • Renewal and expansion motion
  • Enterprise standard positioning
  • Repeatable revenue engine
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.

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 →