← All articles

Product planningCodeCraft team

How should you prepare for a new business system?

Start with a real piece of work. The people, information and hand-offs involved will tell you more than a list of feature names.

A list of accounts, notifications, reports and an admin area sounds like a useful brief. It still leaves important questions open: when is a message sent, where do report figures come from, and which teams may see the same data? Feature names alone do not describe the work.

Follow a recent task

If the goal is to move applications online, take one recently completed application. Trace how it arrived, where staff checked it, how missing information was requested and who confirmed the outcome. Existing forms, spreadsheets and messages reveal more than a discussion about the home screen.

Ask the people doing the work which step sends them back to search for information and what is most easily missed when they are busy. The answer may be clearer status and hand-offs rather than more fields.

Include the cases that do not follow the happy path

People enter the wrong details, documents need resubmission and approvers may be away. These cases affect who may change a record, which stage it returns to and who receives a notification.

You do not need an exhaustive catalogue of exceptions. A few recent cases that required manual handling show who made the decision and how it was recorded. That is enough to discuss which cases the system can handle and which still need a person.

Make the first release useful end to end

The first release does not need every team and report. Give one group a complete task they can finish. If they must return to an old tool halfway through, decide whether that hand-off is intentional or a gap.

Prioritise by asking whether the task can finish without a feature and whether there is a workable alternative for now. That gives a clearer boundary than collecting each team's favourite features.

What to bring to the first discussion

Bring one real task, the forms or screens used today and the part that most needs improvement. Remove sensitive information from examples. Feature choices and screen design can follow once the work is understood.

A budget range and a target date help the team explain what can be done first and what needs more discussion. You need not design every screen in advance.