Why positive user feedback can fail to become a sale
A warehouse worker may love a new handling aid, while a manager worries about training, maintenance and compatibility. A parent may pay for a product used by a child. A building owner may fund equipment selected by a contractor and operated by a tenant. These are different relationships, and the invention's value must survive all of them.
Do not assume that the most senior person is the buyer or that the person with the strongest opinion controls the purchase. Ask how the last comparable item was actually acquired. The resulting sequence often reveals more than an organizational chart.
Draw the decision map
- User. Who touches the product or performs the task? Record the workflow benefit and any new burden.
- Economic buyer. Whose budget pays? Learn the spending category and what the purchase competes with.
- Technical or operational approver. Who checks fit, safety, compatibility or serviceability?
- Purchasing gatekeeper. Are approved vendors, quotations, insurance documents or ordering systems required?
- Maintainer. Who cleans, repairs, stores and replaces the product? Their burden can overturn a favorable demonstration.
- Influencer or champion. Who is willing to help coordinate the decision, and what authority do they actually have?
NASA: I-Corps frames discovery around customer needs and the business model. SBA: Market research and competitive analysis provides broader market-research guidance. The role map here is a proposed interview tool; it does not imply every purchase has six different people. In a small business, one person may occupy several roles.
Work through a hypothetical hospital-adjacent example
Consider a nonclinical cart accessory designed to keep supplies organized in an administrative stockroom. Staff like the easier access. The stockroom supervisor can approve a trial but not a purchase. Facilities must confirm that the accessory fits existing carts, and purchasing requires an approved supplier. Cleaning staff point out that the first design traps debris.
If the inventor speaks only to users, the product appears ready. Mapping the roles identifies three unresolved requirements: fit documentation, supplier onboarding and cleanability. The next step becomes a revised mockup and a process conversation with purchasing, not a larger batch of samples.
This hypothetical example does not establish suitability for medical use or infection-control requirements. Its point is that the workflow around a product can matter as much as the immediate user benefit. Product-specific compliance and professional evaluation remain separate tasks.
Ask each role a different question
| Role | Useful question | Evidence to request |
|---|---|---|
| User | What happened during the last difficult shift? | Task sequence and workaround |
| Buyer | What funded the last similar purchase? | Budget process and alternatives |
| Approver | What would cause you to reject a trial? | Acceptance criteria |
| Maintainer | What fails or takes longest to clean? | Service history or observed routine |
| Purchasing | What must a new supplier complete? | Actual onboarding steps |
Follow the money without inventing authority
A participant saying “we could buy that” may mean that the idea sounds affordable, not that funds exist. Ask about a recent purchase at a comparable scale: who initiated it, what documents were needed, how long it took, and why it was approved. Do not pressure them for confidential budget details; process information is often enough for early research.
Record whether the benefit and expense fall in the same budget. A device might save maintenance time while its purchase comes from an operations budget that receives no credit for the saving. That mismatch can require a different value argument or sales route. It is not solved by repeating the total savings more loudly.
Recognize vetoes and hidden work
Ask “Who else would need to be comfortable with this?” and “What would make a trial inconvenient?” These questions often expose storage, IT, procurement, installation or warranty concerns. A trial itself may require substantial coordination, so a refusal is not always rejection of the concept.
Do not turn every objection into a feature request. Some are constraints your product must meet; others suggest that the segment is unsuitable. If a $40 accessory requires a six-month approval process, a different channel or customer type may be more viable than trying to optimize the accessory indefinitely.
The deliverable: a purchase-path diagram
Write the sequence from problem recognition to purchase, installation and ongoing use. Beside each step, name the role, required evidence, likely delay and unresolved question. Use job titles rather than personal names in shared documents. Mark assumptions until someone with direct experience confirms them.
The next experiment should address the weakest link. That might be a user test, a maintenance review or a discussion with a distributor. A clear purchase path helps prevent a common mistake: treating twenty enthusiastic users as twenty ready buyers when none can authorize adoption.