Find more context and history behind the model in Journey to Product Principles.

Model

Product Principles

Or, Product Pyramid:

Product Pyramid

Product

Focus

  • Product strategy (mission, vision, objectives, success metrics, North Star, etc.) is well-known to the whole team

  • The team is picking improvement ideas carefully and saying “NO” to a lot of things

Powered by Insights

  • Most decisions are based on data/insights

  • A variety of data sources are considered - analytics, customer data, new tech insights, industry trends, engineering team findings, etc.

Transparency

  • Product strategy is communicated clearly and with respective reasoning data

  • There is no feeling of a “hidden agenda”

“Placing Bets”

  • Everyone, especially product leaders, accepts some solutions would not solve the problem and that is the cost of experimenting to find the best solutions that do

  • Product leaders and stakeholders do not hesitate to remove features that do not bring value

Code & System

Code Quality and Tech Debt

  • Unit testing, code maintenance, tech debt tracking, continuous improvement

  • Standards (code conventions, architecture, diagrams, documentation, etc.)

  • Frameworks, tools, third-party libraries, and other dependencies are up-to-date

Automation and Tools

  • The team has proper automation and tools that allow it to move fast (high productivity) and not to break things (high quality)

  • Automation is seen as a necessity rather than a roadblock/obstacle in a process

  • Automating both functional tests and quality attribute (a.k.a. non-functional) tests

Deployment Infrastructure

  • The team is engaged in CI/CD and actively uses, adjusts (when needed), and maintains their CI/CD pipelines

  • The majority (or all) of test automation is part of deployment infrastructure (not separate build jobs)

  • Branching and versioning strategy

  • Release strategy allows small, frequent, uncoupled releases

  • Disaster recovery, restore mechanisms, quick reaction to production incidents

Monitoring and Observability

  • The team can answer most operation-related questions (business outcomes related and technical) via observability

  • Metrics, signals, and KPIs are balanced and distributed across Product (North Star, business success metrics), System (SLAs), Code, and Processes

  • Business value discussions focus on Product and System KPIs, and Code and Process KPIs are used mostly for diagnostic/debugging purposes

Teamwork & Process

Outcomes over Output (Results over Effort)

  • Understanding of value and quality is based on product strategy and business outcomes, not delivered volume of code/features (or story points)

  • Progress is measured by outcomes, not effort (as effort without progress is useless)

Flow

  • Delivering fast and making work visible

  • Limiting work-in-progress (WIP)

  • Reducing batch sizes

  • Reducing hand-offs between teams

  • Identifying and removing constraints and waste

Sense of Ownership

  • Team efforts translate to meaningful outcomes, so the team owns those outcomes and cares to deliver results

  • The whole team cares for quality

Empowered with Problems to Solve

  • Incoming requests (tasks) are based on problems to solve, not solutions to implement

  • Business stakeholders and product leaders understand they do not know what is possible in engineering

Responsible Testing / Testing Breadth

  • The testing strategy is well-known to the whole team and aligns with the broader quality strategy and product strategy

  • Versatile testing techniques are applied, testing happens in a variety of places (see Holistic Testing) and covers a variety of quality attributes (a.k.a. non-functional requirements) - security, performance, accessibility, usability, etc.

  • There are mechanisms to test/validate small increments frequently in production and/or with business (UAT, A/B testing, (key) user testing, etc.)

  • Prevention over detection. Detected findings drive continuous prevention improvements.

  • The testing approach is responsible - existing value is protected while experimenting and moving fast

Collaboration

  • Not a democracy - decisions are owned by subject experts (only they know what is possible)

  • However, experts are not made bottlenecks

  • Most feedback loops (within the team, with stakeholders, with leadership) are short and fast

  • The whole team cares for quality

Rapid Validation and Experimentation (“Fail-Fast”)

  • Ideas, prototypes, and solutions are tested early and quickly (both in Product Discovery and Product Delivery)

  • Then, minimizing waste - eliminating what’s not working before over-investing

Culture

Trust over Control

  • Leaders are leading with context, not command-and-control

  • There is a safe and constructive environment to speak up, voice ideas, provide feedback, and suggest improvements

Principles over Process

  • The team knows their core principles (values) well and shapes processes around them

  • The team has high flexibility to change most of the processes and drives continuous process improvement

Innovation over Predictability

  • Product Mindset over Project Mindset

  • Business Outcomes over Delivering Features

  • Long-term investment/strategy over the time-boxed project budget

  • Time to money/value/outcomes over (feature) time to market

Learning over (Fear of) Failure

  • The team emphasizes the value of learning (frequent and varied retrospectives, root cause analysis of customer issues, reading and listening to books, webinars, attending conferences and training)

  • Continuous improvement over blaming and finger-pointing. Even though some experiments/features will result in poor outcomes (a.k.a. failures), the team is encouraged to experiment and innovate.

Well-being and Satisfaction

  • The team is feeling well, satisfied, and motivated