How can competitor research reveal why people buy?
Use the same task to examine six layers, separate observations from inference, and test a concrete reason to switch.
On this page
Direct answer
The output should be an evidence chain explaining why users choose a product and when they might choose yours. Examine the problem, user journey, delivered result, charging design, acquisition entry points and technical loop. Reproduce a workflow as a learning exercise, then choose a narrow situation for a business experiment. Compare trials, separate fact from interpretation and test migration. A visible interface cannot reveal the actual backend model, conversion rate or profit.
When to use
- You want to learn from an established product but do not know which parts matter.
- A competitor has many features and you need to choose a first version.
Step by step
Find representative products and non-software alternatives for one task
Choose a task you understand and can try, such as improving a résumé or preparing product images. Product directories, public revenue displays and search results can help find direct competitors, free alternatives and manual services. Use directories for discovery, then inspect official sites, actual outputs and user feedback. Record metric names, dates, evidence locations and whether numbers are estimates. MRR, trailing-30-day revenue, visits, active users and profit are not interchangeable. Leave unavailable data unknown.
Run the same input through the complete journey
Prepare anonymized task material and record each step: entry, understanding the promise, beginning, entering input, first perceivable value and usable output. Note requirements, waiting, hesitation and recovery. Inspect only authorized interfaces and mark unpurchased sections untested. Structured fields may reduce uncertainty about what to write; this causal hypothesis is more useful than copying button positions, but its effect still requires testing.
Complete the problem, journey and output layers
State who needs what and when. Record the first user action and where value appears, then retain the deliverable type, quality criteria and editability. “Generates a résumé” is insufficient: can facts be checked, content adapted to a role, and the file exported and submitted? Label every claim as observation, product statement or inference. A screening-success claim is not proof of a higher interview rate. Produce a six-layer table with links or screenshot IDs.
Study charging and acquisition at moments connected to value
Record the trial boundary, paid unlock, charging unit, and whether users already know the result is useful before payment. A résumé tool might charge at generation, review or export; verify current terms rather than using historic limits or prices. For acquisition, record visible query results, discussion posts and referrals. Label third-party traffic estimates separately. Keywords on a homepage do not establish organic-search dependence; advertising does not establish ad profitability.
Propose only the technical loop needed for your version
From inputs, output structures and errors, infer the minimum pages, models or rules, data, state, payment and delivery your own implementation would need. Label it a proposed design, not the competitor’s actual architecture. Compare a learning prototype with the workflow, while using your own brand, copy and assets in a public product. A form plus API describes a functional skeleton, not acquisition, reliability or recurring revenue.
Use complaints and switching barriers to choose an entry
Look for the same task in Reddit, X, Product Hunt, official roadmaps, support or extension reviews. Check the version, independence and whether the issue is already fixed. A useful entry must matter to users, be deliverable and improve on alternatives. Ask whether colleagues or a wider ecosystem must join, whether data must migrate, and whether users must relearn or lose history. Network effects and switching costs are analytical dimensions, not a formula that low network dependence guarantees success.
Test one complete small task rather than a full replacement
Choose an underserved group and workflow segment, with comparable outputs. For example, reduce input preparation for people translating Chinese work history into English résumés rather than rebuilding a job-search platform. Have target users compare quality, time and switching effort on the same material. If someone expresses interest in moving, observe whether they actually transfer a sample and return next time. Produce a differentiation hypothesis, switching barriers and a next validation experiment.
Worked example
Hypothetical exercise: a résumé tool’s journey and value
Imagine a tool with structured input, a result view and feature-based payment. Ask why the form is divided, when users perceive value, which result is ready to submit and why someone would change tools. To serve a group with existing Chinese résumés, try preparation and export tasks and investigate their specific friction and switching cost. This exercise makes no assertion about any product’s current limits, prices, architecture or hiring results; someone else’s revenue story cannot replace your experiment.
Action checklist
Reusable templates
Six-layer competitor worksheet
[Six layers with evidence fields]
Product, official site and observation date:
Task and shared input sample:
Layer | observed fact/product claim | evidence link or screenshot ID | my interpretation | unknown
Problem: audience, trigger, promised result
Journey: entry -> input -> first value -> output -> payment -> return
Output: file/report/image, editability, delivery quality
Charging: trial boundary, charging unit, paid value, untested sections
Acquisition: visible entry points; estimates separately labeled
Technical: my proposed design; unknown competitor internals
Market metric name, evidence location, date and definition:
Free or manual alternatives for the same task:
Complaints and counterevidence:
Network dependencies and switching cost:
One differentiation hypothesis and next experiment:
Same-task trial and prototype review
[Suggested worksheet]
Step | existing product behavior | my learning prototype | effect on the result | supporting evidence
What must users prepare?
Where do they first recognize value?
Which step is unnecessary, and which cannot be removed?
Is the deliverable actually usable?
Does the payment moment align with perceivable value?
Can a failed task resume?
Design decisions I still do not understand:
Learning conclusions:
Commercial assumptions still needing real-user evidence:
Pitfalls
- Attributing revenue to a form and API while ignoring acquisition, delivery, trust and ongoing operation.
- Treating visits as active users or revenue as profit, or presenting historic screenshots as current prices or revenue.
- Copying a brand or page rather than learning the loop and design decisions.
- Using a lower price to conceal gaps in switching effort, quality or reachable users.
- Equating low network effects with easy profits, or creating needless data lock-in to retain users.