Ideas

Start with the work, not the software.

The best digital decisions begin with the work people are trying to complete, not with a preferred tool or technology.

Start with the work, not the software.

Software is a choice you make later. First understand the work: who does it, why it matters, where it breaks and what a better result would look like.

Technology is usually introduced too early

Digital projects often begin with a product name: a CRM, a portal, an AI assistant, a new website, a workflow platform. Once the tool has been chosen, the project quietly reorganises the work around the capabilities of that tool.

That reverses the order. The first job is to understand the work as it exists today.

Observe the work in its real form

What triggers the work? Who receives it? What information is missing? Where is judgement required? Where does somebody wait, copy, reconcile, re-enter or chase? Which parts are exceptions, and which parts happen every day?

Do not study the screen first. Study the path from a real need to a finished result.

Question 01What starts it?Identify the event, request or need that creates the work.
Question 02Where does it stall?Find waiting, ambiguity, rework and avoidable handoffs.
Question 03What counts as done?Define the outcome before defining the software.

Find the friction before listing features

A good discovery exercise produces a friction map, not a feature wish list. It distinguishes between problems caused by poor information, poor sequencing, unclear ownership, duplicated effort and genuinely missing capability.

Some friction disappears through better language or clearer responsibility. Some needs a small automation. Some needs a new data model. Only a smaller portion requires a large new application.

The system should be the consequence of understanding the work — not the starting assumption.

Choose the smallest mechanism that changes the outcome

Once the work is understood, the digital response becomes easier to size. A form may be enough. A shared operational view may be enough. A full platform may be justified only when persistent state, complex rules or many participants truly require it.

This is one of the most effective ways to avoid over-building: solve the work at the level where the problem actually exists.

Measure the work, not the installation

A project is not successful because software has been launched. It is successful when the underlying work improves: fewer unnecessary handoffs, clearer decisions, shorter waiting time, better evidence, less rework or a better customer experience.

The implementation can change. The outcome is what should remain stable.

Explore solutions →Discuss a workflow →