shaping-product-appetites - SKILL.md Agent Skill

name: shaping-product-appetites description: A framework for defining product features within a fixed time budget (appetite). Use this when projects are consistently dragging, when there is a "wall" between design and engineering, or when you want to replace dense PRDs and high-fidelity mockups with actionable, de-risked concepts.

Shaping Product Appetites

This framework shifts product development from "estimating how long a feature will take" to "deciding how much time we are willing to spend" (the Appetite). It ensures that by the time a project reaches the build phase, the major "rabbit holes" and "time bombs" have been cleared by a collaborative triad of Product, Design, and Engineering.

Core Principles

Fixed Time, Variable Scope: You commit to a time box (usually 2, 4, or 6 weeks) and adjust the feature's complexity to fit that box.
The Triad: Shaping must involve Product (business context), Design (user flow), and Engineering (technical feasibility) simultaneously.
Fat Marker Fidelity: Ideas are sketched at a level that is "sharp enough to understand, but fuzzy enough to leave room for the builders' creativity."

The Shaping Workflow

1. Frame the Problem

Narrow the scope to a specific, valuable problem rather than a generic feature.

Bad Frame: "Build a calendar."
Good Frame: "Users need to see empty spaces to book appointments because the current agenda view only shows scheduled items."

2. Set the Appetite

Determine the "budget" for the solution.

Small Batch: 1–2 weeks for minor improvements.
Big Batch: 4–6 weeks for significant features.
Constraint: If it takes longer than 6 weeks, it cannot be "seen from the beginning." Break it down into smaller, independently shippable shaped pieces.

3. Conduct the Shaping Session

Bring the triad (PM, Designer, Senior Engineer) into a room with a whiteboard (physical or digital).

Identify Rabbit Holes: The "grumpy old plumber" (Engineer) should look at the code/infrastructure during the session to identify hidden complexities.
Breadboarding: Map out the flow using only text and arrows (e.g., [Button: Create Event] -> [Form: Event Details] -> [Success Message]).
Fat Marker Sketching: Use thick lines to draw the UI. If you can't draw the idea with a "fat marker," you are getting too detailed and micromanaging the build team.

4. Define the Moving Parts

A well-shaped project should have fewer than 10 moving pieces.

Example: "1. Two-month dot grid, 2. Scrolling agenda view, 3. 'New' button, 4. Event creation modal."

5. The Build Kickoff: Nine Boxes

When handing off to the build team, have them perform the "Nine Boxes" exercise:

Draw a 3x3 grid.
The team must identify the ~9 major "scopes" of work required to finish the project.
If it requires significantly more than 9 boxes, the project is likely over-scoped or under-shaped.

Examples

Example 1: The Calendar Update

Context: Users complain they can't see when they are free.
Appetite: 6 weeks.
Shaping Output: Instead of a full Google Calendar clone, the team shapes a "Dot Grid" view.
- Concept: A two-month view where days with events have dots.
- Interaction: Tapping a day slides an agenda view underneath.
- Technical Check: Engineer confirms the existing API supports "dots per day" without a new database schema.
Result: The team ships a functional, high-value "empty space finder" within the 6-week appetite.

Example 2: FinTech Onboarding Optimization

Context: High churn on the "Bank Info" step of a funnel.
Appetite: 3 weeks.
Shaping Session: The PM suggests piping data from a partner API to skip the step.
The Rabbit Hole: The Engineer opens the code and finds three different branching paths for different bank integrations.
The Trade-off: The triad decides to shape the solution for the top 80% of users (Bank A and B) and leave the old flow for Bank C to fit the 3-week appetite.

Common Pitfalls

Shaping in Isolation: PMs writing PRDs or Designers making high-fidelity Figmas without Engineering input. This leads to "time bombs" discovered in week 4 of a 6-week cycle.
The Paper Shredder: Breaking a shaped idea into 100 tiny Jira tickets. This destroys the team's ability to see the "whole castle" and make creative trade-offs.
Estimating vs. Appetite: Asking "How long will this take?" instead of "What is the best version of this we can build in 4 weeks?"
The "Over-easy" Hand-off: Giving a team a fuzzy goal (e.g., "Improve the dashboard") without shaping the boundaries. This causes the team to spin in circles.