Home / Product Development Principles
Leadership Alignment: These principles represent our shared understanding of how we build products. It may take time to fully embody them, but we commit to this direction.
How Principles Connect
Story Quality
INVEST Framework
Story Criteria
5 Characteristics
Shippable, Consumable...
↓ enables ↓
Product Philosophy
Product is Whole
Not Pieces
Continuous Improvement
Not Perfection
First Principles
Think Deeply
↓ drives ↓
Execution Culture
Transparency
Creates Innovation
Speed
Over Precise Dates
Minimal Process
Teams Decide
Principles at a Glance
User Story Definition
A well-crafted user story is the foundation of successful product development. Every story should meet these five characteristics:
| Characteristic |
Definition |
Why It Matters |
| Shippable |
Can go to production on its own; independently testable |
Enables continuous delivery and reduces integration risk |
| Consumable |
When feature-gated on, the user can use it for the stated benefit |
Ensures real value delivery, even if partial to the overall goal |
| Well-defined |
Comprehensive details created with Product, Business, and Tech involvement |
Reduces ambiguity and rework during development |
| Estimatable |
Team can provide a reasonable "guesstimate" to build it |
Critical for sprint planning and capacity management |
| Time-bound |
Shippable within a single sprint's timeframe |
Large stories must be broken down while retaining other characteristics |
Breaking Down Stories: Large stories may be split during sprint planning, but each resulting piece must still be shippable, consumable, and independently valuable.
INVEST Framework
Another lens for evaluating user story quality. Good stories are:
| Letter |
Principle |
Description |
Example |
| I |
Independent |
Not dependent on other stories; shippable on its own |
"View Orders" is independent of "Edit Order" - each is a separate story |
| N |
Negotiable |
Scope is discussable; processes already agreed beforehand |
"View All Orders" might be negotiated into separate "View Orders" and "Filter Orders" stories |
| V |
Valuable |
Delivers value to a user of the product |
Value may not always be a metric change, but must benefit someone |
| E |
Estimable |
Small enough for teams to estimate if doable in two weeks |
If team can't estimate, story needs more definition or splitting |
| S |
Small |
Fits within a sprint timeframe |
Stories over 8 points should be split |
| T |
Testable |
Clear acceptance criteria that can be verified |
Scenarios should read like test cases |
PRD = Acceptance Criteria = Test Cases: When scenarios and use cases are well-detailed, they should look similar to test cases. A great PRD serves as requirements document, acceptance criteria, and test cases in one.
Product is a Whole, Not Pieces
Customers do not see or benefit from part of the product - they can only rely on the whole product.
- Non-integrated and shipped software has no value "yet" - Value is only realized when customers can use it
- Teams are NOT done when their part is done - They're done when the whole value is shipped and realized
- Optimize for the whole product - Not for individual teams or components
Key Mindset: The goal is customer value, not completed tasks. A feature in staging is not value delivered.
Matrix Organizations Are Real
Mid to large teams must balance two structures. Both are necessary; over-indexing on either causes problems.
Organizational Structure
Along Domain & Tech Skills
- Example: App Teams, X Service Team, Y Service
- Purpose: Growth of individuals, deep expertise
- Managed by: Engineering Managers
Execution Structure
Along Business/Customer Value
- Example: Customer Call Centre, Buying Experience
- Purpose: Consumer value delivery
- Managed by: Technical Leads
Warning: Over-indexing on one structure will cause the other to fail and create mismatches in expectations at individual and company level.
Chase Continuous Improvement, Not Perfection
There is no state of "perfect product" or "perfect architecture." Systems evolve based on current requirements plus reasonable assumptions about the future.
- No big batch "initiatives" or "products" - Use extremely short cycles of improvement
- No big upfront design - We don't know precisely what we'll build two months from now, and that cannot be estimated
- Features are good if they create consumer delight and move metrics - This is good enough
- Iterate until current state is good enough - Then move on
- Everything is in perpetual WIP - Documents and concepts start rough; don't wait for "ready" or "perfect"
- Ship customer value every iteration - Potentially shippable products in each small iteration
Working software over perfect documentation. Don't let the perfect be the enemy of the good.
Systems and First Principles Thinking
Think deeply first. Then do. But do this fast.
A "first principle" is a foundational proposition that cannot be deduced from other propositions. Systems and products must be imagined on strong foundational concepts.
Key Practices
- Understand System Dynamics - Technologists are good at breaking static structures down but often miss the dynamic complexity of products
- Build Strong Mental Models - Base them on foundational concepts that are intuitive. If models are hard to explain, go deeper - your mental model isn't strong enough yet
- Avoid Local Optimizations - When you measure "work done" or "effort," you subconsciously make decisions that optimize locally (your team, yourself, your component). Resist this.
- Debate and Produce Concept Notes - Writing expands your scope and vision of the product. Use it as a thinking tool.
Mental Model Test: If you can't explain a concept simply, you don't understand it deeply enough. Go back to first principles.
Transparency Creates Innovation
Without transparency, it is hard to adapt and be agile. Concepts, decisions, and value created must be transparent.
- When ideas are transparent, more thoughts flow in - Quality of solutions improves
- Transparency enables adaptation - Teams can self-correct when they see the full picture
- It's the hardest principle to follow - It's discomforting for everyone
- Some transparency comes from ceremonies - But true transparency comes from mature execution teams
Lived By: Ceremonies, demos, shared documentation, open discussions. Make the implicit explicit.
Speed Over Precise Landing Dates
The ability to move fast and change direction trumps hitting exact deadlines.
- Transparency + Speed = Trust - When we show speed (value delivered in iterations), focus shifts from "missed deadlines" to "how to get more value in time"
- Optimize to be faster and iterative - Be less focused on getting "precise" with dates
- Precise dates cannot be achieved at scale - Not without "big upfront planning design" which conflicts with agility
- Focus on the next two sprints - Land them well. That's your commitment horizon.
Commitment Horizon: We commit to the current sprint. We plan the next sprint. Beyond that is intentionally fuzzy.
More With Less Process
We need just enough process that enables these principles and keeps teams at the center of decision-making. Nothing more, nothing less.
- Process enables speed - It doesn't replace judgment
- Right-size everything - Match process rigor to item complexity
- Remove friction, not add bureaucracy - Use retrospectives to continuously simplify
- Teams decide execution details - Process guides, doesn't dictate
The Test: If a process step doesn't directly enable one of these principles, question whether it's needed.