Product Principles

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

Model

Or, Product Pyramid:

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

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.

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

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

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

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

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)

Team efforts translate to meaningful outcomes, so the team owns those outcomes and cares to deliver results
The whole team cares for quality

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

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

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

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

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

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

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.