Hello, this is Ryuta Hamamoto from TIMEWELL. I spent more than ten years building new businesses inside large companies, ran new-business development programmes, and consulted on business development for large corporations. I led "CHANGE by ONE JAPAN", a challenger-support programme in which more than a hundred large Japanese companies took part, and today I run WARP ENTRE, an AI-driven development programme for founders and intrapreneurs. Drawing on that, this is a four-part series on an AI-native methodology for new business development. Part 1 is about customer interviews.
Series: An AI-native methodology for new business development
There is a failure pattern I have seen more and more in the past year. Have an AI generate customer personas. Have it list their problems. Have it propose solutions. Turn all of it into a polished deck and send it up for approval. Without ever meeting a customer. The deck looks great and the logic holds. It just contains not a single sentence a customer actually said. I call this "new business closed inside the AI". An AI-generated customer hypothesis can only be tested by putting it in front of a customer. This article is about doing that "putting in front" step faster, deeper, and with a record, using AI as the helper.
Summary: Design a 60-minute semi-structured interview in four blocks: past behaviour, problems and workarounds and payment, live mock, wrap-up. No mock in the first half. Prepare three hypothesis screens as a single HTML file with a coding agent beforehand, then swap in the customer's own words within minutes during the second half and capture reactions. Afterwards, hand the transcript to the agent and extract insights with verbatim quotes and timestamps, then update a hypothesis ledger. Every prompt here can be copied as is.
Why "build while you listen"? An AI hypothesis is only testable against a customer
In the old way of doing new business development, weeks separated the customer interview from the prototype. You took notes home, wrote them up, briefed a designer or an engineer, and by the time a mock existed, both your memory and the customer's had faded. At the second interview they would say "that's not what I meant". A month per round trip was normal.
A coding agent collapses that gap to minutes. The moment a customer says "every Monday I copy numbers out of three systems", you can show a rough screen that does it in one. The reaction you get is not a reaction to something described in words; it is a reaction to a picture on the table. "No, we do it at month-start, not Monday." "This column is useless, I need this one instead." Corrections like that come out on the spot.
One thing has to be said clearly, though. What got faster is the building, not the listening. If anything, building got so fast that the temptation to build before listening grew stronger. Getting an AI to describe your customer is easy, and it will produce plausible problems without end. But those are hypotheses. In a study published in November 2024 by researchers at Stanford and elsewhere, 1,052 Americans each gave a two-hour semi-structured interview, and a "generative agent" was built for each person from that record. Agents grounded in the person's own words reproduced their answers with 83% accuracy, measured against how consistently the person answered the same questions two weeks later. Agents built from demographics alone, age, occupation and so on, reached 74%1. There is a clear gap between a persona made of attributes and an agent that has learned from real speech. AI personas become useful only when fed real conversations.
So the order is this. Listen first. Use what you heard as material and build on the spot. Listen again to the reaction. Hand the record to the AI and have it propose what to ask next. The AI is not a substitute for listening; it is the tool that turns what you heard into something visible, and something organised, quickly. If you want a read on how well your team uses AI today, the AI literacy check takes a few minutes.
Designing the 60-minute semi-structured interview
A semi-structured interview fixes the skeleton of topics but leaves the order and the depth to the flow of conversation. Free-form chat cannot be compared across interviews; survey-style fixed questions never reach what people really think. The skeleton is four blocks, sixty minutes in total.
| Block | Time | What you ask | What you do not do |
|---|---|---|---|
| 1. Past behaviour and context | 20 min | The concrete steps, time, people and tools the last time they did "that job" | Explain your business. Show a mock |
| 2. Problems, workarounds, payment | 15 min | The worst moment, what they do instead today, the time and money they already spend on it | "Would you use a feature that…" |
| 3. Live mock | 15 min | Show a rough screen built from their words and ask "what's different?" | Persuade. Collect nice reactions |
| 4. Wrap-up | 10 min | Who else struggles with this, who to talk to next, may we show you again | Talk about contracts |
The key in block 1 is to ask about "the last time", not "usually". Ask "how do you usually do it?" and people describe an idealised average. Ask "when did you last do it, and what was the very first thing you did?" and the real steps come out. Once they do, keep reconstructing the scene: "how many minutes did that take?", "who did you check with?", "what was on your screen at that moment?" The principle I wrote about in The Mom Test technique for drawing out what customers really think applies here unchanged: ask about past facts, not opinions.
Block 2 is where you ask about frustrations with current tools. Three questions work here. First, "if the thing you use today disappeared tomorrow, what would happen?" That tells you how heavy the alternative is. Second, "have you ever considered switching and then stopped? What stopped you?" That surfaces switching costs and the axis the customer actually judges on. Third, "what do you currently spend, in time and money, on this problem?" The "degraded alternatives" I described in How to write an empathy map become concrete here. If someone says they suffer but pays nothing, that problem is not yet a business.
One more technique I always use: three whys. "Copying the numbers is a pain." "Why is it a pain?" "Because the field names differ across systems." "Why does that matter?" "Because when I explain it to my manager I can no longer tell which number is which." By the third why, the real problem turns out to be not the labour of copying but the anxiety of accountability. That is the moment the thing you should build changes.
Rebuild the question skeleton for every business. Paste the following prompt into a coding agent or chat and you get an interview guide in the four-block structure.
You are an expert in designing customer interviews for new businesses.
Create a 60-minute semi-structured interview guide for the business hypothesis below.
# Business hypothesis
- Target customer: [e.g. production planning staff at manufacturers with 300–1,000 employees]
- Assumed problem: [e.g. compiling actuals from several systems takes three hours every week]
- Tentative solution: [e.g. cross-system compilation of actuals plus a draft explanation for the manager]
# Constraints
- Four blocks: (1) past behaviour and context, 20 min; (2) problems, workarounds and payment, 15 min; (3) live mock, 15 min; (4) wrap-up, 10 min
- In (1) and (2), no question may mention our solution
- Questions about opinions, the future or hypotheticals ("would you use…", "do you think … is useful") are forbidden
- Attach two follow-up questions to each question that make the person reconstruct the last specific occurrence
- (2) must include "alternatives", "why you stopped switching", and "time and money you currently spend"
- (3) contains only questions that show a rough screen and ask what is different; never "would you use it"
- Finish with five examples of leading that an interviewer might do unconsciously on this exact topic
Output as a script that can be read aloud, not as a table.
Do not use the guide as it comes; rewrite it in your own words. AI-written questions are stiff and make people guard themselves. Turning "When did you most recently perform that task?" into "When did you last do that, roughly?" changes how much you get back.
Looking for AI training and consulting?
Learn about WARP training programs and consulting services in our materials.
Prepare a "live mock kit" beforehand
If you build a mock from nothing during the interview, you keep the customer waiting. The trick is to prepare a base for swapping. I call it a live mock kit: three screen options derived from the business hypothesis, in one HTML file. Buttons at the top switch between options A, B and C, and the copy and field names inside are held in JavaScript variables so they can be swapped.
Why three? Show one option and the customer judges that option. Show three and they tell you which one is closest to their reality, and start explaining why. Comparison makes it easier to say what you really think. The "built to be thrown away" approach from Building MVPs and mocks with AI applies here too.
The instruction to the coding agent starts from this prompt. Paste it with your working folder open.
Build a mock kit for customer interviews that can be "swapped and shown on the spot".
# Business hypothesis (Lean Canvas summary)
- Customer segment: []
- Problems (top three): []
- Tentative solution: []
- Unique value proposition: []
# Deliverable
- A single index.html (Tailwind CSS via CDN, no build step; opens in a browser)
- Buttons at the top to switch between Option A, B and C
- A: the shortest path to solving problem 1 / B: solves problem 2 / C: handles problems 1 and 2 together
- Each option has three sections: hero (one-line value proposition), one screen showing the main action, one screen showing the result
- All copy, field names and numbers live in a const CONTENT = {...} at the top of the file, so swapping means editing only that block
- Dummy data uses realistic field names for the segment's actual work (never "sample" or "test")
- Keep the look plain enough to read as "obviously a rough sketch"; no logo, colour or decoration
- Inputs need not work; buttons only need to move to the next section
# Forbidden
- No company or product names
- No evaluative words on screen such as "AI-powered" or "revolutionary"
Open the file in a browser and look at all three options once yourself. Check that none of them is a disguised pitch of your own hypothesis. A common failure is option C being visibly the most elaborate. Keep the three visually equal in weight.
On the day, two people is ideal: one interviews, one drives the agent and swaps content. If you are alone, before block 3 say "give me two minutes to set up a screen", and use the following prompt to reflect what was just said.
I am in the middle of an interview. Rewrite CONTENT in index.html to reflect the customer's words.
Do not change the structure; swap copy and fields only. Finish within two minutes and ask no clarifying questions.
# The customer's words (verbatim)
"[e.g. At month-start I pull numbers from three systems, reconcile them in Excel, then write an explanatory memo for the department head. Writing the memo is the worst part.]"
# Changes
- Make option B's hero a single sentence in the customer's words (e.g. "Three numbers, one page for the department head")
- Add a "memo for the department head" button on the main-action screen and show a sample memo on the result screen
- Rename fields to the words the customer used ("actuals", "month-start", "department head")
Running the session: the mock is a question, not a proposal
How you enter block 3 decides whether this method works. I always say: "Based on what you've told me so far, I put together a rough sketch. It is not the answer, so please tell me what's wrong with it." Then I show an option, and the first question is a single one: "What's different?"
Ask "what do you think?" and people compliment you. Japanese businesspeople especially. Ask "what's different?" and people start looking for the gap between the picture and their reality. "It's unusable without an approval column." "We look at this weekly, not monthly." The gap is what you build next.
Capture reactions in behaviour, not just words. Where their eyes went first. Which option made them lean in. Where an "ah" came out. The second person notes the time of each moment, because none of it survives in a transcript.
Swap at most twice. Go to a third and fourth round and the customer starts treating this as a place to get wishes granted, and a list of wishes begins. Wishes are not problems. When the reaction improves on the second swap, stop there and move to the next questions: "If this were available tomorrow, who would you show it to first?" and "What monthly price could you sign off on without going up the chain?" These two can only be asked after a mock has been shown.
Decide on one question you will never ask: "Would you use this?" Almost everyone answers yes, and the yes means nothing. As I wrote before, no report is more dangerous than "everyone said it sounded great".
Extract insights within an hour afterwards. Throw away any insight without a verbatim quote
Process the session the same day, while it is fresh. Transcription now takes minutes on any device. Before handing the transcript over, do two things by hand. Mask names, company names, partner names and anything confidential. And insert markers such as "[Option B shown from here]" at the moment each mock appeared.
The instruction to the agent is the prompt below. The point is to force quotes. Read a transcript to an AI and it will naturally fill in "insights" that are not there, plausibly and fluently. So it may not output any claim without a quote.
Extract insights from this customer interview transcript.
Most important rule: every item must carry a verbatim quote from the transcript with a timestamp.
Any inference not backed by a quote must be written separately and prefixed "UNVERIFIED:".
# Transcript
[paste here; personal data masked; "[Option B shown from here]" markers at each mock]
# Items to extract
1. What the person actually does (reconstruction of the last occurrence), including time, people and tools
2. The single worst moment, in their words; with frequency, duration and money as numbers where stated
3. Current alternatives and the time and money spent on them
4. Frustrations with current tools and the reasons they have not switched
5. Reactions after the mock, organised per option: what they said was "different"
6. Flag every statement made only after the mock with [AFTER MOCK] to separate the influence of leading
7. Contradictions within the person's statements (where the first half and the second half differ)
8. Questions where I, the interviewer, may have led, and the statement immediately after each
9. Five questions for the next interview, each with the hypothesis it is meant to test
# Output format
- Bullets under each heading; each line ends with [mm:ss] "verbatim quote"
- Finish with three things this single interview cannot decide
When you read the output, look hardest at items 7 and 8. Contradictions are evidence that the person voiced both the official line and the real one, and the real one is usually in the second half. The possibly-led passages are what you use to discount the corresponding insight. Being told your own questioning habits every time is not pleasant. It is also the fastest way to get better at interviewing.
Do not stop at reading each interview once; accumulate them in a hypothesis ledger. The ledger tracks each Lean Canvas block through four states: hypothesis, supporting statement exists, refuting statement exists, verified. Hand the extraction to the agent and have it update the ledger.
Update the hypothesis ledger below with the extraction from this interview.
Rules: accumulate "supporting quotes" and "refuting quotes" as counts per row.
Never mark a row "verified" on one statement. Three or more supporting and zero refuting = "candidate for verified".
# Ledger (current)
| ID | Block | Hypothesis | State | Support | Refute | Ask next |
| H1 | Problem | Compiling month-start actuals takes three hours a week | hypothesis | 0 | 0 | |
| H2 | Customer | The decision-maker is the production planning section head | hypothesis | 0 | 0 | |
| H3 | Revenue | 30,000 yen a month can be approved at section-head level | hypothesis | 0 | 0 | |
# This interview's extraction
[paste here]
# Output
- Updated ledger, same format
- Rows whose state changed, with the quotes that caused it
- New hypotheses that should be added (born from what the customer said)
At five interviews, look across them. "Read these five extractions and list, with quotes, the problems voiced by three or more people, the problems voiced by only one, and the statements that contradict each other." Patterns start to appear. At this point the AI personas I described in Having an AI grade your business become useful. A persona that has read five verbatim records is a different animal from one built on attributes. Use it as a sparring partner for the next interview's questions. It is a tool for deciding what to ask next, never a reason not to ask.
The cautions, once more. Sort out consent and personal data first. Discard insights without quotes. Flag statements made after the mock. Never conclude from one interview. And remember that what people say and what they do are different things. Whether the person who said "I'd pay 30,000 yen a month" actually pays is unknown until you send an invoice.
Making this work inside a large company's new-business unit
By now some readers are thinking "we can't just get access to customers". The biggest constraint in a corporate new-business team is not the ability to build a mock but access to customers. What I recommend is asking existing sales or customer-support colleagues to introduce one customer a week who will give you thirty minutes. Existing customers may not match your new target. They are still the best people to ask about frustrations with current tools: why they have not switched, what they spend today in time and money.
One a week is enough. Ten weeks gives you ten verbatim records and a ledger. When it is time to write the approval memo, whether you have "a list of problems in the customer's own words" and states like "three supporting, one refuting" changes the internal conversation from "does it sound interesting?" to "what has been confirmed and what hasn't?" It also becomes clear where a senior manager should push back.
There is one trap specific to large companies: legal. Recording, transcription, feeding an AI. Unless a consent template and the list of approved AI tools are settled in advance, every step stalls. In the first week, sit down with legal and put three things on paper: an interview consent form, the masking rules for personal data, and which tools may be used and under what conditions data may leave the company. This is the business development team's job. Leave it and everything stops right before interview number ten.
In WARP, we run this listen-build-extract cycle on participants' own business themes. The method is readable. How much you lead in your very first interview is not something you can see without being told. The programme structure is on the WARP page.
Wrapping up
What this article describes looks like a story about tools. It is really a story about order. Listen, then build. Show what you built as a question, not a proposal. Keep the record with quotes. Never decide on one interview. As long as that order holds, AI raises the speed of new business development by an order of magnitude. Break the order and you are left with a beautiful deck and an empty ledger.
If you do one thing tomorrow: take the guide generated by the interview prompt above and interview a colleague for thirty minutes. Then run the transcript through the extraction prompt and read item 8, the places where you led. That is the first step of this methodology. If you want to design this cycle around your own new business theme, let's talk through a consultation.
Footnotes
-
Park, J. S. et al., "LLM Agents Grounded in Self-Reports Enable General-Purpose Simulation of Individuals" (arXiv:2411.10109, first version November 15, 2024). Generative agents built from two-hour semi-structured interviews with 1,052 people reproduced GSS answers at 83% (interview-only), 82% (survey-only), 86% (combined) and 74% (demographics-only) of participants' own test-retest consistency ↩
