The most useful work at the start of a software project is to describe the problem before listing the screens to build. The same problem can have different solutions: configuring an existing tool correctly, changing the workflow or developing a new application.

Which task is difficult today?

Instead of saying “we need an administration panel”, describe where time is being lost. For example, a team may track requests in separate files and therefore perform the same task twice. The need is not simply a screen; it is shared records, clear responsibilities and access to current information.

Write down how often the problem occurs and who it affects. A short weekly task may not have the same priority as work repeated throughout the day. If possible, list the current steps simply.

Who will use the solution?

Job titles alone do not describe users sufficiently. Consider where people work, which device they use and which information they need. Someone using a phone in the field may have different expectations from someone working on a large office screen.

One person might create a request while another approves it. This distinction matters for access permissions and workflows. Discuss from the outset whether every user needs to see all information.

What is truly needed in the first version?

Limit the initial scope to work that solves the main problem. Separate essential features, features that can be added later and work outside the scope. This does not make a feature unimportant; it establishes an order.

For example, shared request records and status tracking may be essential initially, while detailed reports can be considered later. This choice lets you see actual team usage earlier.

How will you know the work is complete?

“It should be easy to use” is understandable but not measurable on its own. A user being able to create a request, an authorised person being able to see it and a status change being recorded are more concrete acceptance conditions.

Write a few real work examples at the beginning. As the project progresses, these examples help check whether the solution meets expectations.

What should you bring to the conversation?

A short problem description, an outline of the current workflow and key priorities provide a good starting point. Not having a technical specification does not prevent a conversation. Make unknowns visible rather than hiding them.

With this information, technology choices have a more meaningful foundation. The first goal is to understand the right problem and its boundaries together, rather than requesting the largest number of features.