🥳  No mês de Aniversário da Caroli.org, você estuda com 30% off usando o cupom: 7ANOSCAROLI. Escolha o seu treinamento!


Precisa de ajuda para escolher o seu
treinamento ou tem alguma dúvida?

Triple Track Development: Business Innovation Through Continuous Discovery and Continuous Delivery

Triple Track Development represents a transformative methodology that operates on three parallel tracks, seamlessly intertwining to create a comprehensive approach to digital product development and innovation. These tracks – Business Strategy, Discovery, and Delivery – function continuously, driving the heartbeat of digital product development.  The Business Strategy track sets the high-level direction, the Discovery track refines ideas through assumption validation and experimentation, and the Delivery track translates these refined concepts into tangible, market-ready product features. Together, they form a dynamic framework that shapes the future of business agility and innovative product development practices.

Introducing the Triple Track Development, connecting the HOW, the WHERE TO, and the WHAT

I’d like to introduce you to a straightforward concept: I call it ‘Continuous Triple Track Development,’ or simply ‘Triple Track Development’ for short. It’s a way of working that’s continuous in all aspects – from setting directions and goals (WHERE TO go next) to discovering new ideas and opportunities (WHAT to work on); and delivering features and products (HOW to build it). This approach is an evolution of software engineering practices from the last decades.

Back in the 90s, when I began my journey as a developer, things moved slowly. We spent months crafting software based on detailed plans, sometimes even putting them in boxes with manuals and CDs. Can you believe it? Some of these digital products even included the year they were released as part of their names!

I worked as a developer for almost twenty years, and things changed a lot during that time! Back in the early 2000s, we started having continuous integration for the code. Then, around 2011, we shifted to continuous delivery. This meant that every new feature my team created was quickly added to the digital product. It was a big change in HOW we developed software.

My colleagues Jez Humble and David Farley wrote the definitive book on Continuous Delivery. It’s a must-read for anyone involved in software delivery!

continuous triple track

continuous triple track development

The changes aren’t just about delivering digital products faster. Businesses have also evolved. Instead of planning everything annually, modern organisations, set goals every few months. We use Team OKRs to guide our teams. We start with the WHERE TO, which define as quarterly OKRs then we meet regularly to review our plans based on these OKRs. It’s a continuous business strategy recalibration process, always reviewing and adapting.

In the midst of this fast-paced business and technical environment, there’s a need for connecting the WHERE TO with the HOW. We must be effective and efficient. We must target WHAT to build, we must comprehend the business challenges, the users, and the customer’s needs, collaborate, and discover solutions that lead to the creation of successful and user-centric products and services. That’s where continuous discovery comes in – an ongoing journey of learning, experimenting and adapting.

Teresa Torres wrote the definitive book on Continuous Discovery, making it a must-read for anyone involved in crafting products that meet user needs.


Triple Track & the Mathematics of Collaboration: 1+1+1 > 3

Consider three people pulling a heavy object. Each person represents one important factor of this equation: Business Strategy, Continuous Discovery, and Continuous Delivery. Individually, each person can exert a certain amount of force (representing their individual capabilities). Mathematically, this can be represented as follows:

Individual Effort (A + B + C)result


  • A represents the contribution of Business Strategy.
  • B represents the contribution of Continuous Discovery.
  • C represents the contribution of Continuous Delivery.

Now consider the same three people, well aligned and working as a team to pull a heavy object. When they work together as a team, their combined effort can often achieve more than the sum of their individual efforts.

Synergistic Effort (A + B + C + Synergy)greater result

In a synergistic collaboration, there is an additional “Synergy” factor that represents the combined effect of working together. This synergy can arise from enhanced communication, shared insights, validated ideas, and mutual support. It is the team work synergy!

While the specific mathematical value of “Synergy” might be challenging to quantify precisely, the concept illustrates that the combined effort of the team is greater than the sum of their individual efforts. This enhanced collective capability often leads to more effective problem-solving, creativity, and innovation, demonstrating the qualitative aspect of synergy in collaborative endeavours.


Think Threefold Cord instead of 3 separate tracks: Business Strategy, Discovery, and Delivery in Harmony

Imagine you have a rope to pull something. Now, consider two other colleagues also have ropes to pull something. If the 3 of you combine your efforts and pull the same thing, you can get a bigger result, a bigger impact. To guarantee alignment, consider you have a Threefold Cord instead of those three separate ropes.

