Let the review shape the next build
The previous projects created several possible directions: improve a website, deepen a booking guide, repair product delivery, strengthen onboarding or simplify reporting. This week chooses one. The aim is to focus effort on a problem that matters to the audience and the business, using the evidence currently available.
Keep the programme's plan flexible at this point. Week 19 includes a sensible default improvement to website or resource clarity, but the actual project can change if a different need has stronger evidence. Record why the substitution was made so the audience can follow the decision.
1. Describe the constraint precisely
Start with an observed problem. “We need growth” is too broad to direct a build. “Readers who want the checklist cannot find it from the linked page” describes a task, a situation and a possible obstacle. “Customers repeatedly need help opening the product” describes a different delivery constraint.
Gather the evidence supporting the problem: source-backed counts, direct questions, usability observations, support records and operating effort. Label each as observation, self-report, proxy, assumption or missing information. Keep the original context and dates so a striking anecdote does not lose its limitations.
Check whether a data-quality issue explains the apparent problem. Missing confirmations or duplicated records can create a false impression of performance. Repair the evidence before investing in a solution based on the wrong conclusion.
2. Compare a small set of actions
List a few plausible actions and include the option of collecting more evidence. For each, record the intended customer benefit, the strength of evidence, approximate effort, dependencies, maintenance and commercial relevance. Use simple qualitative judgements when exact estimates would be invented.
Distinguish a fix for a demonstrated failure from a speculative expansion. A broken delivery link has direct evidence and a clear correction. A new course category may require audience research and a small trial before a large build. Both can belong in the opportunity list, with different levels of confidence and commitment.
Consider the business model. A booking series may be useful if readers are preparing real service offers. A store series may be premature if most readers are still choosing a first product. More software adoption is valuable when the tool supports a genuine task and the learner can reach a useful result.
3. Select a bounded change
Write the chosen problem, the change and the mechanism that should help. Keep the scope small enough to implement and inspect during the next build week. Specify what will remain outside this project so other attractive ideas do not turn it into a redesign of the entire business.
Define the customer-facing result and the operating responsibilities. If the change introduces a new message, someone must own exceptions. If it adds a tool, include its cost and maintenance. If it changes a resource, update the relevant links and content that describe it.
Record the alternatives considered and why they were deferred. This is useful learning content: the audience can see that a focused business system grows through choices, rather than through adopting every available feature.
4. Agree the review rule before the build
Choose the evidence you will collect after the change. This may include a controlled task test, a reliable completion event, direct customer feedback or operating time. Specify the observation window and the conditions that would lead to retaining, revising, reversing or extending the change.
Use a rule appropriate to the evidence volume. A small audience can support usability testing and reliability checks even when it cannot support a persuasive comparison of close conversion rates. Avoid an arbitrary target chosen solely because it looks impressive in a video.
Record other changes that could influence the result. The final review should be able to distinguish “the change worked in our test” from “the business metric improved during a period when several things changed.”
Illustrative case
Clearweft might find repeated questions about choosing a first business path. The relevant guide receives visits, but a fresh-reader test shows that learners cannot tell which worksheet to use. We could add a concise path selector and a clearer first action, then repeat the task test and observe the relevant resource clicks. That is a bounded project with a plausible mechanism.
If the real evidence instead identifies a delivery failure, choose that fix first. Publish the evidence, the trade-off and the decision brief. The next episode then has a clear reason to exist.
You are finished when: The next build has a decision brief that can be reviewed against actual evidence.
Work with the evidence you have.
This guide teaches a review method. No live Clearweft performance is claimed. Explore labelled practice data, then apply the worksheet to your own records.
Open the analytics labCheck your work.
The next build has a decision brief that can be reviewed against actual evidence.
Saved only in this browser. You can change this any time.