Research protocols · Practical guide

Founder outreach workflow interview protocol

Where does a founder’s recent outreach workflow compete with product, support and sales responsibilities? Use this proposed protocol to collect and interpret evidence.

Reviewed · Examples are illustrative

Who this helps: Teams collecting evidence. Limited software observations are identified separately from unperformed campaign experiments and participant studies.

Define the decision

This page is a proposed research protocol, not a completed study or a report of findings. The decision is: Where does a founder’s recent outreach workflow compete with product, support and sales responsibilities? The observation unit is one founder reconstructing a recent working week. Define the population and owner before collecting records; do not substitute an available convenience dataset without documenting the change.

Work through the procedure

  1. Recruit people at the intended stage and record team size, sales motion and current tooling. Avoid selecting only enthusiastic product users.
  2. Walk through the last outreach session from research to reply handling. Ask about interruptions, postponed actions and decisions delegated to others.
  3. Before collection, write the primary outcome, observation window, exclusion rules and stopping conditions. Preserve excluded observations with a reason rather than quietly removing them.
  4. Pilot the procedure with fictional or owned test data, resolve ambiguous fields, and freeze a dated protocol version before the main run.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

prompt: show the last time you stopped preparing outreach to handle another task; follow-up: how did you know where to resume?
Suggested record fields: observation_id, condition, evidence_reference, outcome, exclusion_reason, reviewer, protocol_version
Status: illustrative record only; no study has been run for this page.

Read the result

Map observed handoffs and unfinished tasks to design opportunities. Do not equate a requested feature with a proven solution. Keep the numerator, denominator and missing evidence visible. If the available observations cannot answer the registered question, report that limitation rather than selecting a more favorable metric after collection.

Collect the evidence

Observation unit: founder-interview.

Consenting founders at the intended stage, including non-users when possible.

Reconstruct the last actual session; do not present feature suggestions before observing the problem.

Analysis: Observed handoffs, interruptions and unfinished tasks; retrospective reports need corroboration.

Download the JSON collection template under Source references. Set an owner, eligibility rules, outcome definition, observation window and sample justification before collecting records. Templates contain no participant data or results; keep original private records outside the public website.

Check before moving on

  1. Name the person responsible for collection and review.
  2. Check that the evidence can be inspected without exposing private messages or credentials.
  3. Record deviations from the protocol and analyze their possible effect.
  4. Retain a dated, redacted evidence worksheet with the final interpretation.

Limits and next action

Interview accounts are retrospective and may omit routine work. Validate important patterns through consensual observation or a later diary study. Publish results only after the evidence, method and limitations have been reviewed. This protocol provides no benchmark, expected lift or completed-study claim.

Source: Method or workflow reference

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow