Designing a founder interview around a real workflow

Customers may describe a process as “manual” even when several systems are involved. The difficulty might lie in a handover, an approval or information that arrives too late. A founder needs to see the sequence before deciding what to automate.

Choose one completed example

Ask the participant to describe a recent instance using authorised, non-sensitive material. Follow what started the work, the information available and the people involved. When the participant says “usually,” ask whether the selected example followed that pattern.

GOV.UK’s moderated-testing guidance examines people completing specific tasks. Discovery interviews can use the same emphasis on concrete activity without pretending that a conversation is a formal usability test.

Do not request customer credentials or private records merely to make the session feel authentic. A redacted example or recreated task may provide sufficient detail.

Mark the handovers

For each transition, record what the next person needs and what happens when it is missing. A supplier approval might wait because a manager lacks one document, not because the form takes too long to complete.

An illustrative regional retailer could have fast store-level reporting but slow consolidation because branch codes differ. Building a faster entry screen would leave the underlying issue intact. A shared identifier and correction process might be more useful.

Record exceptions alongside normal steps. A workflow designed only around successful cases can underestimate the service burden created by real customers.

Return a process map for correction

Summarise the sequence and ask the participant what is inaccurate. The purpose is to verify understanding, not to obtain approval for the product. If different participants disagree, preserve the variation rather than forcing one universal process.

Next, identify the smallest intervention that would remove a material constraint. State what should change and which existing step remains. That creates a testable starting point for a prototype.

Use a map with one row for each transition: input, responsible role, output and exception. Mark any step observed directly separately from a step described in conversation. The distinction matters when the team later uses the map to estimate integration effort or claim that a bottleneck has been verified.

GAT’s analysis of growth bottlenecks explains why execution can become heavier as companies expand. Workflow discovery gives founders a way to locate that burden before adding another application to it.