A spreadsheet can be evidence of demand. It can also be evidence that a spreadsheet works perfectly well.
That distinction is easy to miss when building software becomes cheap. A developer sees someone copying information between two systems, imagines an elegant automation, and starts designing screens. The existing process looks awkward. The proposed application looks obvious. Yet the person doing the work may have no reason to buy it.
Perhaps the task happens twice a year. Perhaps copying the information takes three minutes. Perhaps the delay comes from a supplier who never sends a complete invoice, and a better interface would simply display the same missing information more attractively.
The first job of a software business is therefore to understand a consequential difficulty well enough to know whether software can improve it. This chapter opens The AI Software Factory, a series in the SalarsNet AI section. Its question is specific: what separates an interesting annoyance from a problem worth investigating as a software business?
The answer begins with a person trying to finish something, the obstacle in their way, and the consequences of that obstacle. Those relationships give an idea something to improve.
Start with the work someone is trying to finish
Consider a hypothetical small equipment dealer. A customer brings in a used mower. An employee records its condition, photographs it, checks the model number, looks for comparable sales, and prepares a listing. Another employee later discovers that a photograph shows a different serial number from the intake sheet. The listing needs correction before it can go live.
“Build an AI listing app” is one possible response. It is also premature. The same surface complaint could arise from several different causes: confusing intake labels, photographs uploaded in the wrong order, weak employee training, a missing review step, or an existing system that cannot associate an image with an item.
Each cause points toward a different intervention. New labels might cost less than new software. A structured intake form might solve most of the problem. A software tool might be justified if the business repeatedly moves the same item record between incompatible systems and errors survive despite a sound process.
Describe the underlying job without embedding a solution: when accepting used equipment, the employee needs a trustworthy record linking the physical item, its condition, and its listing information so that the business can sell accurately. This keeps several solutions available while making the desired outcome clear.
The UK Government Digital Service recommends researching users’ goals, present methods, and frustrations, then describing needs in terms of the problem rather than a particular feature. Its guidance concerns public services; applying that discipline to a commercial product is an inference, not proof of market demand. Learning about users and their needs.
An early opportunity note should capture an episode rather than a slogan. Who was doing the work? What triggered it? What information did they need? Where did progress stop? What did they do next? What consequence followed? A recent episode gives the investigation something concrete to examine.
Separate frequency, consequence, control, and ownership
The word “pain” is useful shorthand, but it can obscure more than it reveals. A mild inconvenience, a recurring expense, a serious uncertainty, and a legal exposure require different responses. They also attract different buyers.
For discovery, separate the difficulty into frequency, consequence, controllability, and ownership.
Frequency tells you how often the condition occurs for the same customer. A daily reconciliation error can accumulate into a meaningful burden. An annual filing problem can still be valuable, but its software may face seasonal demand and long gaps between uses. Count occurrences during an appropriate period instead of assuming that a strongly worded complaint describes frequent work.
Consequence tells you what happens when the task goes badly. Time lost is one consequence. Others include a delayed payment, a missed customer response, an incorrect shipment, or information someone cannot trust. An emotional complaint can be entirely real while its commercial importance remains uncertain.
Controllability asks whether the proposed product can change the outcome. A shop may struggle with unreliable deliveries, but software cannot make an unavailable part appear. It might improve prediction, communication, or substitution decisions. Those are narrower promises, and the business must value them enough to adopt the tool.
Ownership identifies who is responsible for the outcome and who can approve spending. The person suffering the problem may lack purchasing authority. A useful application for employees can fail commercially if the owner regards the current process as acceptable or cannot justify a recurring expense.
These dimensions help explain why identical complaints can lead to different businesses. Two people say that invoicing is frustrating. One needs a faster way to create an invoice. The other needs customers to pay. Automating document creation may help the first person and barely affect the second.
Look for the workaround and its cost
A workaround shows that someone has already attempted to make the problem manageable. It might be a notebook, a shared folder, a contractor, an assistant, a spreadsheet, or a rule that experienced employees carry in their heads.
Examine what the workaround accomplishes before criticizing it. A spreadsheet may be easy to inspect, inexpensive to change, and familiar to everyone involved. Replacing it can remove useful flexibility. A notebook can remain available when the network fails. An employee’s judgment can handle exceptions that an automation has not yet recognized.
The interesting question is where the workaround fails under conditions the business actually encounters. Does it break when volume doubles? Does it depend on one person being present? Does it lose the history needed to resolve a dispute? Does it force two employees to repeat the same work?
The U.S. Small Business Administration’s market-research guidance asks prospective businesses to examine demand, alternatives, reach, market saturation, and existing prices. Those questions put a workaround in its commercial setting: it is part of the competition, even when nobody sells it as a product. Market research and competitive analysis.
A hypothetical dealer might spend 20 minutes correcting an item record four times per week. That is 80 minutes weekly. At an assumed labor cost of $24 per hour, including employment overhead, the direct labor value is $32 per week. These are illustrative inputs, not measured Salars results or industry averages.
The calculation is a starting point. It does not establish willingness to pay $32 per week. The correction may occur during otherwise unused time. A new tool could introduce review work. The buyer may distrust the estimate or prefer to fix the intake procedure. Additional benefits, such as preventing an inaccurate sale, also need evidence rather than convenient guesses.
The discipline is to name the cost you can support and leave other consequences uncertain until investigated. An exaggerated estimate can make an ordinary problem appear like an irresistible opportunity. It also creates a product promise the builder may never fulfill.
A complaint is a clue; behavior is stronger evidence
People often describe what annoys them more readily than what they will change. A discussion thread full of complaints can be useful for discovery, but it does not reveal every participant’s budget, authority, or alternatives.
Behavior adds another layer. Someone who has hired temporary help, purchased a competing product, built a complicated workaround, or repeatedly returned to solve the same task demonstrates effort. That effort does not guarantee a sale, but it provides a firmer starting point than an enthusiastic reaction to an idea.
Separate four questions that are often compressed into “people want this.” Do they encounter the problem? Do they regard it as important? Do they seek an improvement? Will they make a particular commitment to obtain that improvement?
The commitments can differ. Sharing a redacted example may support further discovery. Scheduling a trial may support product interest. Paying for a bounded service may support willingness to pay for an outcome. Renewing after using the service provides evidence about continuing value. These are successive observations, not interchangeable votes.
The NSF I-Corps program provides an institutional example of research commercialization organized around experiential learning beyond the laboratory. Its stated mission is to reduce translation risk. That supports taking discovery seriously; it does not establish that a particular interview count or development method guarantees a profitable business. NSF I-Corps.
For methods of finding candidate complaints, see How to Mine the Internet for Profitable Software Problems. This chapter stays with interpretation: what the complaint reveals, what it leaves unknown, and what behavior would clarify it.
Follow the buyer through the whole decision
A product may solve a user’s problem while creating work for someone else. The owner needs to approve it. An accountant needs consistent exports. A support employee needs to understand failures. A contractor may need access without seeing confidential records.
Discovery should include these people when they materially affect adoption. The goal is not to produce an elaborate organizational chart for a tiny app. It is to avoid designing a product around the easiest person to interview while ignoring the person who must operate or purchase it.
In the hypothetical dealer, the listing employee may welcome automatic descriptions. The owner may care more about incorrect condition statements. The person processing returns may need an audit trail showing what the customer was told. A product that saves writing time but weakens the evidence behind a sale can make the business worse.
Ask the buyer what they would stop doing if the tool worked. If nothing would stop, the product may become another layer of work. Ask who would maintain the information, handle exceptions, and verify results. Savings depend on those responsibilities, not just on the speed of generating an output.
Purchasing conditions also shape the problem. A business that cannot install software on its existing devices has a different constraint from one that can adopt a web service immediately. A buyer who needs approval from a franchise operator presents a different sales path from an owner who decides alone.
These conditions influence the first product’s scope. The best first app may serve a narrow buyer group with an accessible decision process, even when another market looks much larger.
Some important problems should not become your first product
Finding a severe problem is exciting. It can also tempt a small builder into a domain whose failure consequences exceed their capabilities.
A tool that influences medical treatment, lending eligibility, or legal rights needs competence and controls appropriate to those decisions. A builder should not reinterpret the existence of pain as evidence that an improvised product is suitable. The issue is practical: can the team deliver the promised outcome reliably, lawfully, and with the necessary support?
Even ordinary operational software can create harmful surprises. Automatically publishing an inaccurate product description can produce disputes. Automatically contacting customers can send inappropriate messages. Automatically changing inventory can sell an item that is unavailable.
Define the action boundary while describing the problem. A first version could prepare a draft that a human checks. It could flag conflicting records without deciding which one is correct. It could calculate a comparison without committing a purchase. These designs may provide useful value while preserving a clear review point.
The existing permission architecture chapter develops those authority boundaries. Here the discovery implication is simple: a proposed solution’s risk belongs in the opportunity assessment from the beginning.
There are also problems that software can solve technically but cannot serve economically. A customer may need extensive individual configuration, have little repeat usage, or require support at times a small operator cannot cover. Discovering those conditions early is a valuable result. It prevents a painful customer problem from becoming an unmanageable supplier problem.
Write a problem brief that can be wrong
An early brief should be short enough to change and precise enough to challenge. For the dealer example, it could read:
Independent used-equipment dealers with several employees sometimes lose the connection between intake photographs and item records. During listing preparation, employees spend time reconciling mismatches, and some records require owner review. We propose investigating whether a structured intake workflow reduces correction work enough to justify adoption. Frequency, cost, existing alternatives, and willingness to pay remain unverified.
This is a hypothesis, not a product announcement. It names a customer, task, difficulty, proposed mechanism, and uncertainty. It also leaves room for the answer to be a process change instead of a software subscription.
A weaker brief would say that small businesses need an AI platform to optimize inventory. That statement can absorb almost any observation without changing. If users complain about listings, the platform needs listings. If they complain about purchasing, it needs purchasing. The idea grows while the evidence remains vague.
Useful discovery narrows the claim. If mismatches occur only after an employee changes the camera workflow, the problem may be training. If businesses already own a tool with the needed feature, adoption support may be the opportunity. If the correction work is substantial but every dealer stores data differently, the next question becomes whether a bounded service can establish a repeatable pattern.
The brief should record such alternatives explicitly. A competing explanation gives the builder something to investigate instead of treating every observation as confirmation.
Separate a useful internal tool from a sellable product
An internal application can be worthwhile even if no external market exists. A business may have unusual inventory, specific employee habits, or a particular combination of systems. Improving that environment can create real operational value.
Turning the improvement into a product introduces new obligations. Other customers need onboarding, documentation, account separation, support, billing, and a way to leave. Their data and processes differ. Their tolerance for interruptions differs. A solution that works because its creator is nearby to explain every exception has not yet demonstrated product readiness.
This distinction matters especially when AI makes prototypes fast. A working demo proves that a mechanism can operate under the demo’s conditions. It does not prove that strangers can use it successfully or that supporting them will leave a margin.
Treat internal experience as evidence with a scope. If a tool reduces correction work in one store, describe the store’s conditions and how the reduction was measured. Avoid calling the result an industry opportunity until other customers’ behavior supports that expansion.
The next stage, payment validation, examines stronger commitments. Discovery earns the right to ask those questions. It does not skip them.
What Would We Do at Salars?
The proposed Salars approach would begin with an operational difficulty whose records can be examined responsibly: listing corrections, supplier information gaps, repeated customer questions, or the handoff between intake and publication. These are candidate areas, not claims that any measured problem currently exists.
For one candidate, the team would assemble a small set of recent, redacted episodes with the operator’s permission. Each record would identify the task, trigger, present method, failure point, consequence, and person responsible. Customer identities and unnecessary personal information would stay out of the discovery file.
The team would then compare at least two plausible interventions. One might be a process change using the present tools. Another might be a small software aid. The comparison would prevent the investigation from quietly assuming that software is the answer.
A useful next decision would be whether there is enough evidence to offer a bounded improvement trial to a reachable buyer. That trial would have a clear outcome and limits. It would not promise an autonomous venture engine, generalized profit gains, or a platform before the underlying job was understood.
If the evidence showed that the current workaround was inexpensive and adequate, the proposal would close. If it showed a meaningful recurring burden, the team would carry the problem brief into customer discovery and payment validation. Both outcomes would improve the allocation of development time.
The strongest beginning is often an ordinary sentence someone can substantiate: this task keeps going wrong, here is what happens, and here is what it costs us. Software becomes interesting when it can change that sentence.
Sources
- Government Digital Service: Learning about users and their needs, official discovery and user-needs guidance. Commercial application in this article is the author’s reasoning.
- U.S. Small Business Administration: Market research and competitive analysis, official guidance on demand, alternatives, reach, and pricing.
- National Science Foundation: I-Corps, the program’s stated purpose and experiential commercialization approach.
Sources inspected October 7, 2026. The equipment-dealer example and cost calculation are hypothetical; the Salars section describes proposed work.
Loading comments…