samarv 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.