Join Table for One | Other Articles
I have wasted weeks of my time, my engineer’s time, and my startup’s money building the wrong thing.
Not because I was building in an echo chamber. Not because I wasn’t conducting enough customer interviews. Because I wasn’t using the information I already had properly.
Let me explain.
The case for user interviews is that it keeps you close to the problem of the people who are actually going to pay you.
And the standard advice on how it should go is as follows:
Define your hypotheses and your open questions
Find your ideal target customers
Build rapport, focus on behavior, find more information about their problems and do not disclose the product
Synthesize your findings
Identify the features required for your MVP
Now for whatever reason, there are hundreds of thousands on videos and articles on conducting the interview. From how to find the people to what to ask. But you can hardly find anything on the synthesis of the information you get during the interview.
And I see most founders, including me, get this wrong. We think we are not biased. We try not to think about the solution or the features we cooked up in our heads. But we are wrong.
Our biases do creep in!
After reading forty minutes of transcripts and seeing the comments that sound like agreement, we choose to let them stay with us. We miss the thing she said she does. We miss the confused questions she asked. We even miss the hesitation she had to pay for a solution. And We draw a conclusion from what we want to notice.
Getting Users To Talk Is The Easy Part
Understanding what exactly they need is more difficult.
No matter what you do, you cannot achieve this result via a form. On a form people fill in what you put in front of them, so you can write the most open ended question in the world and still only hear back about the thing you already thought to wonder about. Your blind spots stay exactly where they were.
The ability to synthesize the right information from your user interviews is a serious skill. If you can do that, you can see which hypothesis actually moved and which open questions are still sitting there.
It could be the difference between building something people use and something they seem excited about but don’t actually want.
Capture What You Heard
So how do you “synthesize information” from the interview? What do you even look for? What do you need to update?
Well I am sharing what I know, what I have done, and what has worked for me. I am not claiming to be an expert in this. So do not come after me!
Okay… You have 40 minutes of transcripts. Now what?
If you go through it looking for the bits that agree with you, you WILL find them. And users are not trying to mislead you. They are just polite or helpful or genuinely clever. So the information they give you is something you want to hear.
Usually I try to avoid these typical signs:
The polite comments like “I would definitely use that”, “I could see myself paying for it” or something similar that promises a payment in the future. Unless they already pay for something of a solution in time or money, the promise doesn’t mean anything.
The helpful comments that suggest a feature like “Oh you should build a dashboard” or “Can we click a picture of the fridge.” Some of them are genuinely helpful but some of them could be enthusiasts. You need to be able to differentiate.
The expert comments without context like “oh yes this is a problem” or “someone should solve it.” These people could have seen the issue and their thoughts could help you. But if this person is not the end user, then their support might not mean as much.
The entire job of synthesizing the transcripts is basically to understand:
Which hypotheses are getting stronger
Which open questions are getting answered
What evidence am I collecting
And what evidence do I still need to get
But a few interviews in when you are frustrated and can’t think straight, things can get a bit muddled up.
But lucky for us, we can train AI to do this job! We can make it an unbiased synthesizer of information. So the thing I am going to show you today is how to train Claude or ChatGPT to do the unbiased pattern recognition for you.
Build It Yourself
Everything below is a step by step method that you can use in either Claude or ChatGPT. I personally prefer Claude over ChatGPT. But you do you!
You do not need to know how to code. You just have to paste the instructions in the box into your chat/code terminal.
Step 1: Building The Brain
Before you build any skill, you need a company brain.
Don’t worry I am not asking you to build anything convoluted. Just a simple structure to store your information and to give the skill a place to drop the documents it creates.
This image is the exact snapshot of how I had structured my startup brain. You don’t have to create all the files. All you need to create are the folders.
A few rules to follow when you create a brain:
Store everything as an MD file. MD files are plain text files your AI can open, read and rewrite without a conversion step in between. The file size is small and it saves you a lot of tokens as compared to a pdf.
Fix the filenames. It is a boring rule but a bit of structure right now goes a long way when you have tons of information to deal with.
Number the files you save. Number your interview transcripts like “interview-01-sam.md” or “interview-01.md.” A level of organization will genuinely help you a lot later on.
You can also paste this instruction in Claude Code/codex or claude cowork to create it for you:
Create a folder called <your-startup>-brain, in a location I will give you.
Inside it, create these folders and nothing else: customer/, customer/interviews/, customer/snapshots/, product/.
Then create one file at the top level called _brain.md holding four lines.
The startup name, my name, today’s date, and “v1”.
Ask me where to put it before you create anything, and show me the exact path you are about to use.
Inside it, create these folders and nothing else: customer/, customer/interviews/, customer/snapshots/, product/.
Then create one file at the top level called _brain.md holding four lines.
The startup name, my name, today’s date, and “v1”.
Ask me where to put it before you create anything, and show me the exact path you are about to use.
Step 2: Creating The Skill
Now moving onto the skill itself. This is the one that reads the transcript and tells you what moved.
So paste this in:
I want to build a reusable skill that synthesizes my customer interviews. Save it so I can run it again on every new transcript. Here is the job.
WHAT IT DOES
It reads an interview transcript against what I already believed and tells me what changed. Which of my hypotheses got stronger, which got weaker, which ones the interview killed outright, which open questions got answered, what new questions opened that I had not thought to ask, and whether this person is even the customer I think I am building for.
Never delete anything. Every finding gets an id, a status and a strength, and stays in the brain permanently. When something is overturned, mark the old entry superseded with the reason, and keep it.
THE FILES IT OWNS
Create any of these that do not exist yet, inside my brain folder:
product/hypotheses.md what I believe, with a verdict per run
customer/open-questions.md what I don’t know, and how far I have got
customer/evidence-ledger.md every observable point, with a count
customer/interview-insights.md one dated section per interview
customer/voice-of-customer.md their words next to mine
customer/jtbd.md the job they are hiring the product for
customer/snapshots/ one file per interview
_log.md one line every time you run
Nothing else writes to these files. Append under dated headings.
WHAT YOU DO ON EVERY RUN, IN THIS ORDER
1. Write a snapshot for each new interview into customer/snapshots/, using the exact same filename as the transcript. Open it with the plain facts about the person, in this order: name, gender, age, role, company, company size, when we met, and how I found them. Every one of those fields is optional and every one is allowed to say “not recorded”. Fill in only what the transcript states outright or what I have told you directly. Then who they are in their own words, the single sharpest verbatim quote, and what they said, what they did, and what you concluded, kept apart.
2. Pull the evidence out into customer/evidence-ledger.md.
3. Give every hypothesis in product/hypotheses.md a verdict for this run. Strengthened, weakened, unchanged with no evidence either way, or falsified. Name the evidence each verdict rests on. Add any new hypothesis this interview revealed, and for each one write what would prove it wrong. “No evidence either way” is a real verdict, not a gap.
4. Update customer/open-questions.md. Four columns: the question, the answer so far, the evidence behind it, and whether it is open, partly answered, answered, or dead. Add the new questions this interview opened. Separately, list the questions to go back to this person with.
5. Write their actual language into customer/voice-of-customer.md. Two columns, how I say it and how they said it, verbatim. Only phrases that genuinely appear in the transcript.
6. Write the job they are hiring the product for into customer/jtbd.md as a verb, an object, and a context. No adjectives, no feature names. If you cannot write one from this transcript, write none and say so.
7. Write up the run itself into customer/interview-insights.md as one new dated section per interview. Append it, never overwrite the sections above it.
If I hand you an interview you have already processed, load what you wrote last time first and update it in place, keeping the ids. Do not start over.
BEFORE YOU BUILD ANY OF IT
Interview me. Ask no more than two questions per message, and wait for my answer each time.
Ask me what the product is. What I believed going into these interviews, two or three beliefs, one line each. What I was hoping the interviews would answer. And in one line, who I thought these people represent.
Write my answers into product/hypotheses.md and customer/open-questions.md as real entries, not as a chat log.
Then build the skill and show me where you put it.
WHAT IT DOES
It reads an interview transcript against what I already believed and tells me what changed. Which of my hypotheses got stronger, which got weaker, which ones the interview killed outright, which open questions got answered, what new questions opened that I had not thought to ask, and whether this person is even the customer I think I am building for.
Never delete anything. Every finding gets an id, a status and a strength, and stays in the brain permanently. When something is overturned, mark the old entry superseded with the reason, and keep it.
THE FILES IT OWNS
Create any of these that do not exist yet, inside my brain folder:
product/hypotheses.md what I believe, with a verdict per run
customer/open-questions.md what I don’t know, and how far I have got
customer/evidence-ledger.md every observable point, with a count
customer/interview-insights.md one dated section per interview
customer/voice-of-customer.md their words next to mine
customer/jtbd.md the job they are hiring the product for
customer/snapshots/ one file per interview
_log.md one line every time you run
Nothing else writes to these files. Append under dated headings.
WHAT YOU DO ON EVERY RUN, IN THIS ORDER
1. Write a snapshot for each new interview into customer/snapshots/, using the exact same filename as the transcript. Open it with the plain facts about the person, in this order: name, gender, age, role, company, company size, when we met, and how I found them. Every one of those fields is optional and every one is allowed to say “not recorded”. Fill in only what the transcript states outright or what I have told you directly. Then who they are in their own words, the single sharpest verbatim quote, and what they said, what they did, and what you concluded, kept apart.
2. Pull the evidence out into customer/evidence-ledger.md.
3. Give every hypothesis in product/hypotheses.md a verdict for this run. Strengthened, weakened, unchanged with no evidence either way, or falsified. Name the evidence each verdict rests on. Add any new hypothesis this interview revealed, and for each one write what would prove it wrong. “No evidence either way” is a real verdict, not a gap.
4. Update customer/open-questions.md. Four columns: the question, the answer so far, the evidence behind it, and whether it is open, partly answered, answered, or dead. Add the new questions this interview opened. Separately, list the questions to go back to this person with.
5. Write their actual language into customer/voice-of-customer.md. Two columns, how I say it and how they said it, verbatim. Only phrases that genuinely appear in the transcript.
6. Write the job they are hiring the product for into customer/jtbd.md as a verb, an object, and a context. No adjectives, no feature names. If you cannot write one from this transcript, write none and say so.
7. Write up the run itself into customer/interview-insights.md as one new dated section per interview. Append it, never overwrite the sections above it.
If I hand you an interview you have already processed, load what you wrote last time first and update it in place, keeping the ids. Do not start over.
BEFORE YOU BUILD ANY OF IT
Interview me. Ask no more than two questions per message, and wait for my answer each time.
Ask me what the product is. What I believed going into these interviews, two or three beliefs, one line each. What I was hoping the interviews would answer. And in one line, who I thought these people represent.
Write my answers into product/hypotheses.md and customer/open-questions.md as real entries, not as a chat log.
Then build the skill and show me where you put it.
I always add an interview step in the skills I make. It might feel like boring admin work but if you do not have a brain folder or a way to give specific context, getting your AI to interview you is always a good idea.
Step 3: The Rules
These are important for this skill. It will keep it honest and reliable even when you want to process more information.
Feel free to add your own rules in the script too:
Add these rules to the skill. They apply on every run.
Read before you write. Open the existing files first, then update them. Never overwrite. Append under a dated heading.
Quotes are retrieved, never generated. Verbatim only, with who said it and which interview it came from. Never shortened, never tidied up for grammar. If you cannot find a real quote for a point, say so.
Keep three things apart and never blend them. What they SAID, in their own words. What they DID, meaning something that actually happened, with a count. What you INFERRED, linked back to the row it came from. A claim about their own behaviour is a said. It becomes a did only when something they actually did backs it up.
Score every piece of evidence 0 to 5 and never add the scores up. 0 is a compliment, or something they say they would do. 1 is a story about one time. 2 is a repeated complaint. 3 is a workaround they built and still use. 4 is a workaround they pay for. 5 is money already spent, or a behaviour I watched happen. A hundred 0s are not a 5.
Use denominators. “Two of six people”, never “users say”. If a transcript was thin, still count it in the denominator, and name it as thin.
Tag every field EVIDENCE or ASSUMPTION.
Report weak signal, no signal, and anything that contradicts me. A hypothesis that never came up on its own is a real finding, not a failed run.
Never invent gender or age. Not from a name, not from a voice, not from how someone writes. “not recorded” is a correct answer.
End every run with three readings. The case for, built only from what is actually in the transcripts. The case against, which is the alternative explanation and the thing that would embarrass me in six months. And what the data alone says, with counts and no adjectives, allowed to conclude “not enough data to say”.
Then tell me what the run cannot tell me. The denominator, which transcripts were thin, whether I watched any of this happen or only heard about it, and whether my beliefs were written down before the interviews or made up at the start of the run.
Read before you write. Open the existing files first, then update them. Never overwrite. Append under a dated heading.
Quotes are retrieved, never generated. Verbatim only, with who said it and which interview it came from. Never shortened, never tidied up for grammar. If you cannot find a real quote for a point, say so.
Keep three things apart and never blend them. What they SAID, in their own words. What they DID, meaning something that actually happened, with a count. What you INFERRED, linked back to the row it came from. A claim about their own behaviour is a said. It becomes a did only when something they actually did backs it up.
Score every piece of evidence 0 to 5 and never add the scores up. 0 is a compliment, or something they say they would do. 1 is a story about one time. 2 is a repeated complaint. 3 is a workaround they built and still use. 4 is a workaround they pay for. 5 is money already spent, or a behaviour I watched happen. A hundred 0s are not a 5.
Use denominators. “Two of six people”, never “users say”. If a transcript was thin, still count it in the denominator, and name it as thin.
Tag every field EVIDENCE or ASSUMPTION.
Report weak signal, no signal, and anything that contradicts me. A hypothesis that never came up on its own is a real finding, not a failed run.
Never invent gender or age. Not from a name, not from a voice, not from how someone writes. “not recorded” is a correct answer.
End every run with three readings. The case for, built only from what is actually in the transcripts. The case against, which is the alternative explanation and the thing that would embarrass me in six months. And what the data alone says, with counts and no adjectives, allowed to conclude “not enough data to say”.
Then tell me what the run cannot tell me. The denominator, which transcripts were thin, whether I watched any of this happen or only heard about it, and whether my beliefs were written down before the interviews or made up at the start of the run.
Step 4: The Difference Between Good And Bad
Most people that make skills don’t really focus on the output. They create the skill and then try to fix it once something breaks. That is one way to do it. Another way that I like is to already define what a good vs bad output is.
So this way you skip the initial back and forth.
Here is my quality bar. Grade your own output against it before you save anything.
Bad:
“Users absolutely love the checkout screen and think the layout is intuitive.”
“Technicians don’t use the app because they are lazy and prefer texting.”
[If you find more examples, add them here. The more specific they are the better.]
Three failures in those two lines. An opinion filed as an observation. A character flaw standing in for a barrier. And no count, no moment, nothing anybody could act on.
Good:
“4 of 5 sustainability officers abandoned the automated upload at step 3 and manually uploaded a CSV instead, citing a legal requirement for human audit before cloud storage.”
[If you find more examples, add them here. The more specific they are the better.]
One observable action, at a named moment, with a count and a denominator, and nothing at all about how anyone felt.
Now write me three more good examples and three more bad ones in this shape, using my product and my customers. The bad ones should be the plausible kind, the ones that look fine at a glance, not the obviously broken kind.
Bad:
“Users absolutely love the checkout screen and think the layout is intuitive.”
“Technicians don’t use the app because they are lazy and prefer texting.”
[If you find more examples, add them here. The more specific they are the better.]
Three failures in those two lines. An opinion filed as an observation. A character flaw standing in for a barrier. And no count, no moment, nothing anybody could act on.
Good:
“4 of 5 sustainability officers abandoned the automated upload at step 3 and manually uploaded a CSV instead, citing a legal requirement for human audit before cloud storage.”
[If you find more examples, add them here. The more specific they are the better.]
One observable action, at a named moment, with a count and a denominator, and nothing at all about how anyone felt.
Now write me three more good examples and three more bad ones in this shape, using my product and my customers. The bad ones should be the plausible kind, the ones that look fine at a glance, not the obviously broken kind.
You can even ask the AI to write its own examples for good and bad so that you can grade them.
Step 5: The First Run
The best thing to have before the first run is a list of hypotheses and a list of assumptions. It is important for the skill to know what it is that you what to understand.
Once everything is set up, drop your transcripts in the interviews folder and run the skill.
This article is a part of an AI Workforce that I am building for early-stage founders. Every Tuesday, I will share a functional task that makes your job easier. Below this is a ready to use task file. This file gives you three things: the interview synthesizer, the validation dashboard (so you don’t have to read MD files), and the persona builder (so you know what kind of people you are catering to). It is available to all the paid subscribers and it is the first (of 55) tasks from the AI Workforce Map.
Ready To Use
Above this was the instruction to build one skill. But we are not building skills.
A task, the way I have structured it, is the whole job rather than one step of it. The task, Capture What You Heard, sits inside Validate The Idea and has three skills in total.
The Interview Synthesizer. The one I wrote about above. This skill sharpens your hypotheses, answers what it can, collects evidence for you and files all of these things for you to see.
The Validation Dashboard. This dashboard is a way to see your validation journey. The output generated by every skill in Validate The Idea can be seen here.
The Persona Builder. It groups the people you talked to based on their behavior and their triggers so that you can start to see past demographics.
This is one of the 55 tasks that I am building. The next one is Study Your Competition. It is also a package of three but it has one agent and two skills.
If you build it and something breaks, reach out. And if there are some tasks that you want me to build for instead, tell me!
The separation of said, did, and inferred is the strongest safeguard here. I would add a blind first pass where the model summarizes each transcript before it sees the founder's hypotheses, then compare that with the hypothesis-aware pass. If a theme appears only after the model knows what the founder hopes to prove, that is a useful warning that the synthesis may be mirroring the prompt rather than the customer.
And btw- I help the solo founders get to next level through accounting and tax matters, while also acting as a sounding board, how the decisions in business target change the business direction and impact to reporting and tax matters