If you have a model and no product, you do not have a marketing problem yet. You have a research problem. The job is to find credible problems your technology can solve, find the people close enough to those problems to teach you something, and turn what you learn into a product direction. Design partners are what that process produces when it works.
The proof
The company was a frontier speech-to-speech AI lab with a model but no finished product, website, customer journey or category playbook. I joined as first marketing hire and GTM lead for a two-month engagement.
- Interview participants were sourced and researched with Clay and Apollo, across consumer and enterprise segments.
- A shared research framework was adapted per person, based on their niche, role, company and likely workflow.
- 24 interviews were completed and combined with competitor and product research.
- The model was narrowed to two testable use cases.
- The company had two design partners before the wider trial launch, in about two months.
The useful ideas came from specific interviews and observed needs, not from attaching fashionable claims to the technology.
Step 1: List problems, not features
Write down what the model can do, then translate each capability into workflows where it would matter. A speech model is not a use case. “Support teams handling calls in a language they do not staff for” is closer. Aim for a long list of candidate problems across several segments. You are going to cut most of them.
For each candidate, note who has the problem, what they do today, and what it would be worth to them if it went away. Where you cannot answer the last part, that is a question for the interviews.
Step 2: Build the interview list
Pick segments where the problem is likely to be frequent and expensive. Then find specific people inside them.
Clay and Apollo work well here because you can filter by role, company type and size, then enrich each record. The point is not volume. Before contacting anyone, research:
- Their niche and what is changing in it.
- Their role, and whether they actually touch the workflow or just sign off on it.
- Their company: size, tools, and anything public about how they operate.
- Their reason to care: why this problem would be on their list right now.
Outreach should name their situation in a sentence. “We are researching how X teams handle Y, and your role looks close to it” gets replies. “Would you give us feedback on our AI?” does not.
Step 3: Write the research framework
Use a consistent core so interviews can be compared, then adapt the questions to each person’s role, company and behaviour. The core should be about the last real instance of the problem, not a hypothetical future:
- What were you trying to do?
- What did you use?
- Where did it fail?
- What did the failure cost, in time, money or risk?
- Who else was involved?
- What would have to change before you tried something new?
Do not ask “would you use an AI tool for this?” Everyone says yes. Ask how they handled it last week. Behaviour, constraints and the exact words people use are what you are collecting.
Step 4: Run and synthesize the interviews
Write each interview up the same day against the same template: segment, problem described, current workaround, cost, who decides, and quotes worth keeping. After every five or six, look for patterns:
- Which problems repeat across people who do not know each other?
- Where are people already spending money or time on a workaround?
- Which segments describe the problem in the same language?
Combine this with competitor and product research. A problem that repeats, costs real money and is badly served by current tools is a candidate use case. If new interviews keep surfacing new problems, your segments are too broad. Narrow them and keep going.
Step 5: Narrow to testable use cases
Cut to one or two use cases you can actually test. The lab went to two. A use case is testable when you can describe who it is for, what they do today, what changes with your product and how you would measure whether it worked.
This is also where positioning comes from. The language interviewees used to describe the problem becomes the language on the website and in outbound. Translating a technical capability into words a non-technical buyer recognizes is most of the positioning work, and the interviews have already done it.
Step 6: Convert interviewees into design partners
Your strongest design partner candidates are already in your interview notes: the people with the problem at its most frequent and expensive, who engaged most in the conversation and asked what you were building. Go back to them with:
- The specific use case, described in their words.
- What a design partnership involves: access to a real workflow, regular feedback sessions, early use.
- What they get: input on the product, early access, and a product built around their problem.
Two committed design partners with a real workflow are worth more than twenty polite beta sign-ups.
Keep outbound as a research channel
At this stage outbound is for learning, not volume. The same research-first method that recruits interviewees later becomes the outbound motion: signal, researched hypothesis, relevant proof, clear follow-up. Running it as a mass sequence before you know the use case burns the list you will need later.
Who should run this
At a pre-PMF AI startup, the founder or the first marketing hire should own discovery. Whoever runs the interviews hears the customer’s language first, and that language becomes the positioning, the site and the outbound. If nobody on the team has done this before, a startup GTM consultant can set up the framework and run the first round alongside you.
Have a model and need to find the use case and first design partners? Book a diagnostic call or try the free growth tools.