3 people (as a team) pulling together

3 people (as a team) pulling together

In the world of digital products and innovation, amazing results is like that thing being pulled. The ropes represent important aspects: Business Strategy, Continuous Discovery, and Continuous Delivery. Each part is powerful alone, but when you put them together, they make something even stronger.

So, instead of thinking about Business Strategy, Continuous Discovery, and Continuous Delivery as separate tracks, think of them as interlaced ropes, like the threefold cord represented in the image below.

Threefold Cord: Business Strategy, Discovery, and Delivery

Threefold Cord: Business Strategy, Discovery, and Delivery

Business Strategy is the first cord giving direction and purpose. Continuous Discovery, the second cord, is about always learning, exploring and finding better ways. Continuous Delivery, the third cord, is transforming ideas into product features.

When you intertwine these three cords, it signifies more than just parallel tracks; it demonstrates a profound alignment and connection. The Threefold Cord represents the triad of Business Strategy, Continuous Discovery, and Continuous Delivery, ensuring adaptability and guaranteeing success.

The threefold cord analogy is powerful, illustrating the seamless integration of Business Strategy, Discovery, and Delivery. Despite its appeal, for the sake of consistency, simplicity, and to facilitate clear visual representation and explanation of their connections, I have decided to stick with the nomenclature of ‘Triple Track Development’.


Triple Track Development: Synchronising Business Goals, Product Discovery, and Delivery

Triple Track Development, an extension of the Dual-track development that adds the Business Strategy track, is a holistic approach that addresses business, product, and technical aspects. It focuses on the ongoing pursuit and alignment of business strategy through Continuous Discovery and Continuous Delivery processes.

In today’s fast-paced business world, companies have shifted away from rigid yearly plans and embraced the continuous pursuit of Business Strategy.This approach involves setting significant goals and guiding their teams through Team OKRs (Objectives and Key Results), encouraging them to work diligently to accomplish these objectives every few months. These teams review their OKRs regularly, usually on a bi-weekly basis, to assess their progress and confirm they are heading in the right direction. Business strategies are no longer fixed for a whole year; instead, it’s a continuous effort to achieve more.

Meanwhile, agile delivery teams, responsible for creating digital products, have streamlined how they deliver software through Continuous Delivery. They efficiently use tools to test new features, monitor product performance, and work on small changes. These changes are released frequently, sometimes even multiple times per day, ensuring a constant flow of improvements and features to users.

In the midst of Business Strategy and Continuous Delivery, organisations must also engage in Continuous Discovery. This means they need to continuously understand upcoming challenges, coordinate efforts, and explore solutions worth developing. It’s an ongoing process of learning, experimenting adapting, and finding valuable solutions for users and customers.


Triple Track Development = Dual track development + Business Strategy

Triple track development has its roots in Dual Track Development, a term coined by my colleague, Jeff Patton. I’ve extended this approach and named it Continuous Triple Track Development, emphasising the newest track and its continuous nature across all levels: delivery, discovery, and business strategy.

If you haven’t already, I encourage you to read Jeff Patton’s main article on Dual Track Development to grasp its fundamental principles.


Dual Track Development: Discovery and Delivery

Dual track development recognises that software development isn’t a linear process; it’s inherently iterative and involves two parallel tracks:

  1. Discovery Track: This track focuses on exploration and learning. It involves activities like user research, user interviews, and prototyping. The goal is to identify user needs, pain points, and potential solutions.
  2. Delivery Track: This track is where the actual development takes place. It involves coding, testing, and releasing features based on the insights gained from the discovery track.
dual track development

dual track development

The image above illustrates Continuous Delivery and Continuous Discovery with two arrows labeled “Discovery” and “Delivery.” Additional notes highlight the interactions between Discovery and Delivery:

  • From Insights & Ideas (Discovery) to Implementation & Development (Delivery): Discovery teams focus on gathering insights and ideas to understand business context and user needs. They utilize tools like research, interviews, and prototyping to validate assumptions and decide which features or product ideas to pursue.
  • From Feedback & Learnings (Delivery) to Interactive Exploration (Discovery): Teams practicing continuous delivery make rapid changes and additions to their product, often multiple times a day. These quick deliveries, often MVP (Minimum Viable Products), provide the basis for user feedback and real usage data. This feedback enriches the discovery process, allowing teams to validate assumptions not only through pre-software solutions like prototypes but also with real-time usage data. Techniques such as A/B testing, facilitated by dedicated platforms, enhance this live-data validation process.


