Competitor research without confusing assumptions with evidence

A competitor's website can tell you what it advertises. It rarely tells you the whole story about customer satisfaction, usage or business performance. Useful research preserves that distinction instead of turning every visible claim into a market fact.

Record what you can actually observe

Capture the source URL, date, published price, billing interval and the features explicitly described. Keep the context: a per-seat monthly price billed annually is different from a one-time personal license. If a capability is unclear, record it as unclear rather than assuming it is absent.

Separate interpretation from the source

You may interpret a complex pricing page as a sign that a product serves teams. That can be a useful hypothesis, but it is not proof that independent users are poorly served. Label the interpretation and decide what would test it: interviews, a hands-on trial or a review of documented workflows.

Study the alternatives people use today

The alternative to your app may be a spreadsheet, a document, a folder or doing nothing. Include those choices in the research. Ask what triggers a person to change their current process and what they would lose by moving. A list of competing software features will miss those costs.

End with a decision or a direct test

For each important finding, state what it changes about the customer, scope, pricing or distribution plan. Where the evidence is weak, define the next direct test instead of assigning false precision to a score. Public web research is useful context; it does not validate demand or willingness to pay by itself.

Product Vector separates evidence collection from evaluation and plan refinement. Keep the source material, inspect the proposed conclusions and choose the changes you want to adopt. That makes it easier to explain why the product plan changed later.