Product Development on Claude Code Wiki

Product Thinking for Engineers

Mon, 01 Jan 0001 00:00:00 +0000

Product Thinking for Engineers#

Executive Summary#

Most engineers build what they’re told to build, and build it well. The gap is that “well” usually means technically sound – correct algorithms, clean architecture, good test coverage – while the thing being built may not solve the problem it was meant to solve. Product thinking is the discipline of questioning what you’re building and why, before optimizing how.

Article	Focus	What You’ll Get
Product Thinking (this page)	Why engineers should care about product work	A concrete example of product-blind vs. product-aware engineering, and how the section fits together
User Research & Validation	Discovering what users need	Interview techniques, assumption mapping, validation methods
Requirements & Specifications	Turning research into buildable definitions	Spec writing, acceptance criteria, traceability
Prototyping & Iteration	Building to learn, not to ship	Throwaway prototypes, feedback loops, iteration discipline
Prioritization & Trade-offs	Deciding what to build next	Impact vs. effort, RICE scoring, opportunity cost, cost of delay, saying no

The Gap Between Building and Solving#

Engineers optimize. Given a problem, they reduce latency, improve throughput, eliminate edge cases, and harden failure modes. This is valuable work. It is also, frequently, the wrong work.

User Research & Validation with Claude Code

Mon, 01 Jan 0001 00:00:00 +0000

User Research & Validation with Claude Code#

Executive Summary#

Engineers skip user research because it feels like a separate discipline – interviews, surveys, affinity diagrams, personas. Most of that overhead is mechanical: reading, categorizing, synthesizing. Claude Code handles the mechanical parts, which means you can do useful research in 20 minutes from your terminal. This article shows you how.

Research Method	What It Tells You	Claude Code Technique
Support ticket analysis	Where users get stuck right now	Feed ticket exports, extract patterns and frequency
Interview transcript synthesis	What users say they need (and what they reveal accidentally)	Load transcripts, pull out themes and contradictions
Competitive analysis	What alternatives exist and where they fall short	Describe competitor features, identify gaps
Usage data interpretation	What users actually do (vs. what they say)	Feed metrics, generate hypotheses for observed behavior
Survey design and analysis	Targeted answers to specific questions	Generate questions from assumptions, analyze response data
Feasibility prototyping	Whether a solution is technically viable	Build proof-of-concept scripts to test core mechanics

Table of Contents#

Why Engineers Skip Research
Support Ticket and Bug Report Analysis
Synthesizing Interview Transcripts
Competitive Analysis
Usage Data Interpretation
Validation Before Commitment
When to Stop Researching

Why Engineers Skip Research#

Research feels slow because it’s unstructured. Writing code has a tight feedback loop – write, run, see results. Research has no compiler. You read a stack of support tickets and come away with vague impressions. You interview three users and get three different stories. There’s no green bar that tells you you’re done.

Requirements & Specifications: From Problem to Prompt

Mon, 01 Jan 0001 00:00:00 +0000

Requirements & Specifications: From Problem to Prompt#

Executive Summary#

You’ve done the research. You know what users struggle with. Now you need to turn that understanding into something precise enough that you – or Claude Code – can build it. This article covers requirement formats, feature decomposition, edge case discovery, and the handoff to spec-driven development. The goal: close the gap between “I understand the problem” and “I can write a build prompt.”

Prototyping & Iteration: Build to Learn

Mon, 01 Jan 0001 00:00:00 +0000

Prototyping & Iteration: Build to Learn#

Executive Summary#

A prototype is a question in code form. You build it to answer a specific question – “can this API handle the load?”, “does this workflow make sense to users?”, “will these two systems integrate?” – and then discard it. This article covers the types of prototypes, when to use each, the Claude Code workflow for running them, and the discipline of deciding what comes after.

Feature Prioritization & Trade-offs

Mon, 01 Jan 0001 00:00:00 +0000

Feature Prioritization & Trade-offs#

Executive Summary#

Every team has more ideas than capacity. The hard part of product work is deciding what to build next and – equally important – what to defer. This article covers prioritization frameworks you can apply to a backlog, the concept of opportunity cost in engineering decisions, the discipline of saying no, and how Claude Code can model trade-offs quantitatively.

Framework	Best For	Inputs Needed	Output
Impact vs. effort	Comparing features against each other	Estimated impact (users, revenue, retention), estimated effort (days, complexity)	2x2 matrix ranking features by ROI
RICE scoring	Large backlogs with mixed feature types	Reach, impact, confidence, effort	Numeric score for stack-ranking
Opportunity cost	Binary build-or-defer decisions	What else the team could build with the same time	Explicit comparison of alternatives
Cost of delay	Time-sensitive features	Revenue or retention impact per week of delay	Urgency-adjusted priority

Table of Contents#

The Prioritization Problem
Impact vs. Effort
RICE Scoring
Opportunity Cost
Cost of Delay
Saying No
Modeling Trade-offs with Claude Code
Worked Example: The Dashboard Backlog
Anti-Patterns

The Prioritization Problem#

A team has twelve features in the backlog, capacity for three this quarter, and stakeholders who each believe their feature is the most important. Without a framework, the loudest voice wins – or the team compromises by starting five features and finishing none.