Choose a Product Pricing Model

Task

Decide initial product pricing and packaging.

Summary

Decide how licenses, seats, usage, implementation, access, or hybrid pricing should reflect value and cost.

Set the First Product Price Without Rebuilding the Service

Task ID: S3-04

An initial product price is not a number chosen from costs or competitors. It is a testable design linking customer value, a measurable charging unit, onboarding work, support cost, and package boundaries. This article shows how a demo-led company can choose a simple starting model, define credible price tests, and decide whether the product can stand on its own.

The first price often exposes whether the product is truly separate from the service

The product works. A design partner has used it. A few prospects have seen a demo and asked what it costs.

Then the difficult questions begin.

Should the company charge each user, each account, each transaction, or one annual license? Is onboarding included? What happens when a customer needs migration, configuration, training, or an integration? Does the price rise when the customer receives more value, or only when the company performs more work?

A weak answer is to choose a familiar software price, add three packages, and leave the sales team to negotiate the exceptions. That produces something that looks like pricing, but each sale may still depend on custom scope, founder judgment, unrecorded discounts, and unpaid implementation.

The real task is to decide whether the product can be sold, launched, and supported as a repeatable product.

Choose the charging logic before defending the number

An initial price has three connected parts:

• the package, which defines what the customer receives;
• the price metric, which defines what makes the bill increase; and
• the price level, which assigns money to that package and metric.

Changing any one can change the meaning of the others. A $1,000 monthly account price, $20 user price, and two-cent transaction price may produce the same first invoice for one customer while producing radically different incentives and economics as the customer grows.

The central operating principle is:

Charge using a unit that customers understand, that rises reasonably with the value they receive, and that the company can measure and deliver profitably.

That unit does not need to mirror cost perfectly. Customers do not buy cloud-compute expense, development hours, or database rows. But a model that ignores both customer value and variable cost eventually creates friction on one side of the transaction.

Start with the customer and result

Before comparing pricing models, define five facts:

1. Which customer segment is this product for?
2. Who approves the purchase?
3. Who uses the product?
4. What useful result should the customer receive?
5. What repeatable work is required to reach that result?

These answers determine which units are plausible.

A collaboration product may create value as more employees participate, which makes an active-user metric understandable. Slack uses active members as its billing unit and applies prorated credits when paid members become inactive. The lesson is not that every collaborative product should copy Slack. It is that a seat definition can be refined to reflect real participation instead of merely counting every account ever created.

An infrastructure product may create value through data processed, storage used, or compute consumed. Snowflake describes its product revenue as dependent on customer consumption, and its cloud-infrastructure costs also rise with consumption. A measurable usage unit can therefore reflect both the customer’s activity and an important cost driver.

An automation product may create value by completing a task or producing a verified result. Intercom’s current model combines per-seat plans with charges for defined automated outcomes. Its documentation specifies what counts as each outcome and limits billing to one outcome per conversation. Outcome pricing is credible only when the event can be defined with that level of precision.

Understand what each model asks the customer to believe

A license or fixed subscription asks the customer to pay for access during a term. It gives the buyer predictability and avoids metering every action. It works well when use is broad, when the product’s marginal costs are low and stable, or when measurement would cost more than it adds. The weakness is that one flat fee may capture too little value from large customers or appear expensive to small ones.

A per-seat model asks the customer to treat each user as an additional unit of value. It is easy to quote when user counts are known. It becomes less convincing when a product replaces work, automates jobs, serves occasional users, or becomes more valuable when shared widely. Charging for every user can cause the customer to limit adoption.

A usage model asks the customer to pay in proportion to activity such as transactions, messages, compute, data, calls, or documents. It lowers the entry price for a light user and allows revenue to expand with use. It also makes the bill less predictable and requires trustworthy metering, forecasting, corrections, and spend controls.

Usage pricing is not automatically the modern or superior choice. Research on competitive software pricing found that monitoring and transaction costs can outweigh the benefit of attracting low-usage customers. Other research observes that software demand is often not smoothly adjustable: a company may need a license for every relevant employee or no deployment at all. Under those conditions, flat fees, quantity discounts, or seats can fit better than a simple pay-per-use schedule.

An implementation fee asks the customer to pay separately for launch work. It is appropriate when migration, configuration, training, or integration requires material effort that is repeatable and bounded. The fee should have a scope, customer responsibilities, acceptance condition, and exclusions. “Implementation” is not a safe label for unlimited custom work.

A hybrid model combines components, such as a base platform fee plus usage, seats plus automated outcomes, or a subscription plus a one-time implementation fee. A hybrid can reflect both fixed and variable value, but every extra component creates another rule the customer, salesperson, product, billing system, and support team must understand.

Keep the first package smaller than the future catalogue

Packaging decides which capabilities, limits, support levels, and service obligations come with the purchase. It should make the customer’s choice easier and make delivery repeatable.

A new company is often tempted to create several tiers because established software companies have several tiers. That reverses the reasoning. Established companies often add packages after learning that distinct customer groups value different things, require different controls, or generate different costs.

