Discovery Interview

Discovery Interview is a structured product discovery skill from parcadei’s Continuous-Claude-v3 project. It helps turn early, incomplete, or loosely defined ideas into detailed specifications by interviewing you step by step before any implementation begins.

Instead of jumping straight into features or technical decisions, it works through the problem, users, workflows, data, integrations, security, scale, deployment, and tradeoffs to uncover missing requirements and hidden assumptions.

What it does

1. Clarify the real problem
   Explore what you are trying to solve, who experiences the problem, how it is handled today, and what success should look like.

2. Map the user experience
   Work through the first-time experience, core actions, user journeys, error states, edge cases, and the technical level of the intended users.

3. Define data and system requirements
   Identify what data needs to be stored, where it comes from, where it goes, who owns it, and what privacy or compliance requirements may apply.

4. Explore technical constraints
   Review existing systems, deployment environments, technology preferences, team expertise, and architectural constraints before committing to an approach.

5. Evaluate scale and performance
   Discuss expected users, traffic, response-time requirements, usage spikes, and read/write patterns so infrastructure decisions match realistic needs.

6. Identify integrations and dependencies
   Clarify external services, APIs, authentication requirements, third-party dependencies, and what should happen when integrations fail.

7. Review security and access
   Define who can access what, identify sensitive data, and surface authentication, authorization, privacy, and compliance requirements.

8. Resolve conflicting requirements
   Surface tradeoffs such as simplicity versus flexibility, speed versus future-proofing, or strong security versus frictionless UX, then help you choose what matters most.

Built for different project types

Discovery Interview adapts its questions depending on what you are building, including:

• Backend services and APIs
• Frontend and web applications
• Full-stack applications
• Mobile apps
• CLI tools
• Scripts and automations
• Libraries and SDKs
• Internal tools
• Technical and non-technical products

The interview focuses on the areas that matter for the specific type of project instead of forcing every idea through the same questionnaire.

How the interview works

1. Initial orientation

The process starts with a small number of broad questions to understand:

• What problem you want to solve
• Who will use the product
• Whether it is a new product or an improvement to something existing
• What type of system you are building

This establishes the direction for the rest of the interview.

2. Deep-dive questions

The interview then works through relevant areas such as:

• Problem and goals
• User experience
• Data and state
• Technical landscape
• Scale and performance
• Integrations
• Security
• Deployment and operations

Each section goes beyond surface-level answers and asks follow-up questions when something is unclear.

3. Detect uncertainty

If an answer includes uncertainty, assumptions, or unclear terminology, the skill does not simply treat it as a final decision.

It can identify areas that need more thought, explain important tradeoffs, and suggest further investigation before requirements are locked in.

4. Resolve conflicts

When two requirements conflict, the issue is surfaced explicitly.

For example:

• Simple vs. feature-rich
• Real-time vs. low infrastructure cost
• Flexible vs. highly optimized
• Secure vs. frictionless
• Fast to build vs. future-proof

The goal is to make these decisions intentionally rather than leaving contradictions hidden in the final specification.

5. Check completeness

Before generating the specification, Discovery Interview checks whether important areas have actually been covered.

This includes questions such as:

• Is the problem clearly defined?
• Are success criteria known?
• Are users and stakeholders identified?
• Is the core user journey understood?
• Are error states and edge cases considered?
• Is the data model understood?
• Are integrations specified?
• Are scale and security requirements clear?
• Have major tradeoffs been decided?
• Are important requirements still marked as unknown?

If major gaps remain, the interview continues before producing the final document.

Typical inputs

You can start with something as simple as:

• “I want to build an AI research tool.”
• “I have an idea for a SaaS product.”
• “Help me plan an internal dashboard.”
• “I want to automate this workflow.”
• “I need an API for my mobile app.”
• “I know roughly what I want, but I need a proper spec.”

You do not need to arrive with complete technical requirements.

Discovery Interview is specifically designed to help uncover them.

Typical outputs

Once the requirements are sufficiently clear, the skill can produce an implementation-ready specification containing sections such as:

• Executive summary
• Problem statement
• Success criteria
• User personas
• User journey
• Functional requirements
• Must-have, should-have, and optional features
• Technical architecture
• Data model
• System components
• Integrations
• Security model
• Performance requirements
• Scalability requirements
• Reliability requirements
• Out-of-scope items
• Open implementation questions
• Relevant research findings

Example use cases

• Turn a rough startup idea into a product specification
• Define requirements before handing a project to developers
• Work through a product idea with a non-technical founder
• Clarify architecture before starting a complex software project
• Discover missing requirements in an existing feature proposal
• Define the workflow for an internal automation
• Compare technical approaches before implementation
• Identify security or scalability requirements early
• Turn stakeholder discussions into a structured implementation brief

Designed to challenge assumptions

Discovery Interview is not designed to simply agree with every initial decision.

It actively looks for signals such as:

• “I think this is probably enough.”
• “Just use a normal database.”
• “It only needs basic login.”
• “It needs to handle millions of users.”
• “Whatever technology is standard.”
• “I want it simple but also highly customizable.”

When requirements are vague or contradictory, the skill asks for clarification rather than silently filling in the gaps.

Technical and non-technical users

For technical users

The interview can focus more heavily on:

• Architecture
• Data models
• APIs
• Infrastructure
• Performance
• Reliability
• Technical tradeoffs

It still challenges assumptions instead of accepting technology choices without context.

For non-technical users

The interview focuses more on:

• The problem being solved
• User behavior
• Expected workflows
• Business requirements
• Practical tradeoffs

Technical choices can then be explained in simpler terms based on what the product actually needs.

Final result

The goal of Discovery Interview is not just to produce more documentation.

It is to make sure the important product and technical decisions are understood before implementation begins, reducing unclear requirements, hidden assumptions, conflicting expectations, and unnecessary rework.

Source

https://github.com/parcadei/Continuous-Claude-v3/tree/main/.claude/skills/discovery-interview