A persuasive product can make an organisation write the problem backwards.
Leaders see a competitor's portal, an AI demonstration or a new platform and ask how quickly the firm can buy one. Requirements become a description of the product, delivery success becomes launch, and weak adoption is blamed on resistance.
The source calls this “demo gravity”. It is a good name for the emotional momentum a polished solution creates. The remedy is a decision gate, with one important qualification: technology can legitimately trigger investigation, and technical events can themselves create the problem.
Technology is sometimes the starting evidence
An unsupported platform, material vulnerability, expiring contract or supplier failure can force a technology decision. The business problem may be continuity, risk or avoidable cost rather than an unmet user need.
A new capability can also reveal an opportunity leaders had not imagined. Dismissing it because the problem was not documented first would be artificial.
The discipline is to separate trigger from preferred answer. An end-of-life notice may require action and does not prove that replacement with the vendor's new product is best. An AI demonstration may expose useful potential and does not establish a production use.
Begin with the change or evidence that prompted interest, then define the outcome and constraints before committing to a supplier.
Three tests before market engagement
What is happening now?
Describe the affected people, task, service and consequence. Use direct research and operational evidence where available.
“Our digital experience needs modernising” is too broad. “New clients repeat company information across three onboarding steps, creating avoidable delay and reconciliation work” can be investigated.
State what is known, inferred and missing. A dramatic metric is unnecessary if repeated observation already justifies a bounded improvement; a major investment requires stronger evidence.
What needs to be different?
Describe an observable outcome without embedding one product. The target might be fewer repeated requests, safer data exchange, faster recovery, reduced manual effort or the ability to retire unsupported software.
Include constraints and duties. Security, accessibility, regulatory needs, client preference, operating capacity and contracts can shape a viable result.
Do not force a number where the baseline is absent. Fund measurement or a short discovery step and record the uncertainty.
How will the decision be judged?
Define measures of outcome, service quality, adoption, cost and harm. State when evidence will be reviewed and who can alter or stop the work.
Delivery measures still matter. Date, budget and technical quality affect the investment. They cannot substitute for the reason the investment exists.
A portal launched on time can be a delivery success and a commercial failure. Record both.
Demo gravity changes the questions
A product demonstration usually shows configured data, prepared users and a successful path. It rarely shows migration, exceptions, permission conflicts, failure recovery, operating effort or the decisions needed when the standard workflow does not fit.
Before a demonstration, give vendors representative scenarios and decision criteria. Ask them to show:
- the difficult task, not only the homepage;
- an error and recovery;
- a permission or approval exception;
- accessibility with real interaction;
- integration failure and reconciliation;
- administration and normal change;
- audit and export;
- upgrade, support and exit.
Demonstrations inform evaluation. They are not user research or a business case.
Competitive anxiety needs evidence
A competitor's announcement reveals what they chose to publicise. It does not reveal adoption, cost, client value or fit for your firm.
Investigate the underlying capability and buyer expectation. A rival portal might make status easier to see; your clients may prefer a clear update through another secure route. Copying the artefact can miss the value.
Use competitor work to ask better questions. Speak to clients, inspect your service and compare the commercial strategy. Decide whether the gap matters enough to displace other work.
Problem definition is a leadership conversation
Defining the problem exposes disagreements that product selection can temporarily hide. Marketing may see weak conversion, operations repeated work, security unacceptable exposure and partners no issue at all.
Do not average those views into “the platform is outdated”. Identify the different outcomes, evidence and conflicts. A single programme may address several, or leaders may need to choose which one drives the decision.
Give the problem owner authority and name affected service owners. The technology team should shape feasibility early. “Problem first” does not mean bringing engineers in after strategy is complete.
Clients and frontline users contribute evidence; they do not carry the burden of designing the investment.
Compare non-technology options
Once the outcome is defined, consider process, policy, content, training, staffing, configuration, repair, integration, replacement and stopping the activity.
A form redesign may address errors without a portal. Better ownership may resolve slow enquiries without marketing automation. A platform change may still be the right answer when current architecture prevents the desired service.
Show options at a comparable level. It is misleading to compare a detailed vendor proposal with a one-line “improve process” alternative.
Include retaining the current state with managed controls. The cost and risk of waiting should be explicit.
Use WHNN without turning it into the answer
Distinction's WHNN® framework can organise four connected views:
- Now: the current evidence and constraints.
- Next: the commercially relevant state.
- What: the few priorities that close the gap.
- How: ownership, sequencing, governance and technology.
The value lies in the sequence and recurring decisions. WHNN is one approach, and its presence does not prove the diagnosis or recommendation. A client should be able to use the evidence with another framework or supplier.
Keep the one-page problem statement
The source's practical one-page test is worth preserving. Before material approval, require a page that states:
- trigger and decision required;
- current problem or opportunity;
- affected users and services;
- evidence and uncertainty;
- desired outcome and constraints;
- success and harm measures;
- options to examine;
- owner and decision date.
The page should avoid a predetermined vendor except where a contract or technical constraint makes that vendor part of the problem. Even then, include viable options and reasons.
Apply proportionality. A small reversible tool does not need the same paper as a regulated client platform. Every investment needs enough clarity that somebody can later judge whether it worked.
Scar tissue is a governance signal
A failed investment can make the board sceptical of the next one. The source uses “scar tissue” to describe that memory.
Do not overcome it with a more persuasive pitch. Review the previous decision: what evidence was missing, which assumptions failed, how governance responded and what has changed. Make the new case auditable against those lessons.
Specific scepticism can improve the proposal. General refusal to invest can create another risk, which should be assessed in the same portfolio.
The original article used several precise client costs, adoption and conversion outcomes plus broad transformation statistics. Hold them until records, definitions and permissions are verified. The problem-first argument is stronger without borrowed failure rates.
For related investment choices, read how to plan digital investment when budgets are tight.
But you don't need a framework to start. You need the one-page test. Print it out, stick it on the wall of whatever room your investment decisions get made in, and don't let anything through that can't answer those three questions without naming a vendor.
It won't make you popular with the salespeople. It will make you significantly better at spending money on things that actually work.
