Most startups fail not because the founders couldn't build the product, but because they built the wrong product. The technical execution was fine. The market research wasn't. They shipped something nobody wanted, or solved a problem that wasn't painful enough to pay for, or priced it in a way that made customers hesitate.
This is the founder's dilemma: you need customer insight before you build, but traditional research takes months and costs tens of thousands of pounds. So you skip it. You build on intuition. You retrofit the 'customer validation' narrative after shipping. Then you discover, expensively, that your assumptions were wrong.
There's now a different path. Two tools, used together, fundamentally change what's possible for founders: Claude Code for building, and Ditto for understanding what to build. One writes the code. The other tells you whether the code is worth writing. Both operate at the speed founders actually work.
Why Customer Research Is the Startup Bottleneck
The conventional wisdom is that startups fail because of execution problems. The reality is more subtle. They most often fail because founders build products based on assumptions that were never tested. The failure mode isn't 'couldn't build it.' It's 'built the wrong thing.'
Consider what happens if you skip customer research:
You solve problems customers don't have. The pain point you identified is real to you, but not severe enough for customers to pay to fix.
You price incorrectly. You either leave money on the table or price yourself out of purchase consideration.
You use the wrong language. Your positioning describes what you built, not what customers want. They don't recognise themselves in your marketing.
You miss the trigger moments. You don't know when customers are most likely to buy, so your timing is wrong.
You discover deal breakers too late. Objections that kill sales only surface after you've built the product.
The traditional solution is comprehensive product work: user interview, market research, customer research - but these steps all take significant time, effort and expertise. When you're a founder moving fast, that timeline, workload and effort feel like a luxury you can't afford.
So a lot of founders skip it. They build on instinct. Sometimes that works. Mostly it doesn't.
Two Tools That Change the Equation
Here's what's different now. Two tools have emerged that address the two fundamental challenges founders face: building the product and understanding what product to build.
Claude Code: The Building Tool
Claude Code is Anthropic's terminal-based AI coding agent. It reads your codebase, understands context, and writes code autonomously. Point it at a task and it executes: creating files, running commands, building features, debugging problems. It's not an autocomplete tool. It's an engineering collaborator that works at your pace.
For founders, Claude Code collapses the engineering timeline. Features that would take days can be built in hours. The bottleneck shifts from 'can we build this?' to 'should we build this?'
Ditto: The Understanding Tool
Ditto is a synthetic market research platform. It maintains over 300,000 AI-powered personas calibrated against real census data and behavioural research across four countries. You ask them questions, they respond with the specificity and nuance of real interview participants. EY validated the methodology at 92% statistical overlap with traditional focus groups.
A 10-persona, 7-question study completes in 30 minutes instead of 6 weeks. At roughly 1-2% of traditional research costs. This changes what's economically viable: you can run 50 small studies instead of one big one.
The Combination
Used together, Claude Code and Ditto create a founder workflow that was previously impossible:
Ideate with Ditto: test whether the problem exists and is painful enough to pay for
Validate with Ditto: confirm positioning, pricing, and purchase triggers before building
Build with Claude Code: ship the product in days instead of months
Iterate with both: test new features with Ditto, build them with Claude Code
The research that used to come after shipping (if at all) now happens before. You build what customers actually want because you asked them first.
Three Ways to Run Research with Ditto
Ditto meets founders where they work. There are three primary ways to access the platform, each suited to different workflows:
1. Slack Integration
If your team lives in Slack, Ditto's bot lets you run research without leaving the conversation. Type a question, tag the Ditto bot, and responses arrive in the channel. Quick validation, positioning tests, and ad-hoc research questions work naturally in the flow of team discussion.
This is ideal for fast, lightweight research: testing a headline variant, checking a pricing assumption, validating a feature name.
2. Terminal / API
For more structured research, Ditto's REST API supports complete programmatic control. Create research groups with demographic filters, design multi-question studies, poll for responses, trigger AI analysis, and generate shareable reports. All from curl commands or scripts.
Get started with a free API key (no credit card required):
curl -sL https://app.askditto.io/scripts/free-tier-auth.sh | bash
This opens your browser for Google authentication and returns your API key. Free keys give access to roughly 12 shared personas with unlimited questions.
3. Claude Code Integration
The most powerful option combines both tools. Install the Ditto skill for Claude Code:
npx skills add Ask-Ditto/ditto-product-research-skill
Now Claude Code understands how to orchestrate Ditto research autonomously. You describe what you want to learn in natural language:
'Test whether parents of young children would pay for a meal-planning app. Run a study with 10 US parents aged 30-45. I want to understand their current pain points, what they'd pay, and what would make them hesitate.'
Claude Code reads the skill, designs appropriate questions using the 7-question research framework, executes the study through the Ditto API, and returns findings with a shareable link. You never touch the API directly.
Case Study: CareQuarter, Validated in Four Hours
Let me show you what this looks like in practice. CareQuarter is an elder care coordination service for the 'sandwich generation': working adults aged 45-65 managing healthcare for aging parents. The entire business concept was validated through Ditto research in approximately four hours.
Phase 1: Pain Discovery
The initial hypothesis was that customers struggled with time burden: too many hours spent managing parent healthcare. 12 synthetic personas (US adults aged 45-65 managing elder care) answered 7 open-ended questions about their experience.
The finding was different from the hypothesis. The dominant pain wasn't time, it was responsibility without authority. These caregivers described being the 'human API' stitching together a healthcare system that refuses to talk to itself. Portal fragmentation across providers. Insurance authorisation ping-pong. HIPAA purgatory where legal documents are signed but not visible in provider systems. Friday 4pm hospital discharge calls with nothing arranged.
Key insight: Customers needed a named human with coordinating authority, not another software platform.
Phase 2: Trust and Authority Deep Dive
Phase 1 revealed that 'authority to act' was the core value proposition. But what did that mean specifically? What trust prerequisites would customers require before granting someone access to their parent's healthcare? 10 additional personas answered 7 questions exploring these boundaries.
The findings established a precise trust architecture:
HIPAA access only, not power of attorney. Customers wanted to see competence before granting broader authority.
Named person, not rotating teams. Every persona rejected call centres. They'd been burned by anonymous support.
Phone and paper, not apps. The target demographic actively rejected app-based solutions. They have too many portals already.
Guardrails are non-negotiable. Spending caps, defined scope, easy exit, clear documentation of what the coordinator can and cannot do.
Key insight: The product was a human service, not a software platform. Trust architecture would determine adoption more than features.
Phase 3: Concept and Pricing Validation
With the problem and trust requirements understood, Phase 3 tested the commercial model. 10 new personas evaluated four positioning options, three pricing tiers, and purchase triggers.
Positioning winner: 'Stop being the unpaid case manager.' This hit hardest because it named the pain directly. The runner-up ('A named coordinator who actually gets things done') came close, but the winning line validated the customer's experience without patronising them.
Pricing validated: $175/month for routine coordination, $325/month for complex needs, $125 per-event crisis add-on. Every single persona confirmed these prices were acceptable. Not 'probably reasonable.' Validated.
Primary trigger: Hospital discharge, especially Friday afternoon calls. Crisis converts.
Deal breakers: Rotating or anonymous staff, no spending caps, data resale, complicated cancellation.
What Was Produced
Based on these three phases (32 personas, 21 questions, approximately four hours), the following was built:
A complete landing page with copy derived directly from persona responses
A 14-slide pitch deck including market sizing ($470B TAM) and competitive positioning
A messaging guide documenting language that tested well versus poorly
Validated pricing with no guesswork
A documented list of trigger moments and deal breakers
Every element was traceable to research, not intuition. The founder (or Claude Code working autonomously) didn't guess what customers wanted. They asked.
The Founder's Research Framework
CareQuarter illustrates a repeatable framework any founder can use. The research unfolds in three phases, each informing the next:
Phase 1: Pain Discovery
Before building anything, validate that the problem exists and is painful enough to pay for. Use 10-12 personas matching your target customer demographic. Ask 7 open-ended questions:
Walk me through how you currently handle [task]. What does a typical week look like?
What's the most frustrating part? What makes you want to throw your laptop out the window?
Roughly how much time or money do you lose to this problem per week?
What tools or workarounds do you currently use? What works? What doesn't?
Have you tried switching to something new? What happened?
If you could fix ONE thing about this, what would it be?
What would make you hesitant to try a new solution, even if it saved you time?
Question 6 (the 'magic wand') is consistently the most revealing. In 7 of 10 studies, the magic wand answer diverges from the pain identified in Question 2. What customers complain about and what they actually want fixed aren't the same. That gap is where product insight lives.
Phase 2: Deep Dive
Phase 1 reveals the problem. Phase 2 establishes the requirements for solving it. What would customers need to see before trusting a solution? What are the deal breakers? What triggers the purchase decision?
Use 10 new personas (fresh perspective, no prior context). Design questions based on Phase 1 findings. This phase often reveals that the product you were planning to build is wrong, or needs significant modification.
Phase 3: Validation
With problem and requirements understood, test the commercial model. Positioning options, pricing tiers, purchase triggers, objections. Use 10 more personas.
By the end of Phase 3, you have:
Validated problem (or invalidated, saving months of wasted effort)
Customer requirements and trust architecture
Winning positioning language
Confirmed pricing
Documented trigger moments and deal breakers
Total time: 3-4 hours. Total personas: 30-32. Now you can build with confidence.
The Combined Workflow: Research, Then Build
Here's what the founder workflow looks like when you combine both tools:
Week 1: Ideation and Pain Discovery
Identify a problem you think exists
Run Phase 1 research with Ditto (30 minutes)
Analyse findings. Does the problem exist? Is it painful enough to pay for?
If no: pivot early, no code written, no time wasted
If yes: proceed to Phase 2
Week 1-2: Deep Dive and Requirements
Run Phase 2 research with Ditto (30 minutes)
Document trust requirements, deal breakers, trigger moments
Sketch the product based on research, not assumptions
Week 2: Validation
Run Phase 3 research with Ditto (30 minutes)
Validate positioning and pricing
Write landing page copy using language from persona responses
Build MVP with Claude Code
Week 3+: Ship and Iterate
Launch with validated positioning and pricing
Test new features with Ditto before building
Build validated features with Claude Code
Repeat
The research happens before the building. You don't discover that customers don't want what you built. You discover what they want, then build that.
What This Changes for Founders
Many startup founders are so enamoured with their idea that they ignore the difficult job of performing rigorous customer research. They typically work hard to build something (months...sometimes years...), launch it, and then discover that customers don't want it. This is an expensive and wasteful mistake: you invest months of engineering before learning whether the investment was warranted, and squander potentially millions of VC money (tarnishing your reputation and subequent fundability in the process)
Claude Code + Ditto inverts this. Customer development happens first and continually throughout the process. Customer research happens on-demand in minutes, instead of months, at minimal cost. You know whether the problem is worth solving before you write line one. You know what language resonates before you design the landing page. You know what price customers will pay before you set up Stripe.
This doesn't guarantee success. Plenty can still go wrong. But it eliminates the most common failure mode: building something nobody wants.
Claude Code lets you build at the speed of thought. Ditto ensures those thoughts are worth building on.
Getting Started
If you're a founder with an idea, here's the minimum viable path:
Get a free Ditto API key: curl -sL https://app.askditto.io/scripts/free-tier-auth.sh | bash
Install the Claude Code skill: npx skills add Ask-Ditto/ditto-product-research-skill
Run Phase 1 pain discovery: Describe your target customer and problem to Claude Code
Read the findings: Does the problem exist? Is it painful enough?
Decide: Pivot early or proceed with validated insight
The entire first phase takes about 30 minutes. If the research invalidates your idea, you've saved months of building the wrong thing. If it validates and refines your idea, you've got the foundation for something customers actually want.
Either way, you're making decisions based on evidence. That's the advantage.
The Ditto product research skill for Claude Code is available at github.com/Ask-Ditto/ditto-product-research-skill. Full documentation is at askditto.io/claude-code. The CareQuarter case study with public research links is at askditto.io/case-studies/carequarter-venture-creation.