Separate a real problem from a reason to change
A customer describes the inconvenience clearly, likes your prototype, then keeps using the old solution. Before adding features or lowering the price, ask what changing would require. Switching costs are the money, effort, disruption and uncertainty involved in moving from the current method to another one. A useful invention can still ask for more change than its benefit justifies.
This guide is for testing that transition before committing to production. Start with our comparison of real alternatives if you have not established a useful advantage. Here, the question is narrower: can a likely customer get from today's setup to repeated use of your product under conditions you can actually offer? The workshop example and trial record below are hypothetical editorial tools, not results from customer testing.
Strategyzer's discussion of new customer pains points out that adopting a solution can introduce work that did not exist before. Treat that as a question to investigate. Do not assume every refusal is a learning problem: the underlying need may be too small, infrequent or poorly matched to the person you approached.
Reconstruct the last decision, including who had to do the work
Ask the person to describe the last time the problem occurred. What did they do, how long did it take, and what happened afterward? Then ask about the last comparable tool they adopted or rejected. Follow the sequence from first interest to actual use. Avoid asking only whether they would switch to an ideal future product.
Write down who chooses, pays, installs, learns and maintains the product. In a small workshop these may be different people. A manager may value faster work while a technician must spend an evening sorting parts. A positive interview with the buyer does not establish that the person doing the changeover has time or permission.
Intercom's onboarding guide describes competing attractions and concerns during adoption, including different needs among participants. Its examples concern software. For a physical invention, investigate the actual people and tasks rather than importing a software onboarding sequence unchanged.
Useful questions include: “What would you have to move first?”, “Who else uses this setup?”, “When could you try it without interrupting work?” and “If it failed halfway through, how would you finish the job?” Record specific answers and unresolved questions separately. “Drawer dimensions not measured” is more actionable than “customer resists change.”
Make a transition ledger before offering a trial
Separate costs paid once from burdens that recur. Also record conditions that must be satisfied regardless of an attractive average saving. A tray that does not fit the drawer is a compatibility problem; a lower price does not make it fit. The following categories are a proposed working checklist, not a standardized scoring system.
| Type | Workshop example | Evidence to collect |
|---|---|---|
| One-time spending | Tray, adapter and delivery | Complete proposed purchase cost |
| One-time labor | Sorting parts, fitting, labeling and learning | Time for every person, including the helper |
| Repeated burden | Extra cleaning or returning compartments | Full task cycle over real opportunities |
| Compatibility condition | Drawer clearance and shared storage needs | Measured fit and approval from affected users |
| Disruption and recovery | Bench unavailable during setup; restoring the old arrangement | Elapsed interruption, recovery steps and required help |
Keep labor and elapsed downtime distinct. Two people working for one hour use two person-hours, although the bench is unavailable for only one hour. Do not charge both that labor and an identical labor-based downtime estimate in the same total. Add a separate lost-output amount only when it represents an additional, supported consequence.
Ask which uncertainty matters enough to stop the trial. Do not assign invented dollar values to every concern. A written fallback plan or a fit check may answer the question more honestly than a score of “7 out of 10.” The old product's original purchase price is also different from spending caused by switching now; include remaining obligations or a realistic resale value only when relevant and documented.
Worked hypothetical example: a faster tray with a slow transition
Imagine a removable parts organizer proposed for a repair bench. Keeping the existing parts box requires no new purchase. Assume the new tray costs $120, its required adapter costs $30, and sorting plus instruction takes two person-hours. For illustration only, value that time at $30 per hour. The combined initial spending and assigned labor value is $210: $120 + $30 + (2 × $30).
Suppose the proposed tray saves 45 seconds on each parts-picking cycle but adds two minutes of cleaning per working day. These are invented inputs to show the calculation. In a real assessment, measure both methods under comparable conditions and record the spread of results instead of selecting the fastest demonstration.
| Assumption or calculation | Busy bench | Quieter bench |
|---|---|---|
| Picking cycles per working day | 8 | 4 |
| Gross time saved at 45 seconds each | 6 minutes | 3 minutes |
| Extra daily cleaning | 2 minutes | 2 minutes |
| Net daily time saved | 4 minutes | 1 minute |
| Assigned time value at $30/hour | $2/day | $0.50/day |
| Days to equal the $210 initial total | 105 working days | 420 working days |
Those last numbers are a simple comparison of assigned values, not a forecast of cash payback. Saving four scattered minutes may free some capacity without reducing payroll or creating another billable job. The calculation also omits uncertain costs and benefits rather than silently treating them as known. List any omitted maintenance, delivery, disposal or replacement costs beside the model before using it for a purchase decision.
The useful question is now specific: does this person's real workload produce enough benefit within a period they consider worthwhile? If the net saving is zero or negative, this time-only calculation has no positive recovery period. Other benefits may still matter, but they need their own evidence. Use the problem-frequency worksheet to check whether you have mistaken an occasional annoyance for daily demand.
Test setup and ordinary use as separate stages
Choose a reversible, low-risk trial with a willing likely user. For the tray concept, use one noncritical bench and keep the original parts box available. Confirm fit before moving its contents. Agree how to stop, restore the old arrangement and account for every part. This trial does not establish a product's safety or suitability for a hazardous application.
Write the decision rule before seeing the result. For example, a particular workshop might require setup within its available maintenance window, no misplaced parts, and repeat use without the inventor present. These are illustrative local requirements, not universal thresholds. Ask the workshop what would make the trial worthwhile rather than choosing an easy passing score yourself.
The GOV.UK Service Manual recommends relevant tasks, neutral instructions and observation of actual or likely users. Applying those principles here, ask someone to retrieve the parts needed for a familiar task. Do not lead them through your preferred compartment sequence. Record where help was needed, and distinguish an assisted completion from an independent one.
- Baseline: Observe the existing method, including retrieval and cleanup. Record the task and conditions.
- Changeover: Time fitting, sorting, instruction and interruptions separately. Include the inventor's work.
- Early use: Note mistakes, questions and unfinished tasks. Keep performance and assistance records together.
- Later use: Observe another real opportunity after the initial explanation. Record whether the person chooses and can use the tray again.
- Recovery: Check the agreed return path and record what restoration actually requires.
Do not claim a reliable percentage improvement from a few conveniently selected cycles. Repetition, task differences and coaching can affect the result. A small exploratory trial can identify a specific obstruction worth fixing; it cannot estimate how an entire market will behave.
Use assisted setup to diagnose, then account for it
If setup stalls, offer a clearly documented assisted session as a separate test condition. Preserve the original result. Record exactly what the helper did, how long it took and what the customer still had to do. If later independent use becomes useful, you have a reason to investigate installation or instructions. You have not shown that customers can adopt the original offer unaided.
If hands-on setup would become part of the offer, estimate whether you can provide it at the intended price. Do not hide two hours of founder labor inside a claim that installation takes five minutes. Conversely, do not reject a useful product solely because it needs a service that a customer would knowingly pay for. Test that complete offer separately.
An entrepreneur's Reddit account of unused free access raised both explanations: adoption work may be too demanding, or the problem may not matter enough. This is an unverified software anecdote, not evidence about workshop products. Its useful contribution is the competing question to keep open. Removing the price alone does not test whether removing setup work changes behavior.
Observe the next opportunity and decide what to change
A completed demonstration is only one event. Agree on a follow-up after a genuine opportunity to use the product again. If no relevant task occurs during that period, record “no opportunity” rather than “rejected.” If the task occurs and the old method is chosen, ask what happened and inspect the reason where possible.
GOV.UK's qualitative usability guidance, written for digital health evaluation, notes that a controlled task may not reflect natural use and that unsuitable participants can mislead the research. That methodological limitation matters here too. Our follow-up is an editorial adaptation for a low-risk physical product, not a validated research protocol or a substitute for appropriate specialist testing.
| Observation | Next investigation |
|---|---|
| Setup fails, but assisted setup leads to useful independent use | Simplify fitting or test a fully costed installation offer |
| Setup succeeds, but the full cycle offers little benefit | Recheck the product advantage and problem frequency |
| Useful operation conflicts with other users or equipment | Resolve that compatibility condition before expanding the trial |
| Interest exists, but no practical changeover window exists | Investigate a real replacement or new-bench occasion |
| Repeat use occurs only with constant reminders or help | Investigate dependence on that support before claiming adoption |
These observations suggest the next question; they do not prove a single cause. Test the proposed change with fresh evidence. If the strongest advantage remains small even after reasonable transition work, stop or choose a better-defined use case before funding more features.
Copy this trial record
- Person and task: Who uses, pays, approves and helps? What recent problem occurred?
- Current method: What works well enough to keep, and what measurable burden remains?
- Proposed version: Which exact prototype, price, instructions and support are being tested?
- Transition: One-time spending, person-hours, interruption, fit conditions and restoration plan.
- Benefit: Full-cycle results, real frequency, recurring burdens and unresolved assumptions.
- Decision rule: What evidence would justify the next step? Who agreed to it?
- Follow-up: Next real opportunity, chosen method, help provided and reason for any return.
- Decision: Change setup, change the offer, test another occasion, or stop; name the evidence still needed.
Bring this record to one likely user before your next prototype revision. The aim is to find out whether the product earns its place in a real routine, including the work required to get it there.