Continuous Triple Track Development

By adding the word “continuous,” I want to explicitly highlight that the Triple Track Development approach operates continuously across all facets of development: from the ongoing process of discovery and the delivery of new features to the strategic alignment with business objectives via Team OKRs. The shift from dual track (for discovery and delivery) to triple track signifies the inclusion of a dedicated track for business strategy, thus completing the frame: business strategy, discovery and delivery.

To provide a Triple Track Development visual, I have added one more arrow to the previous presented Dual track development image.

continuous triple track

continuous triple track development

Triple Track Development recognises that product development isn’t a linear process; it’s inherently iterative and involves three parallel tracks, that runs continuously during the product lifetime:

  1. Business Strategy Track: This track focuses on comprehending the overarching business goals, defining team OKRs, and ensuring strategic planning, goal setting, as well as regular reviews and adjustments.
  2. Discovery Track: This track focuses on exploration and learning. Activities such as market analysis, user research, interviews, and prototyping are conducted to identify user needs, pain points, improvements and potential solutions.
  3. Delivery Track: This track involves the actual development process, including coding, testing, and releasing product features based on insights gained from the discovery track.

The tracks must be in harmony with each other (remember the threefold cord analogy). At any moment in time, any team member must be able to pinpoint: this delivery task is related to this validated discovery assumption which we believe will have an impact on this business outcome.

Similarly, a person doing discovery must be able to explain: this discovery work is to generate insights and ideas for coming up with a feature to build that we believe will achieve this business outcome.

A businessperson should be able to say: this is our team OKR. Based on it, we have discovered a few things which helped us formulate a plan for the MVP that we are quickly building. Once it is ready, we will put it in the hands of a few real users. And then we will have data to help us decide the next discovery and delivery steps to achieve our team OKRs.

I will now decompose the triple track image in three:

  • Business Strategy and Discovery
  • Business Strategy and Delivery
  • Delivery and Discovery (already covered in the section above, Dual Track Development: Discovery and Delivery)


Business Strategy and Discovery

business strategy and continuous discovery

business strategy and discovery

The image above illustrates Business Strategy and Continuous Discovery with two arrows labeled “Business Strategy” and “Discovery.” Additional notes highlight the interactions between Business Strategy and Discovery:

  • From Team OKR definition (Business Strategy) to Assumptions and Experiments (Discovery): Teams define their strategic goals via the OKR framework where they state clearly where they want to get to and how to measure progress. This will guide the discovery in creating and validating assumptions and running many experiments to help define the things to do to achieve the desired outcomes.
  • From Exploratory results (Discovery) to Team OKR review (Business Strategy): Discovery teams gather data from the work done to validate the users and customers behavioural changes. This provides insightful business information to review and adjust the strategic direction.

I recommend the following article by Teresa Torres on assumption validation: Assumption Testing: Everything You Need to Know to Get Started.


Business Strategy and Delivery

Continuous Business Strategy and Continuous Delivery

Business Strategy and Delivery

The image above illustrates Business Strategy and Continuous Delivery with two arrows labeled “Business Strategy” and “Delivery.” Additional notes highlight the interactions between Business Strategy and Delivery:

  • From Team OKR definition (Business Strategy) to MVP plan (Delivery): Teams define their strategic goals via the OKR framework where they state clearly where they want to get to and how to measure progress. This will guide the delivery in planning the MVP, the simplest version of the product to validate the business assumption. The MVP plan has the backlog of work (output) to be worked on for achieving the desired outcome (stated on the Team OKR).
  • From Output & MVP usage data (Delivery) to Outcome & Team OKR review (Business Strategy): Delivery team releases changes and features for the MVP / product increment which provides usage data. This data accounts for the Key Results and outcome achievements to be updated on the Team OKR review.


Triple Track Development, the complete picture

On the sections above I have explained the connections and interactions between each of the tracks: Business Strategy, Discovery, and Delivery. Now, on the image below is the complete image.

Continuous Triple Track Development, the complete picture

Triple Track Development, the complete picture

It is lots of arrows connecting the tracks (six to be more precise): business to discover, business to delivery; discovery to business, discover to delivery; and delivery to business, delivery to discovery. It might feel like a lot, but it is the reality on the ground for any team that excels for continuous business strategy, continuous discovery and continuous delivery.


