The business model belongs in product design

The business model belongs in product design because it changes what the product must do. Who pays, what they believe they are buying, how value is delivered and what the business must carry after the sale all shape the experience as surely as a user need or technical constraint.

Leaving those questions until after the product works creates a dangerous kind of progress. The team may have a coherent interface and reliable software, but no clear exchange that a customer can understand, choose and sustain.

Commercial thinking does not make a product less ambitious. It gives the ambition an operating form.

Begin with the exchange, not the pricing page

A business model is often reduced to a price attached near launch. Price matters, but it comes after a more basic product decision: what useful exchange is taking place?

One party brings a problem, information, attention or money. The product creates a change. The business performs the work required to deliver that change. Both sides need to understand what happens next.

A useful first statement is:

A defined customer gives or commits something in order to receive a specific outcome the business can deliver repeatedly.

That sentence forces several decisions into view. The customer must be specific enough to recognise. The outcome must be clear enough to value. The commitment must mean more than casual interest. The delivery method must be repeatable enough to support more than one successful demonstration.

If the team cannot describe the exchange, a pricing model will only give uncertainty a number.

The user, buyer and operator may be different people

Many products fail to distinguish the person using the interface from the person authorising the purchase and the person responsible for running the service.

An employee may use an internal workflow every day, while an operations leader buys it and an administrator handles permissions and exceptions. A job seeker may use a marketplace without paying, while employers or another commercial partner fund the operation. A customer may submit information through a simple form, while a specialist reviews the case behind it.

Each participant needs a different kind of value:

• The user needs the core task to become meaningfully better.
• The buyer needs a credible reason to commit budget, access or organisational support.
• The operator needs a product the business can deliver, monitor and improve.

Treating them as one generic persona hides trade-offs. A frictionless user experience can still be commercially weak if the buyer cannot see the outcome. A persuasive sales promise can still be operationally weak if the team cannot fulfil it reliably.

Product design should connect all three views without forcing them into one interface.

Define the unit of value

Every business model contains a unit of value, even when the team has not named it.

It may be a completed assessment, a qualified enquiry, an approved application, access for one team, a recurring workflow, a successful transaction or continued availability of a system. The unit explains what the customer is paying for and what the product must make visible.

This decision changes the design.

If the value is a completed outcome, the product needs a clear beginning, progress state and finish. If the value is ongoing access, reliability, permissions and continued usefulness become central. If the value depends on a transaction, both sides need to understand the terms and handoff. If the value is a business result, the product needs an honest way to connect activity to that result without claiming more than the evidence supports.

A vague unit produces vague product measures. Page views, registrations and completed screens may show activity, but they do not automatically show that the exchange worked.

The unit of value gives strategy, design, engineering and commercial validation the same object to examine.

Make the delivery burden visible

A digital interface can make a service look self-contained while a growing amount of manual work accumulates behind it.

Someone may still need to check every submission, correct imported data, coordinate a supplier, answer the same question or rebuild context when an integration fails. That work is not automatically a problem. Human judgment and service can be part of the value. The problem is allowing the business model to assume software-like scale while the operation behaves like unpriced custom work.

For each unit of value, ask:

• What must happen before the customer receives the outcome?
• Which step is performed by software, a person or an external dependency?
• Which exceptions are likely, and who owns them?
• What support does the customer reasonably expect?
• Which cost or constraint grows each time the product is used?

These answers influence scope. The first product may need an operator queue before another customer-facing feature. It may need a narrower promise, a clearer review boundary or a price that reflects expert involvement. It may reveal that a supposedly automated product is currently a valuable managed service—and should be described honestly as one.

Commercial viability depends on the whole delivery system, not only the visible product.

Choose the payment moment deliberately

The payment moment is where the product asks a customer to trust the promise enough to commit.

That commitment may be a purchase, subscription, deposit, paid pilot or signed agreement. In some models, payment comes from a different participant than the primary user. Whatever the form, its position in the journey reveals what the customer must understand first.

Paying before use requires a clear promise, credible boundaries and enough trust to act. Paying after an initial result requires the product to create useful evidence without giving away the entire service. A paid pilot requires a defined scope, owner, support process, duration and decision at the end.

The team should not choose the payment moment only because a billing tool makes it easy. It should choose the point at which the customer has enough information to make a fair decision and the business has enough commitment to deliver responsibly.

This is part of the product experience. The offer, onboarding, delivery and renewal logic should describe the same exchange.

Test whether the exchange can repeat

A first sale can be important evidence without proving that the business model works repeatedly.

The customer may have bought because of a trusted relationship. The team may have delivered through exceptional effort. The price may not cover the true burden. None of that invalidates the sale; it simply defines what the next product decision must examine.

Useful evidence includes:

• Whether the intended buyer understands the unit of value.
• Whether the customer commits at the proposed payment moment.
• Whether the product can deliver the promised outcome within its stated boundaries.
• Whether operator effort and exceptions remain visible.
• Whether the customer returns, renews or takes the next meaningful step for the reason the model expects.

The goal is not to prove a perfect business at the first attempt. It is to learn which part of the exchange is strong enough to preserve and which part must change before the product expands.

Keep a product-and-business record

An early product needs a short record that connects the experience to its commercial logic:

• User: who completes the core product journey.
• Buyer: who commits money, access or organisational support.
• Problem: the situation important enough to create action now.
• Unit of value: the outcome or access being exchanged.
• Delivery system: the software, people and dependencies required.
• Payment moment: when commitment happens and what must be understood first.
• Delivery burden: the cost, support and exception work attached to each unit.
• Evidence: the behaviour or commitment that would justify the next stage.

This is not a static business plan. It is a working product decision. As evidence changes, the team may narrow the customer, change the unit, move the payment moment or redesign the delivery system.

Build the product and the commercial system together

Dial8 is a product studio for ambitious visions. We turn ideas into working digital products through strategy, design, engineering and commercial validation. That combination matters because a useful interface and a viable exchange are not separate projects.

Across client products and our own commercially viable products and ventures in development, validation or market, the standard remains the same: describe what is built honestly, identify who it serves and make the next commercial question visible.

This is part of what it means to build things that widen possibility. A product creates a useful new choice for a customer. A credible business model gives that choice a way to be delivered, supported and sustained.