This is the second in a series of articles on the product operating model. To recap, it has three dimensions.
- The right problems to solve
- The right solutions to the problems
- Solutions delivered the right way
This and the next articles will examine the three dimensions in more depth, starting with solutions delivered the right way. They will combine my practical experience with insights I’ve collected from various sources.
In an attempt to focus, I’ll here and in the next articles assume the product “only” to be software-based, a radical simplification compared to IE (see previous article).
Assumptions
The right problem to be solved has been identified, and the discovered solution has been verified to be valuable, usable, feasible, and viable through hypothesis testing.
At this point, the empowered product team is confident that the solution discovered is worth implementing.
Waterfall?
The above illustration suggests a waterfall process, with product delivery after product discovery. It is not. In practice, the team will iterate between solution discovery and product delivery, as illustrated in my article on Product Discovery.
… many companies put a heavy emphasis on delivery – they focus on whether you shipped what you said you would on time and on budget – while under-investing in discovery, forgetting to asses if you built the right stuff.
Teresa Torres, Continuous Discovery Habits p. 13-14
What we deliver must adhere to our quality brand
We do not present our customers with some half-baked “MVP.” What we deliver to our customers are production-grade solutions. MVPs and other types of prototypes are great tools for supporting product discovery.
To avoid any misunderstanding, it’ll be evident below that we strive for continuous delivery, delivering production-grade solutions in small batches, and optimizing for short feedback loops. We go to great lengths to ensure the built-in production-grade quality.
Right, so how do we build in quality?
Accelerate Appendix A provides 24 key capabilities that statistically significantly drive improvements in software delivery performance.
Note on page 86 on team experimentation: “We’re not proposing that you set your developers free to work on whatever ideas they like. “
Reflecting on the product operating model, I would rephrase this: “We’re not proposing that you set your product team free to work on whatever problem they like. Through our product strategy, we decide what problems to solve. We empower our product teams to discover solutions to problems. Setting hypotheses and testing through experimentation is a core aspect of our teams.“
Despite not being explicit about product teams empowered to discover solutions to customer/business problems, Accelerate is still a treasure trove of valuable insights. Among the 24 capabilities, many are highly relevant to the product operating model.
Continuous delivery
- Use version control for all production artifacts: Control the version of nearly everything. This is the foundation of a solid configuration management practice in the Deployment Pipeline.
- Automate your deployment process: Deploying automatically to production is the best thing to do in some scenarios, and in other scenarios, it must be a business decision.
- Implement continuous integration (CI): CI is foundational for CD. No real CI, no CD. Martin Fowler on CI: “Continuous Integration is a software development practice where each team member merges their changes into a codebase together with their colleague’s changes at least daily.”
- Use trunk-based development methods: “Trunk” is another name for the main line. CI expects to merge to the trunk at least daily. We’ll have no, or at least very short-lived, feature branches. A strong culture of collaboration and shared ownership is needed for CI and trunk-based development.
- Implement test automation: This is one of the key characteristics of the Deployment Pipeline. A massive battery of automatic acceptance/regression tests is needed.
- Support test data management: Managed test data under configuration management control is also a key characteristic of the Deployment Pipeline.
- Shift left on security: Ensuring cybersecurity is not an afterthought. It is designed and built in from the start.
- Implement continuous delivery (CD): A logical extension of CI.
Dave Farley is the undisputed king of continuous delivery, with Continuous Delivery and Continuous Delivery Pipelines, among other books. Dave Farley recommends we become proficient in these practices (yes, resonating with Accelerate):
- Reduce the Cycle Time
- Automate Nearly Everything
- Control the Variables
- Work in Small Steps
- Make Evidence-based Decisions
- Work in small, Empowered Teams
- Apply Lean & Agile Principles
I highly recommend reading all of Dave Farley’s books, Continuous Delivery, Continuous Delivery Pipelines, and Modern Software Engineering.
Architecture
- Use a loosely coupled architecture: This helps teams work and deploy independently and maintain a high release cadence.
- Architect for empowered teams: Accelarate’s definition is not as far-reaching as the empowered product team in the product operating model. Accelerate, page 204: “Our research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance.” In the product operating model, the product teams are empowered to discover (valuable, usable, feasible, & viable) solutions to problems. The choice of tools is only a small fragment of the larger empowerment.
Product and process
- Gather and implement customer feedback: This is at the core of empowered product teams, with direct and high-frequency customer interaction.
- Make the flow of work visible through the value stream
- Work in small batches: This helps shorten the feedback loops.
- Foster and enable team experimentation: This is at the core of product discovery and testing hypotheses on the solution’s value to the customer, usability for the customer, feasibility for us to build, and viability for our business.
Lean management and monitoring
- Have a lightweight change approval process: The product team is empowered to discover solutions to problems and is held accountable for the outcome. It does not rely on some external change approval board. Highly efficient product teams avoid lengthy PR (pull requests) blocking flow using, e.g., pair programming.
- Monitor across application and infrastructure to inform business decisions
- Check system health proactively
- Improve processes and manage work with work-in-progress (WIP) limits: How the product team stays focused is at the team’s discretion.
- Visualize work to monitor quality and communicate throughout the team: Transparency of status is one of the characteristics of the Deployment Pipeline.
Cultural
- Support a generative culture (as outlined by Ron Westrum): A culture of product teams empowered to discover solutions to problems and strong management facilitating cross-team collaboration.
- Encourage and support learning. Is learning, in your culture, considered essential for continued progress? Innovation and learning through disciplined experimentation in the product teams and Communities of Practices across teams.
- Support and facilitate collaboration among teams: The product teams are cross-functional, and management facilitates cross-team collaboration.
- Provide resources and tools that make work meaningful: If not, why hire smart people in the first place?
- Support or embody transformational leadership: Product teams are provided with the strategic context (business mission and strategic objectives, product vision, and product strategy) to discover solutions to problems. Management lives and inspires the values and principles of DevOps.
Yes, that is a mouthful. One important takeaway is the duality that
quality needs speed (small steps with short feedback loops), and speed needs quality,
they go hand in hand.
This may, at first glance, sound counterintuitive. Do you not need a lot of time to provide quality?
To illustrate the point, let’s look at two distinctly different scenarios.
Scenario #1:
(Very) long feedback loops
This organization has chosen to separate feature development from system integration and testing. The self-understanding is being “agile,” though I would describe the way of working as “water-scrum-fall.”
In this scenario, the teams are given features (solutions) to implement, not problems to solve.
A developer committing some code can experience 180+ days of feedback length on system level. The feedback from customers is even longer.
Not surprisingly, organizations having this way of working are experiencing poor quality and returning panic getting the quarterly release out the door. Having a long time does not resonate with providing great software.
Poor software, slowly, unhappy customers!
Yes, some organizations will work this way in 2025.
Scenario #2:
(Very) short feedback loops
Running the product operating model, this organization appreciates the duality that quality needs speed (short feedback loops) and speed needs quality.
It has implemented Continuous Delivery by Dave Farley. It stands on three legs:
Dave Farley consistently uses the term “Deployment Pipeline.” It covers what is traditionally known as “CI/CD pipelines.” Cut to the bone, the Deployment Pipeline must, as fast as possible, provide answers to the questions
- Is my code technically correct?
- Is the system releasable?
The organization has potentially deployable release candidates at a daily cadence. When to release to customers is a balanced business decision.
Great software, fast, happy customers!
Continuous Delivery is today the norm in many of the world’s most successful software organizations.
DevOps culture and scaling
Thinking “DevOps” in the culture leg above, you’re close. You’ll find a lot of definitions on DevOps. This one from ThoughtWorks seems to catch the essence:
A culture where people, from a range of disciplines, work together to design, develop, deploy and operate a system.
DevOps is a way of working that stresses the need for cross-functional teams — from a huge variety of backgrounds — who have ownership of the systems they’re working on. It’s a cultural approach, not something that you buy.
“You build it, you run it” is a software development and management approach where the team that builds a piece of software also remains responsible for its maintenance and management throughout its lifecycle.
It’s an important aspect of DevOps cultures, where people from a range of disciplines work together to design, develop, deploy and operate systems, services, and applications.
Scaling
It looks very fine and dandy; what’s not to like?
In a relatively small organization with only a few product teams and a not too complicated product, this is great. No throwing stuff over the fence. Teams own it end-to-end.
As your organization grows with additional product teams and as the complexity of your product and enabling technologies grows, the cognitive load on your product teams grows to an unmanageable extent. Such a loss of bandwidth to focus on the customers is business-critical.
The mitigation is to keep the cognitive load on the teams at a balanced level. You might remember the strategic context described in my first article on the product operating model, including the product team topology.
In Team Topologies, Matthew Skelton & Manuel Pais provide a framework for exactly that; managing the cognitive load in a balanced way. I recommend reading the book.
Team Topologies suggest a range of team types and a set of interaction modes. For the sake of illustration, I’ll here only use the two team types
- Stream-aligned team (product team), serving the customers
- Platform team, serving the internal customers, the stream-aligned teams
and the “X-as-a-Service” interaction mode.
Internal product management
The rationale is to have a platform team provide a range of internal products and services to the stream-aligned teams (aka the product teams) to offload the otherwise excessive cognitive load impeding focus on the customers.
We want the platform teams to apply the same product management principles used by the product teams, with product vision and insights-driven product strategy, deciding what problems to solve. This is a delicate balance, finding the level of abstraction that benefits the product teams most. The platform team must understand the jobs to be done, the pains, and the desires of the product teams.
Developer Experience - DX
An obvious product for the platform team to provide is the Deployment Pipeline infrastructure, tooling, and plumbing with a range of (self-)services. We improve developers’ experience in delivering solutions to customers. It has been coined DX, and it is a big deal.
You’ll find many definitions of DX. The one to the right is from acmqueue with, e.g., Nicole Forsgren, one of the authors of Accelerate.
With inspiration from acmquque
These are the definitions from acmqueue on the three dimensions:
Feedback Loops
Also, scenario #2 above.
“Software organizations commonly look for ways to optimize their value stream by reducing or eliminating delays in software delivery. This allows faster feedback and learning about what is being built, which in turn allows for more rapid course correction. Studies have consistently shown that organizations deploying more frequently and maintaining shorter lead times are twice as likely to exceed performance goals as their competitors.”
Cognitive Load
Also, DevOps scaling above.
“Software development is inherently complex, and the ever-growing number of tools and technologies is further adding to the cognitive load faced by developers. Cognitive load encompasses the amount of mental processing required for a developer to perform a task. For example, cognitive load typically increases for a developer working on an inherently difficult or complex task, or learning to understand an unfamiliar development framework. Cognitive load also varies according to how external information is presented and increases when mental processing is required for translating information into longer-term domain knowledge and models.”
Flow State
“Developers often speak of “getting into the flow” or “being in the zone.” Such statements colloquially describe the concept of flow state, a mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment.
Frequent experiences of flow state at work lead to higher productivity, innovation, and employee development. Similarly, studies have shown that developers who enjoy their work perform better and produce higher-quality products. Interruptions and delays—which relate to the feedback loops dimension—are important factors that hinder a developer’s ability to experience flow state.”
Wrap-up
The main suggested takeaway would be to optimize for DevEx. In its wake, you’ll naturally come to address Continuous Delivery (remember its three legs) and DevOps scaling.
I could also in this article have addressed Domain-Driven Design (DDD), Test-Driven Development (TDD), Behavior-Driven Development (BDD), test strategies, the team sport called Continuous Integration, the automated Deployment Pipeline, Infrastructure as Code (IaC), version control, configuration management, cybersecurity like IEC 62443, cloud computing, microservices, etc.
I did not. Some of these themes may be in future articles.
More inspiration
Dave Farley on Continuous Delivery, Software Engineering, Deployment Pipeline, and “dual-track agile” (though he does not explicitly use that term) at the 2024 GOTO Conference.