Building a Unified Team: Triple track, one team

It is important to emphasise that utilising the triple track approach does not imply you have different teams for each track. It is quite the opposite. It is recommended that you embrace the Triple Track Development as a unified team dynamic: a cohesive, multifunctional team striving towards a shared common team objective (Team OKR) via continuous discovery and continuous delivery practices.

Triple track, one team

Triple track, one team

The key distinction lies in the specific activities, tasks, and workshops undertaken by each team member within their respective areas. For instance, a Team OKR workshop can be conducted to define and align on the objectives of the business strategy track. Simultaneously, designers and UX specialists may engage in various UX research activities and prototype testing as part of the discovery track. Meanwhile, developers focus on delivering a new feature that holds the promise of achieving a desired outcome. This synchronized effort ensures that every team member’s contributions align seamlessly, propelling the team towards repeated success.

This unified team should function as a product team, rather than a delivery or a feature team. This distinction, as outlined by Marty Cagan in his books “Inspired” and “Empowered,” and the article “Product vs Feature Teams” is crucial. Unlike delivery teams, which focus solely on completing tasks, and feature teams, which concentrate on specific functionalities, a product team prioritises customer service while aligning with business objectives.

The Dual Track development model, which laid the groundwork for the triple track approach, was a collaborative effort between Jeff Patton and Marty Cagan. They conducted joint training sessions where the original dual track development concept was introduced. In Jeff Patton’s article ‘Dual Track Development is not Duel Track,’ he recalls, “Years ago, I was teaching a class with my friend Marty Cagan. It was really just my stuff and his stuff mashed together in a 3-day class. But, during my part, I put up a model that I normally show when talking about how Agile thinking and product thinking work together in the same process.”

‘All models are wrong, but some are useful.’ – George Box

However, Marty Cagan, in his insightful article ‘Process vs. Model,’ provides a nuanced perspective on the term ‘dual track.’ He articulates concerns about the potential misinterpretation of conceptual models as prescriptive processes, explicitly invoking George Box’s quote: ‘All models are wrong, but some are useful.’ In the ‘Process vs. Model’ article, Cagan emphasizes the flexibility of the dual track model, which can go by various names such as ‘build the right product / build the product right’ and ‘dual track agile.’ He explicitly calls out the risk of the model evolving into a complicated process flow chart if not approached with caution. Cagan’s concerns stem from a desire to maintain the simplicity and process agnosticism of the model.

‘There is no single product discovery process just as there is no single product development/delivery process.’ – Marty Cagan (from his article’Process vs. Model‘).

Furthermore, Cagan’s perspective is rooted in the belief that ‘there is no single product discovery process just as there is no single product development/delivery process.’ He asserts that various discovery processes exist for different situations, and it’s crucial to recognize that the focus should be on instilling the necessary culture and training teams in critical techniques rather than adhering to a rigid process.

In a recent communication, Cagan told me that ‘business strategy is already a key component of product discovery (at the center of viability risk).’ This statement aligns with his continuous advocacy for a holistic approach to product development that prioritizes collaborative problem-solving, business impact, and customer-centric solutions.

Whether it’s dual track, triple track, or any other name, the best product organisations foster this: one team with a shared common goal. Unified by diverse skills and continuous practices, the team consistently achieves success

Scrum and Team OKR: Orchestrating Success in Sprints

Every three months, the team gathers to set their primary goal for the upcoming period. They discuss and agree upon the Team OKR, ensuring it aligns with broader, more significant objectives, which might stretch over a year or even longer, aiming for ambitious achievements. This collaborative session, named the “Team OKR Definition workshop serves as a pivotal moment where team members converge to define their collective direction, fostering cohesion and strategic focus within the group.

Scrum and Team OKR Events

Scrum and Team OKR Events

The team operates in brief periods, lasting two weeks, known as Sprints. Each Sprint kicks off with a Sprint planning meeting, during which the team sets the goal and plans the tasks for the week. These tasks should be directly related to improving some KR. Every day, they hold a brief 15-minute meeting (Daily Scrum) to update each other on their progress, ask for help if required and ensure they are on course to achieve the Sprint goals.

Typically held at the end of each Sprint, the team comes together for a reflective session to acknowledge their accomplishments and identify areas for improvement. Known as the retrospective meeting, this gathering enables them to celebrate achievements and explore ways to enhance their processes, promoting a culture of continuous learning and improvement. For ideas on creating an effective retrospective agenda, you can visit FunRetrospectives.com.

