The researcher maker: from user pain to shipped prototype in one afternoon

A 5 step framework to turn analytics drops into tested prototypes using AI assisted research

I have all through my career watched research teams present to stakeholders 50 slides about a user experience problem. Beautiful deck. Airtight methodology. The VP said “great work” and moved on. No action, nothing!

I found the same problem in product analytics, ran 5 unmoderated interviews, built a working prototype, and had real user feedback, all in one afternoon. Ready to ship!

Spend less time arguing and debating in meetings, and more time in shipping, become a researcher-maker! That is the gap this article closes.

The operating principle

In the AI era, speed is the primary competitive advantage. The traditional product cycle of weeks of research followed by months of internal reviews is being replaced by the Researcher-Maker model. This process does not deliver “insights.” It delivers functional product.

However, proceed with caution. LLMs hallucinate. They will give you confident, well-formatted nonsense. Every step in this stack requires a human checkpoint for accuracy.

I developed a Human-AI Qual Discovery Framework built around one principle: AI handles volume. Humans handle meaning. This article is the applied version of that framework.

The 3 rules

Rule 1: AI handles volume, humans handle meaning. No exceptions.

Rule 2: Every step produces a decision artifact, not a document. If the output does not force a decision, the step failed.

Rule 3: Human always goes first in analysis. Once you see AI’s themes first, you cannot unsee them.

The new standard

The researcher-maker does not ask for permission to innovate. By the time a traditional committee finishes debating a feature, you have already mapped the friction, prototyped the logic, and shipped a functional URL for testing.

A note on the example: I will use Search as a product case study throughout. This is just an example to showcase how you can design your own insight → ship stack. The goal is to inspire you to try using AI to mock products and automate workflows. But always remember: human-AI workflows, not AI-only workflows. LLMs still have serious limitations in qualitative analysis and require cross-checking at every step for hallucinations.

The 5-Step Stack

Data Pulse → Why → How → Prototype → Handover → [Loop]

• Continuous discovery to find user pain points as a weekly habit
• Code the solution to prove the fix
• Ship

Step 1: Data pulse spotting the leak

Goal: Find where the product is failing. Do this every Monday morning.

Open your product analytics (Amplitude, Mixpanel, PostHog). Pull the conversion funnel. Find the P0 Drop-off — the step where the most qualified users abandon.

Case Study: 30% of users land on search results but never click a link. The data tells you where the leak is. Step 2 tells you why.

Tools: Gemini or Claude to surface anomalies but cross-check every number against raw data. If you cannot verify it in the source, it did not happen.

Step 2: The why qualitative pulse

Goal: Get human context behind the drop off.

Run 5 rapid unmoderated interviews. If research or customer service data already exists, analyze that first.

The two pass model (critical):

• Pass 1 Human first: Read 2–3 transcripts yourself. Develop your own codes. Note surprises and contradictions before any AI output.
• Pass 2 AI second: Feed your human generated codes to Claude. Have it apply across remaining transcripts, flag new patterns, pull quotes. Then review what AI flattened or missed.

Why human goes first: Once you see AI’s themes, you cannot unsee them. The researcher’s first read is sacred.

Case Study: Analysis reveals trust is the barrier. Users do not click because they do not believe the results.

• JTBD: “I want to see community consensus alongside official claims so I can make a purchase decision without cross-referencing Reddit for 20 minutes.”
• Diagnosis: Verification Fatigue. Build social consensus signals directly into the flow.

Tools: Claude for transcript synthesis and JTBD framing. Verify every quote against the original, AI fabricates verbatim looking mashups.

Step 3: The how AI powered ideation

Goal: Bridge the gap between a problem and a feature.

The Prompt:

“Users ignore our search results because they don’t trust the source. The problem is Verification Fatigue. Give me 3 UI features that provide an instant ‘Reality Check’ signal.”

Selected Idea: The Trust Meter — a visual score comparing official AI summaries against real-time community sentiment (Reddit, X, forums).

The Score:

• 🟢 Green (90–100%): Consensus. Humans and AI agree.
• 🟡 Amber (60–89%): Marketing Heavy. Claims slightly inflated.
• 🔴 Red (<60%): Trust Gap. Community reports issues the AI is missing.

Before committing: pressure-test. Does this solve the JTBD from Step 2, or does it just sound clever?

Step 4: The prototype, proof of work

Goal: Not a wireframe. Not a slide. A functional URL.

Use Claude Code + GitHub + Vercel (or Lovable for no-code) to build a working prototype.

Case Study: The SearchJV prototype applies Reality Check logic. Entering “ChatGPT Plus subscription” returns: 75% “marketing heavy.” An emerald to crimson bar flags community reports of “model degradation” against official feature claims.

To illustrate, here is a working prototype I built using this stack: searchjv.lovable.app. It applies the Reality Check logic from Step 3 to live search queries.

Games in hours, an AI web app (Next.js + Claude API), lead management agents, and a $0 daily news aggregator pulling from 10+ sources. I am not an engineer. I am a researcher who builds. But the tools are not the breakthrough, decision clarity from Steps 1–3 is. If your thinking is unclear, the AI goes in circles.

Tools: Claude Code+Github+Vercel, Cursor (VS Code + AI), Lovable (no-code option).

Step 5: The handover ship

Goal: A functional handoff, not a presentation.

The sprint does not end with a meeting. It ends with a URL.

Engineering gets the React prototype, JSON schemas, Tailwind components. The PM gets a 48-hour decision memo:

1. The problem (from Steps 1–2)
2. The solution (prototype URL — from Steps 3–4)
3. The evidence (user quotes, confidence level)
4. The ask: Ship to experiment, pivot, or kill.

The researcher-maker does not deliver a presentation. They deliver a decision.

The loop

This is not a one-time process. It is a continuous discovery loop:

Signal → Diagnose → Ideate → Prototype → Test → New Signal → ...

Each cycle: one afternoon. Run it weekly. Monday analytics, Friday tested prototype.

To make the pipeline self-feeding: Dovetail Channels for real time support ticket clustering, n8n/Zapier to route multi-source signals, or build your own signal agent (I built mine for $0, read Phase 2).

Start here

• Compiling weekly reports manually? Start with Step 1. Monday analytics habit.
• Synthesis takes weeks? Two-pass model. Human first, AI second.
• Have insights but cannot build? Learn Claude Code. Start small. It compounds.
• Building but not testing? Maze free tier + 3 users = direction in 1 hour.

The researcher-maker does not wait for permission to prototype. The stack is the permission.

Stop delivering insights. Start delivering proof of work.

Phase 3 of the researcher-maker series. Phase 1: Build a 0→1 Game. Phase 2: build an AI news agent.