Early in a project it’s easy to make two kinds of progress: more and more pages, or an ever more complete underlying design, while business staff still can’t get one specific thing done with the system. A more valuable goal for week one is to test the whole working path at the smallest possible scope.
Find the assumption most likely to sink the project
GOV.UK’s guidance on the alpha phase uses prototypes to test risky assumptions, not to finish the whole service early.[1] We apply this to business AI pilots: in week one, test first the part that’s most uncertain and could change the project’s direction. The rhythm below is a suggested plan, not a delivery promise for every project.
Say the goal is to generate customer follow-up suggestions. The biggest uncertainty might be thin company data, or a sales system that won’t allow the necessary fields to be read. Building a beautiful chat page first does nothing to reduce that main risk. Get authorized samples first and confirm a traceable judgment can be formed.
Days 1–2: pin down the input and the result
Pick one user, one task and one data source. Put the sample inputs, the expected result and the failure conditions in a single spec. The result should be directly checkable, for example a draft awaiting review that is linked to the right company record, not just “professional advice”.
Record the external dependencies too: who grants account access, who explains the fields, how long test data can be kept. If the real API can’t be had in time, test the interface with clearly labeled samples, but list the untested integration assumptions separately so a good demo doesn’t hide the delivery risk.
Days 3–4: connect one narrow path
Data goes into the system, gets processed, is confirmed by the user, and ends as a result that can be found again. Reuse existing capabilities along the way, and handle the parts with clear, fixed rules in ordinary code. Anthropic’s distinction between workflows and agents is a useful reference: well-defined steps can be orchestrated in advance, and autonomy is added only where the path needs to be decided dynamically.[2]
In this example, the first version can support just one kind of company data, one output template and human review. Leave out multi-role negotiation, automatic sending and complex task scheduling for now. With the scope narrowed, it’s easier to tell whether a failure happened in the data, the reasoning, the presentation or the review.
Day 5: let users operate it, not watch it
Run a short test and hand the mouse to a real user. The engineer watches where they pause, when they go back to the old tool, and what still needs explaining out loud. A demo that goes smoothly and a user finishing the task on their own are two different results.
The review only needs to answer a few questions: did the path work end to end, which assumptions held, which were overturned, and is the next step to continue, narrow or stop? If key data can’t be obtained, stopping a direction in time is a valid delivery too. The decisions from week one should make week two more certain, not just busier.
Write the first version as “one person completes one task and gets a checkable result”, then cut features to fit.
References
This article combines public sources with SWYZL & Co.’s recommended methods. The hypothetical scenarios illustrate design thinking and do not represent client results.