At the conclusion of each Sprint, the team holds a Sprint review meeting. In this session, they evaluate the planned discovery and delivery work, as well as the Sprint goal. The last 15 minutes are dedicated to reviewing and updating the Team OKRs, aligning them with completed tasks and upcoming objectives. Here are some key points discussed during the Team OKR review:

  1. Adjust the OKR: If necessary, the team can pivot and modify the OKR to adapt to changing circumstances.
  2. Update the KR for the Team OKR: Based on achieved results, the Key Results (KR) for the Team OKR are updated to reflect the progress made.

The Team OKR cycle spans across six two-week Sprints, completing a three-month duration. At the end of each cycle, the team reunites for a Team OKR Definition Workshop, where new Team OKRs are crafted, marking the beginning of a new cycle.

Team OKR and Scrum quarterly cycle

Team OKR and Scrum quarterly cycle


Maintaining a Unified Work Backlog for Discovery and Delivery

It’s essential to maintain a single, unified backlog for both planned discovery and delivery tasks within a Sprint. While it might be tempting to segregate tasks by type (such as design-related tasks in one backlog and delivery-focused tasks in another), I strongly discourage this practice. Separating backlogs can create a disconnect among team members, making it challenging to stay informed about each other’s progress. In the fast-paced, highly collaborative environment involving team members from different tracks, synchronisation is crucial. By consolidating all tasks into one backlog (color-coding can help differentiate task types), you will enhance team awareness and foster better collaboration.

Although teams work with a unified backlog, the Design Ahead approach plays an important role in ensuring the seamless flow of work and efficient collaboration between discovery and delivery tracks. By doing user research, preparing prototypes, helping crafting user stories, and design outlines in advance, the Design Ahead methodology guarantees that delivery teams have precisely what they need for a successful and streamlined delivery process. This collaborative approach reduces delays, boosts productivity, and nurtures a harmonious environment where design and development efforts align seamlessly, culminating in the development of top-notch, user-centric products.


Triple track development and Lean Inception

Even within a unified product team, individuals from different tracks may occasionally need to synchronise their efforts with the delivery track’s next steps. To tackle this challenge, it’s vital to establish alignment on the product vision and desired outcomes. This can be achieved either through a designated person, often a product manager, who oversees all tracks to ensure coherence, or by organising a Lean Inception workshop that unites everyone for faster alignment.

In just a few sessions, the Lean Inception workshop unites everyone in the team – including business people, designers, and developers. Together, they engage in discussions, share insights, and collectively align not only what the product should accomplish but also the sequence in which they should develop and validate their solution. Throughout the workshop, they strategise the creation of the simplest version of the product to bring the maximum learning, known as the Minimum Viable Product (MVP). By validating the MVP (or product increment), they gain valuable insights to determine if the produced output achieve the desired outcomes or if adjustments are necessary.



Triple Track Development isn’t just a method; it’s a game-changer. By harmonising Business Strategy, Continuous Discovery, and Continuous Delivery, it empowers teams to excel. It’s more than a process; it’s a strategic advantage, propelling businesses into a future where adaptability and innovation define success.

Paulo Caroli

Paulo Caroli is the author of the best-selling book “Lean Inception: How to Align People and Build the Right Product” (the first on a series of books on business agility). He's also the creator of FunRetrospectives.com , a site and book about retrospectives, futurospectives and team building activities. Caroli writes on this blog frequently. Receive the next post in your email. Sign up here.
New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

New Book Alert: How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas

Introducing our enhanced book, “How to Define, Prioritize and Refine User Stories using the Product Backlog Building Canvas.” Evolving from its predecessor, this edition responds to valuable reader feedback, refining both content and title. Delve into the world of effective product development and user story management, discovering the integrated power of the PBB Canvas. Embrace an enriched reading experience and explore insights from thought leader Jeff Gothelf in the preface. Don’t miss a reader’s insightful review, preserved for wider readership. Join us on this journey of empowering user story craftsmanship, and witness the transformation of your product development goals.

read more
FunRetrospectives.com redesign

FunRetrospectives.com redesign

Amongst other things, I really like MVP and retrospectives. This probably explains FunRetrospectives.com over the years. FunRetrospectives.com is a simple dedicated blog for sharing proven retrospectives activities. The site gets lots of access. I believe it has to do...

read more

Pin It on Pinterest