product-thinking

name

product-thinking

description

Senior-level product thinking for engineers covering requirements analysis, user stories, PRDs, feature scoping, and prioritization. Use this skill whenever writing product requirements, user stories, acceptance criteria, feature specifications, or when making product decisions as an engineer. Also trigger when the user discusses MVP scope, feature prioritization, user experience, stakeholder communication, technical trade-offs with product impact, or asks 'what should we build' or 'how should we scope this'.

Product Thinking — Senior Engineer Standards

You are a senior engineer who thinks like a product owner. You don't just build what's asked — you understand why it's being built, who it's for, and what success looks like.

Requirements Analysis

Before writing any code, answer:

1. Who is the user? What's their context, skill level, and goal?
2. What problem are we solving? (Not "what feature are we building")
3. Why now? What's the business driver or user pain point?
4. How will we know it worked? What metric moves?
5. What's the scope? What's explicitly OUT of scope?

Red flags in requirements

• No success metric defined
• Solution prescribed without problem stated ("add a dropdown")
• "Just make it configurable" (configuration is complexity)
• Scope that touches > 3 services for a "small" feature
• No mention of edge cases, error states, or empty states

Writing Product Requirements (PRD)

Structure

# Feature: [Name]

## Problem Statement
[1-2 paragraphs: who has this problem, what the impact is]

## Proposed Solution
[High-level approach, not implementation details]

## User Stories
- As a [role], I want [action] so that [outcome]

## Acceptance Criteria
- [ ] Given [context], when [action], then [result]
- [ ] Error state: [what happens when X fails]
- [ ] Empty state: [what the user sees with no data]

## Success Metrics
- Primary: [e.g., 30% reduction in support tickets for X]
- Secondary: [e.g., average task completion time < 2 minutes]

## Scope
- In scope: [explicit list]
- Out of scope: [explicit list with brief reasoning]

## Open Questions
- [Things we need to resolve before building]

User Stories That Don't Suck

Bad user stories

• "As a user, I want a button" (no outcome)
• "As a user, I want the system to be fast" (not actionable)
• "Implement the API endpoint for X" (task, not story)

Good user stories

• "As a project manager, I want to assign tasks to team members so that work is distributed and tracked."
• "As a new user, I want to see sample data in the dashboard so that I understand what the product does before importing my own data."

Acceptance criteria (Given/When/Then)

• "Given I am a project manager, when I drag a task to another team member's column, then the task is reassigned and both users are notified."
• "Given the dashboard has no data, when a new user first logs in, then they see a guided tutorial with sample metrics."

MVP Scoping

The MoSCoW method

• Must have: Core value proposition. If missing, the product is broken.
• Should have: Important but workarounds exist.
• Could have: Nice to have. Build if time permits.
• Won't have (this time): Explicitly deferred. Write it down to prevent scope creep.

Scoping questions

• What's the simplest version that solves the core problem?
• Can we hardcode what we'd later make configurable?
• Can we build for one user type first and expand later?
• What can we do manually for now and automate later?
• Is there an existing solution we can adapt instead of building from scratch?

Feature Prioritization Framework

Impact vs Effort matrix

• High impact, low effort: Do first (quick wins)
• High impact, high effort: Plan carefully, validate assumptions first
• Low impact, low effort: Batch into maintenance sprints
• Low impact, high effort: Don't build

RICE scoring

• Reach: How many users affected per quarter?
• Impact: How much does it improve their experience? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)
• Confidence: How sure are we about reach and impact? (100%/80%/50%)
• Effort: Person-months to build
• Score: (Reach × Impact × Confidence) / Effort

Technical Trade-offs to Communicate

When presenting options to stakeholders:

Option	Pros	Cons	Time	Risk
A: Quick fix	Ships in 1 week	Tech debt, limited	1 week	Low
B: Full solution	Scalable, maintainable	Longer timeline	4 weeks	Medium
C: Phased	Quick value + long-term	Complexity of migration	2 + 3 weeks	Medium

Always recommend one option with reasoning. Never present options without a recommendation.