Expert interview

Skill SkillMedev/skills/skills/expert-interview

The open Skill Me catalog — every hosted skill as a portable, MIT-licensed SKILL.md

Install

npx -y skills add SkillMedev/skills --skill expert-interview

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Designs an expert-interview package - sourcing criteria for the right experts, a funneled discussion guide with timing, open-then-probe question design, laddering, and a neutral probe kit - that extracts honest insight without leading the witness. Use when someone asks "help me write questions for an expert call", "build a discussion guide", "prep me for this expert network interview", or is planning customer-development or domain-expert conversations. Do NOT use for designing a full data-collection study with sampling and hypotheses - use primary-research instead; for synthesizing findings after the interviews are done, use interview-synthesis instead; for desk research that involves no live conversation, use deep-research instead.

SKILL.md

7.3 KB, as published. Nobody here has run it

Expert Interview

An hour with the right expert can replace weeks of desk research - or produce nothing but confirmation of what the interviewer already believed. The costly failure this skill prevents is the leading interview: questions that carry the hypothesis inside them, so the expert politely agrees and the team ships on evidence it manufactured itself. A good guide is a structure, not a script.

Inputs to collect

Learning objectives: what decision the interviews inform, and the 3-5 things that must be learned. Separate "must learn" from "nice to know" so sections can be cut under time pressure.
The hypothesis being tested, if any - written down so it can be deliberately kept out of the questions.
Interview length (default 45-60 minutes) and format (call, in person).
How many experts and what mix of vantage points (practitioner, buyer, former insider, adjacent-market operator).
Recording and consent constraints, and any compliance rules (expert networks prohibit asking for confidential or MNPI material - respect this in question design).

Operating procedure

Step 1: Source the right experts

The guide cannot rescue the wrong expert. Apply the sourcing rules:

Prefer recent, hands-on experience over seniority: the person who ran the process 18 months ago beats the executive who approved the budget.
Cover at least two distinct vantage points on the question (e.g., a vendor-side seller and a buyer-side evaluator) - one perspective, however expert, is a single data point.
Screen with one question before booking: "Walk me through the last time you personally did X." An expert who answers in generalities during screening will do so for the whole hour.
Watch incentives: consultants and vendors have a stake in the answer; note the bias, do not disqualify automatically.

Step 2: Structure the guide as a funnel

Order matters - trust and context must exist before depth is possible, and fatigue degrades late answers:

Warm-up (5 min): easy rapport questions; establish the expert's background and standing to answer.
Broad context (10 min): open questions about their domain and how they see the problem - before any narrowing, so their framing arrives uncontaminated by yours.
Core (20-25 min): targeted questions mapped one-to-one to learning objectives. Front-load the most important objective; fatigue is real.
Deep dives / laddering (10 min): drill into the richest threads that emerged.
Wrap-up (5 min): "What did I not ask that I should have?" and referrals to other experts.

Annotate each question with the objective it serves. A question serving no objective gets cut.

Step 3: Write open, neutral questions - open first, probe second

Open with "How," "What," "Walk me through," "Tell me about" - never yes/no, which yields one bit of information and hands the expert your framing.
Strip assumptions and leading language: "How did the rollout go?" not "The rollout went badly, right?"
No double-barreled questions (two questions fused into one - the expert answers the easier half).
Ask about specific past behavior ("What did you do last time...") over hypotheticals ("Would you...") - people are poor predictors and generous self-reporters.
The rule of the interview: ask the open question, then shut up and probe what comes back. Never probe before the open answer has fully landed.

Step 4: Prepare the laddering moves

To reach underlying motivations, ladder up from a stated fact:

They state a behavior → "Why is that important to you?"
They give a reason → "And why does that matter?"
Repeat 3-5 times until a core value or driver surfaces.

Ladder down for specifics: "Can you give me a concrete example of that?"

Step 5: Pack the probe kit

Keep these neutral probes ready for any answer worth more depth:

Clarification: "What do you mean by ___?"
Elaboration: "Tell me more about that."
Example: "Can you walk me through a specific time?"
Silence: pause and let them fill it - do not rescue them.
Echo: repeat their last few words as a question.

Step 6: Engineer neutrality

Do not nod approval at some answers and frown at others. Do not reveal the hypothesis. Do not finish their sentences or supply the word they are searching for. When they say something that contradicts your thesis, probe it with the same energy as something that confirms it - that asymmetry is where bias enters.

Worked artifact: good/bad question contrast

Objective: learn why enterprise buyers churn from a data platform.

Bad: "Did you churn because of the pricing changes?" (yes/no, leading, embeds the hypothesis, invites polite agreement)
Good: "Walk me through the period when you decided to move off the platform - what was happening?" then ladder: "You mentioned the renewal discussion got escalated - why did that matter?" → "And why was that important to your team?"
Bad: "Would you pay more for better support and faster onboarding?" (hypothetical, double-barreled, socially pressured toward yes)
Good: "Tell me about the last support issue you had. What did you do?" then probe: "What happened next?"

Deliverable

Produce an interview package containing: the expert-sourcing spec (criteria, vantage-point mix, screening question), the funneled guide with per-section timing and the objective each question serves, the probe kit, a consent/recording note, and a warm closing that asks for referrals.

Do NOT

Do not lead the witness - the goal is their truth, not confirmation of yours; a confirmed hypothesis from a led interview is worth nothing.
Do not ask hypotheticals when a past-behavior question exists - stated intentions systematically overstate real behavior.
Do not stack every must-learn objective at the end; fatigue makes minute 50 answers half as rich as minute 15 answers.
Do not script exact wording and read it - a guide is checkpoints, not a teleprompter; following a script kills the follow-up instinct.
Do not correct or debate the expert mid-interview; let them correct your framing, and note the disagreement for synthesis.
Do not ask experts for confidential, proprietary, or material non-public information.

Quality bar

Every question maps to a named learning objective, and the most important objective appears in the first half.
No yes/no, leading, or double-barreled question survives in the core sections.
The guide fits the time budget with 10 minutes of slack for unplanned depth.
Someone other than the author could run the interview from the guide without asking what a question is for.