Find product problems in real work

An interviewee says an AI document organizer sounds useful. That response may be politeness; it does not establish frequent pain, suitability, or willingness to pay. Product discovery needs evidence from recent work and existing choices before selecting an experiment.

The fictional case concerns preparing learning materials, finding sources, and confirming versions. Interview records, candidate problems, and scores are teaching data, not user histories or revenue results.

Identify actors and situations

Users, buyers, approvers, and affected people can differ. A learner organizes files, a teacher selects materials, and an institution buys software. Interviewing only one role can miss budget, permission, or daily-work constraints.

Describe triggers, timing, existing steps, goals, and limits. Confirming which of three documents applies to tomorrow's discussion is easier to investigate than “intelligent knowledge management.” Describe progress and failure costs before deciding that AI is required.

JTBD examines progress sought in a situation, including functional, social, and emotional dimensions. It explains choices without automatically predicting purchases. Existing alternatives include folders, checklists, asking someone, and abandoning the task.

Ask about recent work

Explore the last occurrence: when it began, steps taken, obstacles, workarounds, and outcome. Avoid unnecessary personal stories and obtain appropriate consent for recording or quotation.

Questions about hypothetical adoption invite speculation. Questions about the last version check reveal behavior. Investigate frequency, time, errors, and existing investment without leading the person toward your explanation.

Return feature suggestions to their causes. A request for summaries may reflect uncertainty about what to read first; more categories may reflect naming problems. Retain suggestions while separating problems from solutions.

Bound evidence by its sample

Recent work, demonstrated alternatives, and actual effort are stronger signals than praise, but one person's difficulty does not represent a market. Record recruitment, relevance, and people who lack the problem.

AI enthusiasts may overstate interest in AI solutions, while friends may be polite. Seek different practices and constraints and retain counterexamples. Three positive comments cannot establish market size or revenue.

Preserve scope and uncertainty when grouping interview material. “The last task was difficult” differs from “every task is difficult.” Remove unnecessary identity clues instead of collecting sensitive stories to make research appear substantial.

Revisit problem and solution choices

The Double Diamond describes expansion and narrowing through discovery, definition, development, and delivery. It supports exploring problems and testing small solutions, with returns to earlier stages rather than mandatory irreversible phases.

An initial summary idea may become a version-confirmation problem after observation. Candidate solutions might be version labels, source lists, or automatic detection. Compare their conditions and costs through evidence.

Identify the riskiest assumption: need, upload willingness, manual review, or cross-device access. A polished interface tests only part of experience, not every demand and payment hypothesis.

Use ranking to plan research

The example multiplies teaching scores for frequency, cost, and evidence. The dimensions and values are chosen rules, not a validated market model.

candidates = [{"id": "A", "frequency": 3, "cost": 2, "evidence": 2},
              {"id": "B", "frequency": 2, "cost": 3, "evidence": 1}]
def score(item):
    return item["frequency"]*item["cost"]*item["evidence"]
ranked = sorted(candidates, key=score, reverse=True)
assert ranked[0]["id"] == "A"
assert score(candidates[0]) == 12
print([(x["id"], score(x)) for x in ranked])

The actual output is [('A', 12), ('B', 6)]. A ranks first because its product is twelve. Scores do not represent revenue, market size, or success probability. Multiplying guesses does not turn them into evidence.

Also consider user reachability, solution cost, alternatives, and purchasing restrictions. Record score support and test sensitivity to changed assumptions. If a small change reverses the order, gather information before treating the ranking as settled.

Make prototype experiments falsifiable

A version-check prototype can ask participants to identify an applicable document from synthetic materials and explain the evidence. Define success and failures such as wrong selection, missing sources, or confusing status before observation.

Human-produced results can support a prototype if its limits are clear. Separate manual effort from future automation costs. Task usability does not establish willingness to pay or continuing use.

If users already finish quickly or the obstacle is permission, revise or stop the proposal. Do not change acceptance rules afterwards to turn a failure into success. State the new hypothesis before another experiment.

Investigate business constraints early

Individuals may pay directly; organizations may require procurement and security review. Identify payers, budgets, trial conditions, and purchasing habits without assuming organizations will pay. Industry categories remain hypotheses.

Hypothetical price answers are not commitments. Scheduling a trial or entering evaluation provides more concrete but still bounded evidence. Real charging requires separate transaction, refund, and business checks; this lesson performs no payment.

Separate quotations, observations, and researcher inference. Spending half an hour yesterday does not establish recurring weekly waste. Retain necessary context and mark hypotheses explicitly. When combining interviews later, return to individual evidence to check whether the conclusion exceeds the sample's scope.

Exercise: produce a refutable record

Choose a document problem and interview about its last occurrence, alternatives, frequency, results, and constraints. Record supporting and opposing evidence and separate users from buyers. Compare two solutions and test one risky assumption.

Accept the record when evidence has concrete context, praise is not demand, scores expose uncertainty, and experiments have failure criteria. Choose further interviews, a prototype, a revised problem, or stopping, and identify the evidence behind the next action.