Digital product strategy development: how to compare options

What to take away

Compare at least two genuinely different strategies before choosing one.
Score each option on stated criteria, and do not average away a fatal risk.
Write down why plausible options lost, so the debate does not restart without new evidence.
Roadmaps express outcomes and intent, not a permanent feature contract.

Compare options after discovery, not before

Options belong after discovery has named the problem. The GOV.UK Service Manual's guidance on how the discovery phase works says you should not start building your service in discovery, and the same separation stops an option from hardening into a plan too early.

Digital product strategy development works best as a documented sequence of decisions. Gather existing evidence first, so that the comparison draws on what support, sales, operations and product data already show, including behavioral, qualitative and commercial evidence.

Write every option the same way

Give each option the same six fields so the options can sit side by side. A strategy that cannot fill one field is a wish rather than an option.

Option field / Prompt

Target: Which segment and situation first?
Value: Which outcome improves enough to matter?
Advantage: Why this product instead of the alternative?
Model: How is value captured and sustained?
Capability: What must the organization become good at?
Risk: What could harm users or invalidate the economics?

Keep each cell to a sentence or two. The point is a fair comparison, not a long document.

Score against criteria you chose in advance

Score options against user value, evidence strength, differentiation, strategic fit, technical feasibility, reliability, economics, time to learn, reversibility and opportunity cost. Include accessibility, privacy and security as scored criteria, not afterthoughts.

Do not average away a fatal risk. An option with a serious harm to users or an economic flaw that cannot be fixed should not survive on strength elsewhere. Choosing the criteria before looking at the options keeps the scoring honest.

A worked trade-off: one-time or subscription

Consider a hypothetical store selling downloadable design templates. It can sell each template as a one-time purchase or offer a subscription to an expanding library. A one-time purchase suits a self-contained need; a subscription can support recurring access but requires continuing content or service.

Now make the choice from stated evidence, not a preference. Suppose interviews and a test show that shoppers need one template for a specific project and do not value ongoing access. Record one-time purchase as the choice; the subscription's ongoing work has no demonstrated user value in this scenario.

If evidence instead shows recurring use and demand for new material, keep subscription in contention. This is a worked hypothetical, not a claim about market results.

Compare actual expected revenue and costs for both paths, including storefront and payment fees, content production, support and customer acquisition, using the store's own records and current quotes. If those inputs are not available, record the economics as an open assumption rather than inventing a figure.

Five business models side by side

A comparison needs the same question asked of every model. The table sets the five business models a digital store usually weighs against one test each, so the choice rests on evidence the store can collect.

Model	How value is captured	Test before choosing it
One-time purchase	One payment per product	Do buyers need it once, for a specific project?
Subscription	Recurring payment for continuing access	Is there recurring use and demand for new material?
Freemium	A free tier, with a paid upgrade	Does the free tier lead buyers to a need they will pay for?
Usage-based pricing	A charge that follows use	Can the buyer predict the bill?
Licensing	Rights to use, granted on stated terms	Are the rights clear to the buyer?

Run the test column as a short round of interviews or a small experiment, not a debate. A model that fails its own test stays in the record as rejected, with the reason beside it.

Record what you rejected

State the reasons for rejecting plausible options so the same debate does not restart without new evidence. Keep the rejected options in the record beside the chosen one, because the constraint that ruled them out can change.

The record is complete when it holds the chosen model and rejected alternatives, evidence and cost inputs, accountable owners, dependencies, and a condition for continuing, changing, or stopping. The strategy checklist lists the evidence gates a reviewer will look for.

Publish a strategy others can test

Publish the strategy thesis, principles, exclusions, outcomes, first horizon, dependencies, risk owners and evidence plan. Ask every function to describe the decisions it can now make. If marketing, design, engineering, finance and support name different target users, the strategy needs another pass.

GOV.UK's guidance on developing a roadmap says each product iteration should have an objective that gets you closer to achieving your long-term vision. Treat the roadmap as intent that serves the strategy, and revisit it at each product-planning cycle.

Common questions

How many options should be compared?

Usually two or three genuinely different choices are enough to expose tradeoffs without creating a ceremonial exercise.

Who should participate?

Include the decision owner and the people who understand users, delivery, economics, operations, growth, accessibility, privacy, security, and legal risk.

How long should the comparison take?

Timebox the first decision based on risk and available evidence, then keep strategy review continuous.

What if the numbers are not known yet?

Record the economics as an open assumption and name who will fill it. A confident figure with no source is worse than a visible gap. More answers are in strategy questions.