Recent software-engineering research examined more than 150 observed SaaS pricing structures and found that configuration space grew particularly rapidly as add-ons accumulated. A related study used automated analysis on more than 150 models and identified errors in 35. These findings do not prove that a three-tier page is wrong. They show that pricing complexity becomes a product and operating-system problem, not merely a marketing choice.

For an early demo-led product, begin with one clear primary package unless evidence already shows two materially different buying situations. State:

• the customer and use case;
• included capabilities;
• usage, seat, account, or capacity limits;
• support and service level;
• onboarding work;
• exclusions;
• optional additions; and
• the event that requires an upgrade.

Use an enterprise exception process when necessary rather than pretending every possible enterprise request is already a coherent package.

Separate product revenue from custom work

A product sale can look successful while losing money during onboarding.

Snowflake’s fiscal year ended January 31, 2026 illustrates the importance of separate economics. It reported a 72% product gross margin and a negative 31% professional-services-and-other gross margin. Those are the economics of one large public company, not a target for an early product. The relevant lesson is that product and service activity can have very different cost structures and should be measured separately.

For each early customer, record:

• product revenue;
• implementation revenue;
• infrastructure and third-party cost;
• onboarding hours by role;
• support hours;
• custom development or integration work;
• sales discounts and concessions; and
• time until the customer receives a useful result.

If implementation work is necessary but repeatable, define and price it. If it varies widely, identify why. A recurring request may belong in the product roadmap, in a paid integration, or outside the offer. Hiding it inside the subscription prevents the company from seeing whether the product stands on its own.

Set the initial range from three views

There is no reliable formula that produces one objectively correct launch price. Build a range from three views.

The economic floor starts with costs that change when a customer is added or uses more of the product. Include infrastructure, external application programming interfaces, customer support, expected onboarding, billing costs, and other account-specific expense. Add uncertainty for work that has not yet become routine.

The market reference looks at what customers already buy instead. That includes direct competitors, manual processes, internal labor, consultants, and the cost of leaving the problem unsolved. Competitor prices provide context, but they do not reveal the competitor’s costs, discounts, product scope, funding priorities, or target customer.

The customer-value view estimates the result in the customer’s terms. It may be time saved, errors avoided, throughput increased, risk reduced, or revenue enabled. The purpose is not to charge the entire estimated value. It is to understand whether the proposed price makes economic sense to the buyer.

Customer interviews can reveal alternatives, budgets, objections, and preferred contract structures. They cannot prove a customer will pay. An open meta-analysis of 77 willingness-to-pay studies found that hypothetical estimates were about 21% higher than real willingness to pay on average. The included research was consumer-oriented, so that percentage should not be applied mechanically to business software. It does support treating stated willingness as an input and a real purchasing decision as stronger evidence.

Turn the price into a testable offer

A price test must state what the company expects to learn.

A useful record contains:

A working slate of three to five tests can cover the price level, price metric, package boundary, implementation fee, and contract commitment. Three to five is useful because it forces the team to choose the largest uncertainties. It is not a scientific benchmark.

Do not change every variable at once. If one cohort receives a lower price, extra features, free onboarding, a shorter commitment, and more executive attention, a higher close rate will not show which change mattered.

A high-volume self-service company may randomize prices or packages. A low-volume demo-led company usually cannot. It can use sequential offers or matched groups, but it should describe the evidence honestly. Controlled experiments support causal conclusions only when assignment, data, statistical assumptions, and metric interpretation are trustworthy.

Measure the purchase and the consequence

The primary sales measures are:

• qualified proposal-to-close rate;
• realized contract value;
• discount rate;
• sales-cycle length;
• loss and objection reasons; and
• acceptance of the metric, package, implementation fee, and contract term.

Those measures describe the buying decision. They do not show whether the model creates a healthy customer.

Add operating measures:

• time to first useful result;
• activation and use of the promised capability;
• onboarding hours;
• support requests and support hours;
• custom exceptions;
• variable product cost;
• contribution margin;
• early renewal or expansion signals; and
• invoice disputes or forecast errors.

Do not optimize only immediate contract value. Research on long-term controlled experiments warns that raising price can improve short-term revenue while reducing longer-term customer value if more users abandon. Early tests cannot prove renewal, but they should at least avoid a decision that wins the signature by creating poor activation, low use, or an unsustainable support load.

Make every charge understandable before the customer commits

The customer should be able to reproduce the bill from the contract and usage record.

Define what counts as a seat, active user, transaction, outcome, credit, account, or location. Explain minimums, included allowances, overages, rounding, timing, corrections, cancellations, and implementation charges. Give usage-priced customers a forecast and, where feasible, alerts or spend controls.

For Canadian public price representations, Competition Bureau guidance states that a price cannot be made unattainable by mandatory fixed nongovernment fees. It also notes that variable fees may still be problematic when the overall representation is misleading. Requirements differ by jurisdiction and transaction, so the actual offer should receive appropriate legal review.

