Ask a pharmacy owner if they want software that predicts what stock to buy, flags unusual sales, or helps prevent stockouts. They’ll probably say yes.

These features sound useful, especially for pharmacy owners trying to manage inventory, reduce waste, and make better business decisions. But there is a problem: saying yes to a product idea doesn’t mean someone will actually use it.

A pharmacy owner might express interest in new pharmacy management software and still rely on a notebook, spreadsheets, supplier recommendations, or years of experience to make daily decisions. A few weeks after implementation, the software could become another tool nobody opens.

So, what went wrong? The product might work exactly as designed. The features might even solve problems the owner recognises. Yet something is missing: a clear understanding of how people work, what influences their decisions, and what would make them change their habits.

After spending much of this year learning how pharmacies operate, I’ve realised that identifying a problem is only the beginning. The real challenge is building something people have a genuine reason to use.

1. Ask Better Questions Before Building

When developing pharmacy management software, it’s tempting to ask potential customers, “Would you use a tool that predicts what stock to buy?”

It seems like a reasonable question, but it often produces an unreliable answer. People can easily imagine using something helpful, particularly when they don’t have to spend money, commit time, or change their routines.

A better approach to product validation is to ask:

“What would you decide differently if you had this tool, and what do you do today instead?”

That question changes the conversation. Instead of discussing an imaginary future, you begin to understand what happens in the pharmacy today.

For example, imagine a pharmacy owner who regularly runs out of essential medicines. How do they decide what to reorder? When did they last experience a stockout? How do they know which products will sell quickly, and what happens when their predictions are wrong?

Perhaps they check sales records, rely on personal judgement, call a supplier, or consult a more experienced colleague. Whatever their current approach, it tells you something important about their workflow and the alternatives they already have.

These details help you understand how frequently the problem occurs, what it costs the pharmacy, and whether a new solution would make a meaningful difference.

If a customer cannot describe a specific problem, decision, or limitation, you may have an interesting idea rather than a validated need.

And that distinction matters. A feature can sound impressive during a product demonstration without offering enough value to change anyone’s behaviour.

2. Talk to the People Who Will Actually Use It

Once you understand the problem, the next step is to identify everyone involved in solving it.

Pharmacy owners often approve software purchases and make major business decisions. However, they may not be the people who interact with the software throughout the day.

A pharmacist might monitor stock levels, a cashier might record sales, and an inventory officer might handle restocking. Each person experiences the workflow differently.

Consider a tool that sends alerts when sales look unusual. The owner might love the idea because it promises better oversight. But the pharmacist receiving those alerts may have a different experience. If the notifications interrupt their work, appear too frequently, or fail to explain what action they should take, they may start ignoring them.

Eventually, even an accurate alert system can become ineffective if nobody pays attention to its warnings.

This is why user research should involve more than the person who approves the budget.

Ask the people who will use the software every day:

• “Which part of your work takes more time than it should?”

• “What do you currently do when this problem occurs?”

• “What would make you ignore an alert from this system?”

• “What would make you stop using this tool after a few weeks?”

These questions uncover practical barriers that a sales conversation might miss.

More importantly, they help product teams design pharmacy management software around actual working conditions rather than assumptions about how a pharmacy should operate.

The same principle applies beyond healthcare technology. Whenever a product changes how people work, the people closest to the daily process can reveal problems that decision-makers might overlook.

3. Look Beyond Positive Feedback

Positive feedback can make a product idea feel promising. However, customer enthusiasm is not the same as product-market fit.

People may praise a product because the idea sounds useful, because they want to encourage its creator, or because they can imagine a future benefit. None of these responses necessarily means they will adopt it.

A genuine customer need usually reveals itself through existing behaviour: decisions people struggle with, problems they repeatedly encounter, and compromises they accept because better alternatives are unavailable.

In pharmacy inventory management, for example, a real need might involve repeatedly losing sales because essential medicines are out of stock, tying up money in slow-moving products, or spending hours reconciling inventory records.

These are problems a product team can investigate, measure, and attempt to solve.

The next step is to test whether the proposed solution actually improves the situation. Start with a small group of pharmacies, observe how staff use the tool, and gather feedback after they have had enough time to incorporate it into their routine.

Pay attention to behaviour, not just what people say.

“Would you use this?” tells you what someone thinks about an idea. “Show me how you handle this problem today” tells you what you need to understand before building a solution.

Do customers return to the tool? Do they act on its recommendations? Does it save time, improve purchasing decisions, or reduce avoidable stockouts? Would they continue using it if they had to pay for it?

These observations provide stronger evidence of product-market fit than a list of features customers initially approved.

The goal is not simply to build software that customers like during a demonstration. It is to build something they continue using because it solves a problem important enough to justify changing their routines.

Build for Real Decisions, Not Polite Agreement

Building useful pharmacy technology requires more than identifying features that sound impressive. It requires understanding how pharmacy teams work, what influences their decisions, and which problems justify changing established routines.

That understanding should shape every stage of product development, from customer discovery and product validation to software design, testing, and implementation.

Sometimes, the best outcome of customer research is discovering that a proposed feature is unnecessary. Other times, it means finding a more urgent problem that the original idea overlooked. Both outcomes can save time, money, and effort that would otherwise go into building the wrong solution.

The next time someone asks whether a product would be useful, try asking a different question:

“What would you do differently if you had it?”

You might get fewer enthusiastic yeses. But you’ll gain something far more valuable: a clearer understanding of the problem, the people experiencing it, and whether your solution deserves to be built.