Strategy
Six steps from an observed problem to a landing page decision, deferral or exit
Use a landing page software strategy framework that links verified evidence, options, constraints, controlled tests, decision owners and exit rules.
A landing page software strategy framework should let a decision owner trace one buyer problem from evidence to an option, controlled test and exit. Begin with the current workflow. Do not start with a supplier, desired conversion rate or generic aim to "improve performance".
This framework was assembled through desk research on 6 September 2026. No organisation used it, no page was tested and no outcome is claimed. It needs current specialist review before live processing or promotion.
What to take away
- Start with the observed buyer problem, not a supplier or a target conversion rate.
- Keep an option set open and compare every option against identical criteria.
- Constraints sit in separate gates, and one passing gate cannot offset another failure.
- A bounded test names one uncertainty, a non-production method, a stop event and rollback.
- Exit planning covers domains, page assets, claim files, personal data, access and restoration proof.
1. State the observed problem
Write the event, eligible organisation or user, period, evidence and consequence. Separate an observation from its interpretation. "Approval records show page versions returned for missing claim evidence" is an observable pattern if the records exist. "The team needs a landing page builder" is already a solution.
Problem statement essentials
- Write the observed event
- Name eligible organisation or user
- State the period
- Cite the evidence
- State the consequence
- Separate observation from interpretation
The GOV.UK Service Manual recommends turning unsupported assumptions into research questions when teams plan user research. Apply that discipline to the missing part of the problem statement. If the consequence or affected population is unknown, research it before selecting an option.
2. Define the objective and visitor task
Record the business objective with its owner, unit, population and period. Beside it, state what an eligible visitor is trying to do and cite the research. The page proposition should help that task while stating material conditions clearly. It must not turn the business goal into a disguised visitor need.
For claims, the ASA's misleading advertising guidance explains that objective statements need substantiation and the overall impression matters. A named reviewer should examine the final page in context rather than approve isolated copy.
3. Keep an option set open
Compare improvement to the existing website, a controlled manual workflow, specialist software and any relevant managed service. Use identical criteria: task fit, ownership, data route, access, accessible output, evidence storage, integration, monitoring, withdrawal and exit. Mark unavailable evidence unknown. Feature volume is not a decision criterion unless a feature answers the verified problem.
4. Declare assumptions and constraints
Maintain an assumption register with evidence owner, confidence reason, expiry and test. Constraints belong in separate gates: privacy, PECR, advertising, accessibility, security, contract, budget and capacity. One passing gate cannot offset another failure.
The NCSC's cloud-provider guidance asks organisations to understand security needs and shared responsibilities. Use it to frame due diligence, not to infer that a service is secure. For accessibility, WCAG 2.2 supplies global testable criteria; the delivered page and workflow still need direct assessment.
5. Specify a bounded test
Name one uncertainty, a non-production method, synthetic fixtures, acceptance evidence, owner, stop event and rollback. Keep channel, content and configuration fixed where the comparison requires it. A workflow test might check whether the approved version can be recovered and withdrawn. It cannot establish commercial uplift.
HM Treasury's Magenta Book says evaluation should be designed from the outset and results interpreted within the chosen method. If the strategy asks whether the page caused an outcome, an observational before-and-after count is insufficient by itself.
6. Decide, defer or exit
The decision record should show the option chosen, evidence used, unresolved risks and dissent. Define who can proceed, who can block a specialist gate and who can order rollback. A defer decision should specify the missing evidence rather than quietly becoming approval.
Exit covers domains, page assets, claim files, personal data, suppression, integrations, access, exports and restoration proof. Reopen the strategy if the buyer problem, channel rule, supplier edition, risk boundary or material evidence changes. The framework is complete only when the owner can explain both why to proceed and how to stop.
Before you act
- Write the observed event, evidence and consequence before choosing an option.
- Record the business objective with its owner, unit, population and period.
- Compare options on task fit, ownership, data route, access and exit.
- Keep an assumption register with evidence owner, confidence, expiry and test.
- Name one uncertainty, acceptance evidence, owner, stop event and rollback.
- Specify the missing evidence in any defer decision.
Common questions
What should a problem statement separate?
It should separate an observation from its interpretation. The article gives the example that approval records showing page versions returned for missing claim evidence is an observable pattern if the records exist. By contrast, saying the team needs a landing page builder is already a solution rather than a problem.
Why is feature volume not a decision criterion?
The article states that feature volume is not a decision criterion unless a feature answers the verified problem. Options should be compared on identical criteria, including task fit, ownership, data route, access, accessible output, evidence storage, integration, monitoring, withdrawal and exit. Unavailable evidence should be marked unknown.
What does an exit decision need to cover?
Exit covers domains, page assets, claim files, personal data, suppression, integrations, access, exports and restoration proof. The strategy should be reopened if the buyer problem, channel rule, supplier edition, risk boundary or material evidence changes. The framework is complete only when the owner can explain why to proceed and how to stop.
