Product Skill

Product requirements discovery and scope definition for feature specifications.

Discovery Interview

Use open-ended questions to explore the problem space and understand user needs:

Problem Understanding

• What problem are we trying to solve?

• Who experiences this problem?

• How do they currently solve it?

• What triggers the need for this solution?

• What does success look like?

User Needs

• What are the core user jobs to be done?

• What pain points exist in the current workflow?

• What outcomes do users expect?

• What constraints or limitations exist?

• What assumptions are we making?

Context Discovery

• What existing systems/features does this integrate with?

• What data do we need access to?

• What business rules or regulations apply?

• What are the technical constraints?

• What are the performance requirements?

Scope Definition

Define clear boundaries for the feature:

In Scope

• Core functionality that delivers the primary value

• Critical user journeys that must be supported

• Essential integrations required for MVP

• Minimum viable data model

• Must-have business rules

Out of Scope

• Nice-to-have features deferred to later

• Advanced use cases for future iterations

• Optional integrations

• Performance optimizations beyond basic requirements

• Edge cases that can be handled manually

MVP Criteria

• What is the minimum viable feature that delivers value?

• What can users accomplish with the MVP?

• What assumptions need validation?

• What can be learned and iterated on?

User Story Extraction

Convert discovery insights into actionable user stories:

Story Format

As a [role] I want to [action] So that [benefit]

Acceptance Criteria

• Given [context]

• When [action]

• Then [expected outcome]

Examples

As a project manager I want to view task dependencies So that I can identify blockers

Acceptance Criteria:

• Given tasks with dependencies
• When viewing a task
• Then I see all blocking and blocked tasks

Story Decomposition

• Break large stories into smaller, implementable pieces

• Ensure each story delivers independent value

• Order stories by dependency and risk

• Identify stories that validate assumptions

Prioritization Matrix

Value vs Effort

• High Value, Low Effort → Do first (quick wins)

• High Value, High Effort → Do second (core features)

• Low Value, Low Effort → Do later (polish)

• Low Value, High Effort → Don't do (avoid waste)

Dependencies

• Technical dependencies (database before API)

• Business dependencies (auth before user features)

• Learning dependencies (experiments before commitments)

• External dependencies (third-party integrations)

MoSCoW Framework

• Must Have - Core value, MVP blockers

• Should Have - Important but not critical

• Could Have - Nice to have if time permits

• Won't Have - Explicitly deferred

Risk-Based Prioritization

• Tackle high-risk assumptions early

• Validate technical feasibility first

• Test user adoption hypotheses

• Front-load learning and discovery

Handoff to Architect

Product outputs that feed into technical design:

Business Context

• Problem statement and user needs

• Key user journeys and workflows

• Business rules and constraints

• Success metrics and acceptance criteria

Scope and Priorities

• In/out scope boundaries

• MVP definition

• Story breakdown with priorities

• Feature dependencies

Data Requirements

• What data entities are involved

• What relationships exist between entities

• What operations users need to perform

• What access patterns are expected

Integration Points

• External systems to integrate with

• Events to publish or consume

• APIs to call or expose

• Data sources to read or write

Non-Functional Requirements

• Performance expectations (latency, throughput)

• Security requirements (auth, authorization, data protection)

• Scalability needs (user growth, data volume)

• Reliability targets (uptime, error rates)

Product → Architect Flow

Product Skill Outputs → Architect Skill Inputs ───────────────────────────────────────────────────────── Problem & User Needs → Domain Model Design User Stories & Acceptance → Component Responsibilities Data Requirements → Entity & Schema Design Integration Points → API & Event Design Priorities & Dependencies → Task Breakdown & Ordering

The architect uses product context to make informed technical decisions:

• Domain models reflect real user workflows

• Component boundaries align with business capabilities

• Data models support actual access patterns

• API contracts satisfy user story acceptance criteria

• Implementation order respects business priorities