Clients are sometimes surprised that our first week produces no designs and no code. It produces something more useful: an accurate picture of how the work actually runs today.
Day one and two: sit with the people who do the work
We spend time beside the people who will use the software, not just the people who commissioned it. We watch the real process: the spreadsheet that holds it together, the WhatsApp group where exceptions get resolved, the step everyone skips because it doesn't make sense.
If we can't fit the problem on a page, we don't understand it yet.
Day three: write down the gap
There is always a gap between the process as the policy describes it and the process as it runs. That gap is where software goes unused, so we document it plainly: what the policy says, what people actually do, and why.
Day four: define the problem in one page
One page, no more: the problem, who has it, what it costs today, and what a successful first release would change. If we can't fit it on a page, we don't understand it yet.
Day five: agree what comes next
We end the week by playing it back to you and agreeing the scope of the next two weeks, usually a product definition and a clickable design of the core flow. You see everything we found, and you keep it, whether or not we build the software together.
It feels slow for about three days. Then it saves months.
