Start With the Business Problem, Not the Technology
A practical guide for founders who want to avoid building the wrong solution with great confidence.
By Naresh Sadasivan · Founder’s Guide to Building Technology That Lasts
A Surprisingly Common Starting Point
A surprising number of technology projects begin with a sentence like this:
“We need an app.”
Sometimes it is:
“We need AI.”
Or the more ambitious version:
“We need something like Amazon, but simpler.”
These statements sound like requirements. They are not. They are proposed solutions—usually offered before the real problem has been understood.
That is how organisations end up building expensive systems that technically work, look impressive in presentations, and still fail to improve the business.
The First Question
The first question should not be “Which technology should we use?”
It should be “What problem are we actually trying to solve?”
Technology Is Usually the Most Visible Part
When a business process is slow, confusing, or dependent on too many people, technology becomes the obvious target.
The team may immediately start discussing mobile applications, AI assistants, dashboards, workflow automation, cloud platforms, chatbots, and microservices.
Microservices often appear surprisingly early in these conversations. Nobody is completely sure why, but once the word enters the meeting, everyone nods respectfully.
The real system also includes people, decisions, approvals, exceptions, incentives, data, ownership, and operational rules.
Automating a poorly understood process does not automatically improve it. Sometimes it simply allows the organisation to make the same mistakes faster.
A Simple Example
Imagine a company where vendor invoices take ten days to approve.
Management concludes: “We need an AI-based invoice approval system.”
Before discussing AI, ask why approval takes ten days. Are purchase orders missing? Are approval limits unclear? Are approvers unavailable? Who owns delayed invoices?
Suppose the delay exists because department heads do not approve invoices on time.
AI can extract every field perfectly, classify the invoice, match the vendor, identify the purchase order, and even write a polite reminder.
But it cannot force the department head to click Approve before leaving for a three-day conference.
The business problem is not document extraction. It is approval accountability.
Describe the Problem Without Mentioning Technology
Avoid: “We need an AI chatbot for customer support.”
Instead say: “Support agents spend too much time searching across product manuals, previous tickets, and internal documents before responding.”
That version tells us who is affected, what work they are doing, where the delay occurs, and what information is involved.
- Instead of: “We need a mobile app.”
Say: “Our field employees cannot access job details or update work status away from the office.” - Instead of: “We need a dashboard.”
Say: “Management receives operational information too late to intervene.” - Instead of: “We need automation.”
Say: “Employees repeatedly copy the same information between three systems.”
Understand the Workflow, Not Just the Happy Path
Most business processes look simple in a meeting: a request is submitted, a manager approves it, the system processes it, and everyone is happy.
Unfortunately, real organisations do not operate entirely on happy paths.
- What happens when information is missing?
- What happens when two systems disagree?
- What happens when the approver is absent?
- What happens when the AI is uncertain?
- What happens when the integration fails?
A prototype may demonstrate the happy path beautifully. Production software must survive everything else.
Senior management understands the objective. Operational teams understand where the process quietly catches fire every Tuesday afternoon. Both perspectives matter.
Define the Outcome Before the Features
A project may include login, dashboards, notifications, reports, AI summaries, role-based access, and export to Excel.
Excel will almost certainly appear somewhere. It has survived every technology revolution so far and is unlikely to be defeated by your new platform.
But features are not outcomes. Better outcomes sound like:
- Reduce invoice-processing time from ten days to three.
- Reduce customer response time by 40%.
- Eliminate duplicate data entry.
- Reduce manual document review by 60%.
- Identify operational failures within five minutes.
Without a clear outcome, every feature can be described as important. With a clear outcome, prioritisation becomes easier.
Check Whether the Problem Is Worth Solving
Not every inconvenience deserves a software project.
Ask how often the problem occurs, how many people are affected, what it costs, whether a simpler operational fix exists, and whether an existing product can solve most of it.
Sometimes the answer is custom software. Sometimes it is a process change. Sometimes it is a clearer policy.
And sometimes the answer is a shared spreadsheet with proper ownership—which is not glamorous, but neither is spending twelve months building software nobody needed.
The goal is not to maximise the amount of technology. The goal is to improve the business.
A Practical One-Page Problem Definition
- Current situation: What is happening today?
- Affected users: Who performs the work or experiences the problem?
- Business impact: What does it cost in time, money, errors, risk, or lost opportunity?
- Current workflow: What triggers the process and where does it fail?
- Exceptions: What happens when information is missing, incorrect, late, or disputed?
- Desired outcome: What should improve, and how will success be measured?
- Constraints: What systems, data, policies, budgets, security rules, or timelines matter?
If the team cannot agree on these points, it is too early to debate technology stacks.
Before Approving Development, Confirm That You Can Answer:
- What exact problem are we solving?
- Who experiences it?
- What is the current business impact?
- What outcome must improve?
- What are the main exceptions?
- Who owns the workflow?
- Why is technology necessary?
- How will we know the solution worked?
The Core Lesson
Technology is powerful, but it is not a substitute for clarity.
A well-chosen technology can improve a good workflow. But it cannot rescue a project whose purpose was never clearly defined.
Start with the business problem. Understand the people, workflow, exceptions, ownership, and desired outcome.
Then decide whether the answer is software, AI, process improvement, integration—or something much simpler.
Because the most expensive technology mistake is not choosing the wrong programming language. It is building the wrong solution with great confidence.
MVP Does Not Mean Poorly Built
The difference between deliberately limiting scope and creating technical problems that arrive before your first real customer does.