“We need a new application” sounds like the start of a software project. Usually, it’s the middle of a much more interesting conversation.

Something is taking too long. Customers are asking for updates. People are re-entering the same information in three places. A spreadsheet has quietly become the most important system in the business.

The temptation is to jump straight to features. A dashboard. A portal. Some automation. But building the wrong thing efficiently still leaves you with the wrong thing.

Start with the work, not the wish list.

Before deciding what to build, follow one real task from beginning to end. Watch how someone receives a request, finds the information they need, makes a decision, and hands the work to the next person.

Ask where they pause. Ask what they copy. Ask which steps require someone who “just knows how it works.” These details reveal more than a list of requested features, because they show the gap between the official process and the one people actually use.

Include the exceptions. The ordinary case may already work reasonably well. The late change, the missing detail, or the unusual customer request might be where most of the time disappears.

A useful brief describes a change in the business—not just a thing to put on a screen.

Give the problem a useful shape.

“We want a customer portal” is a proposed solution. “Our team spends two hours a day answering status questions because customers can’t see where their job stands” is a problem you can investigate.

The second statement gives you people to talk to, a workflow to observe, and a result to measure. It also leaves room for a simpler answer. Perhaps a portal is right. Perhaps a clear automated update solves most of the problem at a fraction of the effort.

Try writing a short brief with four parts:

  • Who is affected? Name the people doing the work or waiting for it.
  • What gets in their way? Describe a specific, recurring situation.
  • What does it cost? Think in time, errors, missed opportunities, or avoidable frustration.
  • What would better look like? Choose an observable change you can check after launch.

Map what already exists.

A new tool rarely operates alone. It needs data from somewhere, must fit someone’s habits, and may need to work with a system that cannot easily change.

List the current tools, the owner of each important piece of information, and any constraints around access, privacy, or approvals. This isn’t paperwork for its own sake. An integration that looks trivial from the outside can become the center of the project once its limitations are understood.

It also helps you avoid replacing a tool that does its job well. Often, the missing piece is the connection between systems rather than an entirely new system.

Choose one meaningful first improvement.

When the problem is clear, resist solving every related problem at once. Find the smallest complete change that someone can actually use. Not half of ten features—one useful workflow from start to finish.

Agree on how you’ll know it helped. That might mean fewer manual handoffs, less time to prepare a quote, or fewer requests disappearing between teams. Establish a baseline before building so you have something honest to compare.

Then put the improvement in people’s hands and pay attention. Real use will tell you what deserves the next investment.

A better starting question.

You don’t need a perfect specification to begin. You need access to the people doing the work, a willingness to question the first proposed solution, and a clear sense of what would make their day better.

Instead of “What features should we build?”, try: “What is harder than it should be, and what would change if we fixed it?”

That’s a much stronger foundation for useful software.