Choose the next useful improvement before you build

A website project might begin with a design reference. An internal tool might begin with a spreadsheet someone is tired of updating. Sometimes the starting point is less clear: work keeps getting stuck, and you’re unsure which part needs attention.

Before deciding what to build, describe what you want someone to be able to do. That gives the project a task to work towards and a way to discuss whether the first release is useful.

Start with a moment you can describe

Choose one person and one task. What are they trying to do? What do they open, read or enter? Where do they stop, ask for help or repeat a step?

For an illustrative example, imagine a service business whose offers are explained in several PDF files. A prospective customer reads them but still has to ask which service fits their situation.

“We need a better website” leaves a lot open. “Visitors should be able to compare our services and choose the right enquiry route” gives the team a specific decision to support.

Your starting point might be a staff request, a booking or a report. The useful detail is the action someone is trying to complete.

Choose the kind of work the task needs

If the problem is still unclear, the next piece of work may be a review of the current setup and a short plan. It should leave you with a priority, a reason for choosing it and the questions that still need answers.

If the task and requirements are already clear, you can discuss a build: a website, app, internal tool or another piece of software. An existing brief can be the starting point.

If the task crosses tools, look at the handoffs. What information moves, who receives it, and how does the next person know it is ready? An integration needs those decisions as well as a technical connection.

If you’re considering an agent, define a bounded job first. Which actions may it take? Which need a person’s approval? What examples will you use to assess the result? A pilot can help you examine those questions before deciding how much responsibility to give it.

The answer may combine approaches. You can still agree on which part to address first.

Make the first result possible to check

Return to the service business example. A first result might be a page where someone can compare the relevant services and reach the appropriate enquiry form.

A useful walkthrough would follow that person from the service page to the confirmation. It would also check what they see when the form cannot be sent and how the receiving team finds the enquiry.

This walkthrough covers only part of a test plan. The project will have other requirements, such as accessibility, permissions or content accuracy, depending on its scope.

Writing the walkthrough down helps everyone discuss the same result. It also gives unfinished work a clear place in the conversation.

Keep a short record of the decision

You can capture the starting point in a few lines:

• Problem: What is difficult or unclear now?

• Setup: Which people, tools and materials are involved?

• Useful result: What should someone be able to do?

• First check: How will you see that it works?

• Open question: What must you still find out?

Keep the open question visible. If you don’t yet know who should receive an enquiry, that decision belongs in the work. A new form won’t answer it by itself.

At WGMI, we help people work through these choices and build the software and systems that follow from them. The scope starts with the result you need and what you already have.

Use the five prompts above to write a starting note for one improvement you’re considering.

Prepared for WGMI with AI assistance.