---

name: talk-to-users description: Run developer customer discovery via a Technical Advisory Board (TAB). Use when the user has never interviewed a user who isn't a friend, is inventing messaging from a conference room, or is guessing at the roadmap instead of hearing the pain firsthand.

Talk to users (the TAB system)

The best marketing to developers comes from talking to developers. That's it. Everything else in this repo is downstream of this skill.

Use this when: you've never done a real user interview, your messaging is clever but unverified, or you keep debating the roadmap internally instead of asking the people who feel the pain.

The core idea

Stand up a Technical Advisory Board: 30-50 people who represent your users and buyers, not grey-haired advisors telling you how to build. You interview them, on repeat, and let their words become your positioning, roadmap, and homepage copy.

A TAB call is not a demo and not a sales call. It's an interview. You never mention the product.

Framework: the TAB system (Frankl)

Composition

• One+ representative of every persona that touches the product (see who-is-this-for)
• Both users (interact) and customers (pay), often different people
• Target 30-50 members

Cadence

• 30 minutes · one-on-one · monthly · for ~6 months
• Zoom, recorded with permission, never in person
• Same questions every time · never pitch

Recruitment (it's a numbers game)

• Personalize every message, never batch-and-blast
• Lead with their problem, not your startup
• Max 4 sentences
• ~10% reply → plan ~500 outreaches for ~50 members
• No payment: early access, influence, swag

Template:

Dear [Name],

Your post about [specific problem] was genuinely sharp.

I'm building something to attack [that problem] and I'd value your view. Would
you consider joining my technical advisory board?

If so, reply and I'll set up a short call to explain what's involved.

The 7 questions (never more than 7 in 30 min)

1. Magic wand: "If you could wave a magic wand and change anything about how you do [task], what would it be?"
2. The stakes: "If we delivered that, how would it change your day / your work?"
3. Why now: "What's different about the world now that makes this more valuable than five years ago?"
4. What caused this problem in your org?
5. What have you tried, and why did it fall short?
6. What happens if nothing changes for another year?
7. Where do you go to stay current on this? (who/what they trust)

Analyze: turn transcripts into assets

Highlight complete sentences (not fragments) into four buckets, then synthesize the top 3-5 of each, in the interviewee's exact words:

Bucket	You're mining for
Pains	bad outcomes, risks, obstacles
Gains	outcomes they want
Jobs	what they're trying to accomplish
Environmental changes	trends making the pain worse over time → your villain

Those four buckets feed directly into positioning-and-story and value-prop-that-converts.

Mistakes that look reasonable

• Interviewing friends: they're nice and useless. You need people who'll say no.
• Pitching mid-interview: the moment you demo, they start being polite instead of honest.
• Leading questions: "wouldn't it be great if…" gets you the answer you fished for.
• Batch outreach: a templated blast to 200 people gets 200 ignores. Personalize or don't send.
• Asking for solutions: users are experts in their pain, not in your product. Mine the pain.

Your next 30 minutes

• List every persona from who-is-this-for; you need TAB members for each.
• Find 10 people who've publicly posted about the problem (HN, Reddit, GitHub issues, X).
• Send 10 personalized, 4-sentence, problem-first invites. Today.
• Lock your 7 questions (3 above + 4 tailored). Do not exceed 7.
• After 3 calls, fill the Pains/Gains/Jobs/Changes table with real quotes.

---

Built from real dev-tool GTM experience, with frameworks from Adam Frankl (The Developer-Facing Startup) and Jakub Czakon (markepear.dev). If you want help standing up a real Technical Advisory Board, or reading what your interviews are actually telling you, reach out to me on LinkedIn.