Clear disclosure is useful even when a negotiated business contract is outside a particular consumer rule. Hidden charges create procurement delay, invoice disputes, and mistrust.

Recognize false completion

S3-04 is not complete merely because the company has:

• named three packages;
• copied a competitor’s price;
• calculated a cost markup;
• asked friendly customers what they would pay;
• converted a design partner at a large discount;
• put “custom” beside the enterprise package;
• called unbounded consulting an implementation fee; or
• recorded revenue without recording delivery cost.

These artifacts may support the work, but none establishes that the product can be sold and delivered repeatedly.

The company should also reconsider the model when:

• seat pricing causes customers to restrict the users who need the product;
• usage pricing produces bills customers cannot forecast;
• the billable unit is not reliably measurable;
• salespeople repeatedly override package boundaries;
• implementation requires senior people or custom code on every account;
• discounts are necessary to make the model acceptable;
• product use remains weak after a successful sale; or
• support and third-party costs rise faster than revenue.

What should exist when the decision is ready

The result should be a short pricing decision package, not a large strategy document.

It should contain:

1. the target customer, buyer, user, problem, and promised result;
2. the selected license, seat, usage, implementation, or hybrid model;
3. the exact billable unit and metering rule;
4. the primary package, limits, support, exclusions, and upgrade triggers;
5. the initial price or range and the economic, market, and customer evidence behind it;
6. a separate implementation scope and price where launch work is material;
7. a unit-economics model based on expected and actual delivery;
8. discount and exception authority;
9. three to five defined price tests, or a justified smaller plan; and
10. the decision rules for adopting, revising, or rejecting the model.

The company is ready to depend on the result when real customers understand the offer, some accept it without extraordinary concessions, the bill can be implemented and explained, onboarding remains within a defined process, and the economics remain credible after product and service costs are separated.

The first price does not need to be permanent. It needs to be coherent enough to sell, measurable enough to learn from, and disciplined enough to reveal whether the product is becoming a business rather than another custom project.

Sources

Primary and official sources

• Slack, Pricing Plans and Active-Member Billing. Official explanation of active-user billing, proration, and credits for inactive members.
• Snowflake Inc., Form 10-K for the fiscal year ended January 31, 2026. Official description of consumption-dependent product revenue, cloud-infrastructure costs, and separate product and professional-services margins.
• Snowflake Inc., Form 10-Q for the quarter ended April 30, 2026. Current evidence on consumption-related infrastructure expense and segment margins.
• Intercom, Pricing Calculator. Official per-seat plans and separately priced product components.
• Intercom, Fin AI Agent Outcomes, June 26, 2026. Official outcome definitions, charging events, and current outcome prices.
• Stripe, Usage-Based Billing Software for AI and SaaS. Official documentation of subscription, usage, credit, tiered, and hybrid billing capabilities and metering requirements.
• Stripe, Billing Pricing. Official billing and metering feature documentation.
• Competition Bureau Canada, Drip Pricing. Official guidance on unattainable advertised prices and mandatory fees.
• Competition Bureau Canada, Misleading Representations and Deceptive Marketing Practices. Current legal guidance on material representations and mandatory charges.
• Competition Bureau Canada, Guide to the June 2024 Amendments to the Competition Act. Official clarification of drip-pricing and discount-claim requirements.

Open research

• Bala, Ram, and Scott Carr, Usage-Based Pricing of Software Services Under Competition, 2010. University-hosted post-peer-review manuscript on fixed versus usage pricing and monitoring costs.
• Xin, Mingdi, and Arun Sundararajan, Nonlinear Pricing of Software with Local Demand Inelasticity, 2020. Research on why software demand may not vary smoothly with the number of licenses or units.
• Schmidt, Jonas, and Tammo H. A. Bijmolt, Accurately Measuring Willingness to Pay for Consumer Goods: A Meta-Analysis of the Hypothetical Bias, 2020. Open-access meta-analysis of 77 studies and the difference between hypothetical and real willingness to pay.
• García-Fernández et al., Racing the Market: An Industry Support Analysis for Pricing-Driven DevOps in SaaS, 2024. Open preprint examining more than 150 pricing structures from 30 SaaS products over six years.
• García-Fernández et al., Automated Analysis of Pricings in SaaS-Based Information Systems, 2025. Open research on detecting configuration and consistency errors in complex SaaS pricing models.
• Kohavi et al., Online Experimentation at Microsoft. Research overview of controlled experiments and causal evaluation in software.
• Deng, Lu, and Litz, Trustworthy Analysis of Online A/B Tests: Pitfalls, Challenges and Solutions. Research on invalid statistical assumptions and unreliable experiment conclusions.
• Dmitriev et al., A Dirty Dozen: Twelve Common Metric Interpretation Pitfalls in Online Controlled Experiments. Research on experiment-metric misinterpretation.
• Dmitriev et al., Pitfalls of Long-Term Online Controlled Experiments. Research on short-term metrics, longer-term customer value, selection bias, and survivorship effects.