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