Customer research for Referral software

Define the question before collecting names

For referral software, investigate whether the team cannot tell which referrals produced an eligible new customer. Research is useful when it explains a workflow, its owner, and an unresolved constraint. A list of companies in a sector cannot establish that those companies have this problem.

Begin with satisfied customers inviting appropriate peers and check how their work relates to a growth owner designing a customer referral program. Map the current process around coupon codes reconciled manually in a spreadsheet. You are looking for the step where the workaround stops being adequate, rather than asking people to validate an abstract product idea.

Search for the language of the problem

Try the queries below in a search engine or the search feature of a relevant professional community. Read the original discussion and its date. Results are starting points for research; these query examples do not claim any particular search volume or the existence of a matching prospect.

Write an evidence note you can revisit

Illustrative source text: “Our customers already introduce friends, but we lose track of which introductions qualify for the reward. How do we reconcile this?” Save the actual source URL and date when researching a real example. Keep a short relevant excerpt and your interpretation in separate fields. Do not rewrite your interpretation as something the author said.

The working hypothesis is that a small manual referral experiment has produced enough activity to strain reconciliation. The missing information includes whether the author is a growth owner designing a customer referral program, whether the need is still open, and which implementation requirements remain unverified. Keep this constraint visible: reward rules and abuse controls need explicit definitions before automating payouts.

• Observed: the original words, the visible date, the task described, and any explicit requirements.
• To verify: whether the current process is coupon codes reconciled manually in a spreadsheet.
• Disqualify when the need belongs to teams expecting a referral tool to create product satisfaction or guarantee viral growth.
• Next step: one context-appropriate question, or no contact when there is no suitable route.

Use a short discovery interview

Ask about a recent event before showing your product. Let the person explain the sequence in their own words; do not treat agreement with a leading question as validation.

• What verified event makes a referral eligible, and what invalidates it?
• Who resolves duplicate attribution, refunds, or a disputed reward?
• What would need to be true for you to trace a test invitation through an eligible event and an ineligible event without issuing real rewards?
• How would you verify that a qualifying test referral is attributed once while the ineligible case is excluded?

Turn notes into a research decision

Compare independently sourced accounts of the same task. Keep an example that contradicts your hypothesis, such as this ambiguous scenario: A founder wants rewards to compensate for a product nobody uses yet. It may justify more reading, but it is insufficient to label someone a buyer.

At the end of a bounded research session, decide whether to narrow the audience, ask a specific follow-up, change the pilot, or stop. Keep unknowns visible and store only the information needed for that decision. Research quality is measured by a better decision, not by how many names are collected.