Before the Software, Name the Decision

Imagine a team preparing to buy new software. The demonstration looks polished. Everyone recognises a feature they have wanted. Then someone asks a quieter question: “Which decision will we make better because we have this?”

It is a hypothetical scene, but the question belongs in almost every technology purchase.

My direct answer is this: before buying software, write down the decision it should improve, who makes that decision, and what evidence they need. If that sentence is unclear, I would pause the purchase—not because technology cannot help, but because its purpose is not yet clear.

A tool is not yet a reason

As Founder & Growth Head at Vahmine Technologies, my work spans enterprise SaaS, product building, and technology consulting. Across Toolyt, Dale, Acadle, and enterprise automation services, I think about the relationship between what software enables and what people actually need to do.

That relationship is easy to blur during a buying process.

“We need a dashboard” describes an interface. “We need automation” describes a capability. Neither tells me which choice becomes easier, faster, or more dependable.

I would rather begin with something concrete: a sales manager needs to decide which field activities require attention today. A learning administrator needs to decide where additional support is needed. A product team needs to decide which parts of an interactive demonstration deserve revision.

These are possible decisions, not claims about any particular implementation. Their value is that they give the conversation a centre. Features can then be examined against a purpose rather than admired in isolation.

Write the sentence before the requirements

The sentence I would put at the top of a consulting brief is simple:

“We need to help [person or role] decide [specific choice], using [relevant evidence], so that [desired outcome].”

Writing it forces useful disagreements into the open.

One person may believe the problem is missing information. Another may believe the information exists but arrives too late. A third may point out that nobody has the authority to act on it.

Those are different problems. Buying the same software for all three without understanding the distinction is a poor starting point.

I also want to know how the decision is made today. Is someone comparing spreadsheets? Calling colleagues? Relying on experience? Waiting for approval?

The existing method may be imperfect, but it usually contains knowledge worth preserving. A replacement should not discard that knowledge merely because the new workflow looks cleaner.

For me, consulting begins with understanding the work well enough to distinguish a technology gap from a responsibility gap, a process gap, or a question that leadership has not resolved.

Let the decision shape the demonstration

Once the decision is clear, I would change the way the team evaluates software.

Instead of asking only for a broad product tour, I would ask the vendor to show the path from evidence to action. What does the responsible person see? What remains uncertain? What can they do next? Where does human judgement remain necessary?

A screen full of information is not automatically useful. It may simply move the burden of interpretation onto the user.

This matters especially in enterprise software, where the person purchasing a system may not be the person using it each day. A convincing demonstration for leadership can still leave the daily user with more steps and less clarity.

I want both perspectives in the room. Leadership can explain the intended outcome; users can test whether the proposed workflow makes that outcome realistic.

Sometimes that examination supports the purchase. Sometimes it suggests a smaller configuration change, clearer ownership, or a simpler process. I consider those legitimate consulting outcomes too.

A checklist before the commitment

Before approving a purchase, I would ask the team to complete this checklist in plain language:

• Name the decision: What specific choice should improve?
• Name the owner: Who makes it, and who can act on it?
• Describe today: How is the decision currently made, and where does that method struggle?
• Identify the evidence: What information is needed, and can we trust and maintain it?
• Test the workflow: Can a user move from information to action without unnecessary effort?
• Define improvement: What observable change would tell us the software is helping?
• Consider the alternative: Could an existing tool or a process change address the need?
• Plan the review: Who will check whether the intended improvement actually happened?

I would keep these answers beside the requirements document, not buried beneath it.

Technology consulting should help an organisation become clearer about its work, not merely more confident about a purchase. Building products makes me value what software can do. It also makes me careful about asking software to solve a problem we have not named.

Before the next demonstration, I would leave one sentence waiting on the page: “The decision we need to improve is…”

Completing it honestly may be the most useful work we do before buying anything.