TL;DR
- Value delivery model is the first structural classification that should happen. Get it wrong and the next 9 Product DNA dimensions wobble with it.
- There are 5 useful models: workflow tool, system of record, intelligence layer, automation platform, and infrastructure.
- Each model carries different defaults for activation, pricing, moat, and content. A system of record should not run a workflow tool's playbook.
- The practical question is not "what does the product do?" It is "what kind of product is it structurally?"
Most companies answer the wrong question first.
Ask what kind of product they have and they tell you the feature set, the buyer persona, or the category they want to win. What they often skip is the structural layer: what kind of value-delivery model is this thing actually built on?
That matters because value delivery model quietly constrains everything else. A system of record has slower activation, different pricing logic, and a different moat than a workflow tool. An intelligence layer should not run infrastructure messaging. An automation platform should not assume the same buying path as a lightweight scheduling tool.
"If you misclassify what kind of product it is structurally, you will usually spend the next year optimizing the wrong motion."
— Jake McMahon, ProductQuant
This is why Dimension 1 matters so much. It is not the most glamorous dimension. It is the one that stops the company from importing a playbook designed for a completely different product shape.
What Are the 5 Main Value Delivery Models?
These 5 models are useful because they change the product's natural defaults in obvious ways.
1. Workflow tool
A workflow tool helps a user do a repeated job directly. Scheduling, issue tracking, design, and task management all fit here. Activation can be fast because the job is clear and immediate. PLG often works because the user can try the workflow quickly. The moat often starts with habit or team embedding, and content usually works best when it is practical and task-oriented.
2. System of record
A system of record stores and governs important domain data. CRM, ERP, and core HR platforms fit this model. Activation is slower because data migration, configuration, and training matter. Sales-led or guided pilots become much more natural than lightweight trials. The moat usually comes from data lock-in and workflow dependence.
3. Intelligence layer
An intelligence layer sits on top of other systems and turns data into insight. Product analytics, revenue intelligence, and reporting platforms often fit here. Activation depends on integration and enough data volume. Value compounds over time as more data accumulates. That makes the "trial" logic different: the meaningful window starts once data is flowing, not when the account is created.
4. Automation platform
An automation platform replaces manual work with systemized flows. Some use cases activate quickly. Others require much more design and configuration. That means the motion often splits: self-serve for simpler automations, sales assist for deeper, more cross-functional ones. The moat usually builds through workflow embedding and the cost of recreating all the automations elsewhere.
5. Infrastructure
Infrastructure is usually invisible to the end user and valuable to technical teams. Twilio, Stripe, and cloud platforms fit here. Integration depth matters more than UI novelty. Usage-based pricing is often natural. Documentation is not a support asset around the product. It is a core part of how the product is sold and adopted.
| Model | Activation default | Moat default | Common GTM mistake |
|---|---|---|---|
| Workflow tool | Fast or moderate | Habit or team embedding | Overcomplicating the commercial path |
| System of record | Slow | Data lock-in | Running lightweight self-serve trials |
| Intelligence layer | Integration-dependent | Historical data accumulation | Judging activation from signup instead of data-in |
| Automation platform | Mixed | Workflow embedding | Using one motion for simple and complex use cases |
| Infrastructure | Integration-dependent | Integration depth | Writing marketing instead of documentation-led GTM |
Use Product DNA to classify the model before picking the motion.
Once the value delivery model is clear, the rest of the growth and pricing choices get much less vague.
Why the Wrong Model Creates the Wrong Playbook
The easiest way to see the problem is to look at what happens when one model borrows another model's assumptions.
A system of record running a workflow tool playbook usually ends up with short trials, thin onboarding, and underpriced implementation burden. The product never gets a fair evaluation window because the playbook assumes value can appear much faster than the system actually allows.
An intelligence layer running an infrastructure playbook often over-indexes on technical language and developer acquisition when the real buyer may be an analyst, product team, or revenue leader who needs insights more than APIs. The company then thinks demand is weak when the real problem is misclassified content and buyer targeting.
A workflow tool running a system-of-record playbook creates the opposite issue. The product is easy to understand and easy to try, but the company layers on unnecessary sales process, heavyweight onboarding, or enterprise theater that the buyer did not need.
The farther the borrowed playbook is from the real value-delivery model, the more every downstream team has to compensate manually.
This is why value-delivery model is such a leverage point. Once it is right, activation, content, pricing, and sales design stop fighting each other as much.
What Should You Do Instead?
Start by classifying the product structurally before you debate GTM, pricing, or onboarding tactics.
- Name the model first. Workflow tool, system of record, intelligence layer, automation platform, or infrastructure.
- Check whether activation logic matches the model. If value requires data, migration, or configuration, stop pretending signup is the start of the real evaluation window.
- Check whether pricing matches the model. Seats, usage, modules, and flat-rate plans all imply different expansion mechanics.
- Check whether content matches the model. Workflow tools need practical content. Infrastructure needs docs. Intelligence layers need insight-led proof.
- Use the model to reject bad benchmarks. The company should be compared to products with similar structural properties, not just familiar logos.
The sharper framing is simple: classify the value-delivery model, then let the rest of the system follow it. Not the other way around.
If the company keeps borrowing the wrong playbook, start at Dimension 1.
The Product DNA framework is designed to classify the product structurally before the team commits to the wrong motion again.
FAQ
Can one product have more than one value-delivery model?
Sometimes, especially in broader platforms. But one model usually dominates the core GTM logic. The mistake is treating every secondary capability like it should dictate the whole motion.
Why does system of record usually mean slower activation?
Because systems of record depend on real data, governance, configuration, and workflow change. Those things make the product more valuable and more durable, but they also make a lightweight trial less informative by default.
Can an intelligence layer still use PLG?
Yes, but the meaningful product-led window often starts only after integration and data flow. That means the company should measure activation from the point where the product can actually generate insight, not just from signup.
What is the most common misclassification?
Treating a system of record or intelligence layer like a simple workflow tool. That usually creates overly short trials, shallow onboarding, and underestimation of setup burden.
Sources
About the Author
Jake McMahon writes about Product DNA, growth systems, and the structural choices that determine whether activation, pricing, and GTM fit the product or quietly fight it. ProductQuant helps teams classify the product they actually have before they import somebody else's playbook.
Start with what the product is, not what the team wants it to be.
If the growth motion keeps feeling wrong, there is a good chance the value-delivery model was misclassified before the rest of the strategy got built.