By Vellora Labs · Reviewed October 10, 2026
An interview can explain a person’s experience. It does not, on its own, prove that your product fixes that experience. Keep those two steps separate when turning research into a product story.
1. Start with an evidence record.
For each candidate insight, retain a source ID, the question that preceded it, an exact quotation or observation, and the relevant context. Keep an interpretation in a separate field. Record contradictory examples and gaps rather than dropping them when they make the story less convenient.
Use participants’ words only within the permissions they gave. Consent to a research interview does not automatically authorize a public testimonial. A paraphrase should preserve meaning and should not be formatted as a direct quote.
2. Separate three kinds of statement.
| Statement type | What supports it | What it cannot establish alone |
|---|---|---|
| Research observation | A traceable interview or observed action | How common it is across the market |
| Product fact | A verified current feature or demonstration | The benefit someone will actually achieve |
| Benefit hypothesis | A proposed connection between the two | A proven outcome or numerical improvement |
3. Work through a clearly fictional example.
Teaching example — invented, not a customer quote: imagine a participant saying, “After the meeting I check three places to find who owns the next step.” This example illustrates the reasoning; no interview was conducted for it.
Observation: in that described situation, finding ownership involved multiple sources. Interpretation to investigate: ownership information may be hard to locate. Alternative explanation: the information might be present but the team has not agreed where to keep it.
Now suppose a prototype shows a reviewable list of suggested actions with editable owners. That is a product demonstration, not proof that it resolves the coordination problem. A defensible concept message might be: “Review suggested actions and confirm their owners in one place.” An unsupported leap would be: “Never lose an action again” or “Cut follow-up time in half.”
4. Map each scene to a source.
Use a source ID beside each proposed scene. An invented context scene needs a visible concept/example label. A product screen needs a current version and a check of the interaction it implies. A numerical claim needs its own evidence, including the measure, population, and conditions; remove it if that evidence is absent.
5. Test understanding before polishing the story.
Ask a relevant viewer to explain the product after seeing the concept. Capture what they believe the product does automatically, what they must supply, and what would happen next. If a scene implies a capability that does not exist, change the scene even if viewers say they like it.
Keep an evidence gap as an explicit research question. A story can be clear and still address the wrong need. That calls for another study or a change in product direction, not simply a more persuasive edit.
A review checklist for your next draft
- Can every direct quote be traced to its original context and reuse permission?
- Are research observations, product facts, and benefit hypotheses visibly distinct?
- Did we keep contradictory evidence in the internal record?
- Does the video distinguish a prototype from a released capability?
- Is the next action available, and does it match the promise in the message?
- Which unanswered question will we test next?
Use the worked brief to document this mapping, or the brief builder to create an editable outline. Our video tools collection helps choose a production workflow once the message is ready.
This is Vellora’s editorial method and a fictional teaching example, not a completed client study. TapVid is a product from our team; creating a video with it does not verify a research finding.