Before Choosing a Technology, Be Clear About the Business Problem You Need to Solve

The surest way to waste a technology budget is to choose the solution before defining the problem. Before an organization commits to new software, automation or AI, it should be able to say in plain language what isn't working, who it affects, what it costs and what a real improvement would look like. Once those answers are clear, the technology decision becomes far easier. Sometimes it turns out no new technology is needed at all.

Why do technology projects so often start with the solution?

Most technology conversations begin with a request that already contains an answer: a new website, an app, an automation, an AI tool. That's understandable. Vendors demonstrate products, competitors announce launches and every week brings news of what AI can now do. It feels natural to start with the tool.

In our last post, we explained why Myllash now starts every engagement with the business objective rather than the requested technology. This article turns that idea into a practical method you can use, whether or not you work with us.

What's the difference between a symptom and a business problem?

Many projects go wrong because they treat a symptom as the problem.

"Our website isn't bringing in enquiries" is a symptom. The underlying problem could be any of several things:

• the website reaches the wrong audience;
• enquiries arrive but nobody follows up quickly;
• prospects can't find pricing or the next step; or
• the offer itself isn't clear.

Each of these calls for a different response. A redesign fixes only one of them. The others need better follow-up processes, clearer messaging or a connection between the website and the sales team's tools.

The same is true inside organizations. "Staff spend too long preparing reports" might point to disconnected spreadsheets, missing data, unclear ownership or a reporting format nobody actually uses. Each has a different fix.

Five questions that define the business problem

Before choosing any technology, work through these five questions with the people closest to the work.

1. What exactly isn't working? Describe it in operational terms, not technical ones. "Patients miss appointments and the slots go unused" is more useful than "We need a booking app."

2. Who is affected, and where in the process does it happen? Identify the customers, staff or partners involved and the point in the workflow where things break down.

3. What is it costing the organization? Consider lost revenue, staff time, errors, customer experience and compliance risk. Rough numbers are fine. They help you decide how much a solution is worth.

4. What would a meaningful improvement look like, and how will you measure it? Agree on the outcome before the project starts, such as fewer missed appointments, faster responses to enquiries or reports produced in hours rather than days.

5. What constraints must any solution respect? Budget, existing systems, staff skills, regulation, data privacy and internet connectivity all shape what will actually work in your environment.

A simple problem statement template

Once you've answered the five questions, condense them into one or two sentences:

[Who] is experiencing [problem] during [stage of the process], which causes [impact]. We will know it has improved when [measurable outcome].

An illustrative example (not a client case): "Front-desk staff at our clinic can't confirm appointments in advance, so a portion of booked slots go unused each week. We will know it has improved when missed appointments fall noticeably and freed slots are rebooked the same day."

A statement like this gives everyone, including any technology partner, a shared definition of success.

What if the answer isn't new software?

A clear problem statement sometimes shows that new software isn't the answer. The better fix might be:

• changing a process or handover between teams;
• training staff to use tools the organization already pays for;
• connecting existing systems so data stops being re-entered by hand; or
• assigning clear ownership for a task that currently falls between roles.

These options are often faster and cheaper than building something new. A good technology partner should say so.

How does this apply to AI?

Defining the problem matters even more with AI. AI tools can be put to work almost anywhere, which makes it tempting to adopt them everywhere. A useful AI project still starts with the same five questions, plus a few more: what task the AI will perform, what information it needs, and where a person must review or approve its output. We'll explore these questions in more depth in the coming weeks.

How Myllash approaches it

At Myllash Web Services, we start every engagement with the business objective. We work with your team to understand the problem, its cost and what improvement should look like. Then we recommend the right mix of people, AI and technology, whether that's software, automation, systems integration, cloud infrastructure or a change in process. You can read more about how we work.

If your organization is weighing a technology investment, start by writing down the problem. If you'd like help defining it, start a conversation with us.