It’s a story as old as business itself. As companies grow, complexity and inefficiency infect the organization, slow things down, and undermine the value created. The same is true of innovations, such as agile ways of working, that are designed to combat the creep. They, too, can grow bloated and lose focus. Productivity suffers, and businesses are slow to adopt the latest technologies, such as generative AI (or they may implement GenAI but fail to reap value from its potential).

The problem often shows up first in product engineering, where tasks are already complex and speed is a paramount strength. Discontinuities between developer productivity and the delivery of business value gain a foothold, then widen. Agile partly addressed this problem by producing a sea change in productivity for many IT and engineering departments. But its primary focus has always been building the product the right way, rather than building the right product—the ultimate source of value. Companies today need to maintain their focus on business outcomes throughout the development process.

Enter outcome-based teaming, or OBT, an approach designed expressly to combat the root causes of slowdowns resulting from the misalignment between technology and business needs. OBT pushes business-driven development by delivering a step-change improvement in aligning team dynamics with clear, measurable outcomes. It enhances productivity and innovation.

Over the last three years, we have helped more than 200 teams implement OBT—with impressive results. For example, one Fortune 250 software-as-a-service company used OBT to implement a new tech platform for an existing product line, achieving a 50% reduction in implementation time, a 30% reduction in service requests, and a 20% improvement in customer satisfaction.

Here's how OBT works.

Pods, SMEs, and Outcome-Based Principles

OBT embeds business subject matter experts (SMEs) into agile pods—small, freestanding teams of software engineers with a full set of complementary skills that cover the entire software development life cycle. SMEs are often frontline associates who provide direct signals from the rockface and thereby facilitate accurate identification and prioritization of client needs throughout the development cycle, which minimizes downstream adjustments and rework. SMEs’ engagement, from developing product features (and the associated use cases) to testing minimum viable products with clients to participating in product releases, provides critical expertise and feedback that maintains the focus on outcomes. If they see a need, SMEs can add specific action items (such as preparing a training plan or establishing a new customer care process) to a team’s backlog.

OBT requires that teams work according to seven principles that collectively prevent the causes of slowdowns from taking root. (See “The Root Causes of Problems in Software Product Development” and Exhibit 1.) Effective change management is critical to embedding these principles in day-to-day work. Business, product, and engineering leadership is actively involved in oversight, but teams are autonomous and responsible for enforcement.

Engage the business. OBT emphasizes assimilating pivotal business functions, including sales, service, and support, directly into agile pods. SMEs are not distant middle managers but individuals who are close to clients and understand business realities. Their real-time feedback to developers during sprints ensures that development teams understand client needs and pain points and that products accurately meet priorities. The result is fewer and less substantial adjustments in the downstream development stages, ultimately leading to higher productivity and less rework.

Focus on outcomes. OBT anchors teams in a clear mission and aligns them on value-creating outcomes by involving SMEs with design, product, and engineering talent in the early discovery and prioritization process. Ready access to business and product leaders during product development ensures upfront and continuing alignment as well as clarity on the team's mandate and deliverables. The team can readily pivot and revise its backlog to include new features that help achieve the target outcome.

OBT also emphasizes frequent reviews of progress and adjustments. Many companies default to quarterly assessments and planning cycles, which means that up to 12 product development sprints can take place between reviews. OBT relies on weekly sessions where all participants come together to assess progress. Teams present product demos, resolve tradeoff decisions, and ensure alignment with business goals. Frequent interaction builds confidence in the product's direction, raises trouble signals early, and enables resolution of any blockages.

Measure outcomes. Since software products are inherently complex, specificity matters. OBT underscores well-defined objectives and key results, as well as key progress indicators at the level of individual product features. These metrics are established in advance and establish a tight connection with business strategy and objectives (such as growth and margin expansion). They form the basis for a rigorous tracking mechanism.

Embed cross-functional representation. OBT prioritizes the formation of fully autonomous teams. The inclusion of business and cross-functional technical resources (such as UI/UX, cloud, and platform team members) establishes the basis for team autonomy and minimizes handoffs. Teams become end-to-end units that can tackle the entirety of a problem, cutting across traditional silos or boundaries and fostering a unified focus on outcomes.

Set the stage for stability and consistency. Team stability is a key feature of OBT. Staffing teams with the same members for extended periods (typically at least two to three quarters) creates a continuing knowledge base, which accelerates productivity and reduces inefficiencies resulting from gaps in knowledge transmission.

Aligning incentives with team outcomes breaks down divisions among team members from different functions. OBT promotes a culture of accountability and collaboration in which all members focus on results without concern for penalties or pushback. This kind of open feedback loop is crucial for addressing issues promptly and effectively. The collaborative environment helps product and engineering team members feel that business members are aligned and supportive, bridging the gap between business needs and technical execution.

Overcome geographic challenges. Geography and time zones inhibit collaboration for any global organization. Remote working and flexible hours add another level of difficulty. OBT emphasizes structuring team membership and working schedules to take these impediments into account. As a result, all team members can contribute while experiencing a roughly equal degree of inconvenience.

Crystalize ownership and accountability. OBT champions transparent accountability. Product owners (who can come from the business or the tech side) are responsible for establishing an outcome-focused culture, and engineering managers are responsible for on-time delivery.

OBT in Practice

Take the case of an HR-focused software-as-a-service company that was looking to further enhance the client and employee experience by improving the processing-error rate of its zero-touch system and thereby alleviate frictions and manual effort.

The company assembled a cross-functional team with the goal of improving data accuracy, completeness, and timeliness. The team encompassed business, product, and engineering roles located around the world. (See Exhibit 2.) In addition to members with critical technical expertise, business SMEs addressed specific data challenges. For instance, implementation SMEs focused on improving data consistency during client setup. Their expertise ensured that the team prioritized automating the setup process to enhance accuracy and avoid downstream effects. Similarly, a customer service SME brought firsthand knowledge of the pain points that customers were complaining about. These insights led the team to establish a new role within customer care and a new triage process, and to focus on features that directly enhanced data accuracy and customer satisfaction. An integration SME helped streamline input from third parties so that data flows between internal and external systems could be adjusted to work seamlessly, improving consistency and integration.

Data engineers on the scrum team eliminated inefficiencies associated with handoffs between teams. They were responsible for designing, implementing, and maintaining the data infrastructure, ensuring that pipelines were efficient and could handle real-time data processing. They also implemented automated checks and validations within the data pipelines, reducing the manual effort.

Without this type of unified team, the engineering manager and product manager would have had to orchestrate a massive coordination effort among five business organizations and multiple scrum teams. Delays and misalignment, often manifesting in bad code or downstream defects, would have been inevitable.

At the operating level, the global team established its own coordinated work schedule. Team members from the US started their day earlier, while those in India ended the day slightly later, ensuring overlap from 7:00 a.m. EST to 11:00 a.m. EST. This period allowed for real-time collaboration, daily standups, and problem-solving sessions. Despite geographic dispersion, the team operated as a cohesive unit.

The team set out specific, measurable goals to track progress. One goal was to improve data entry accuracy by 50% within three months. Another was to reduce the volume of customer support calls stemming from data inconsistencies by 80% within six months. Progress was monitored through KPIs such as accuracy rates, processing times, and user feedback scores.

Every Friday, the team met with the vice presidents of service, implementation, partner integration, product, and engineering to share demos, align on critical decisions, and review progress. This forum was used to resolve major issues. For example, with increasing customer complaints about data inaccuracies, the team weighed the long-term benefits of enhanced data reliability against the immediate business impact. Certain enhancements could mean a significant change in the architecture, potentially delaying the project's completion and causing short-term business losses. With ready access to leadership, there was little room for surprises.

OBT Beyond Software

OBT is similar to agile in its versatility and applicability. Just as agile methodologies revolutionized software development by promoting flexibility, collaboration, and rapid iterative progress, OBT extends these principles to tackle a broader spectrum of business challenges. Its structured yet adaptive approach makes it a powerful tool for addressing complex problems that require extensive cross-functional teamwork. (See Exhibit 3.)

In practice, OBT breaks down complex problems into manageable components and creates end- to-end teams dedicated to solving these problems. It minimizes handovers to other teams by ensuring that the original team gets the job done. This approach often requires a cultural shift, especially in large organizations where handovers and siloed work are common. Changing the culture involves encouraging team members to forget about traditional lines and boxes and to come together by focusing on delivering the business outcome. This can lead to more effective problem solving, faster implementation, and improved customer satisfaction.

Getting Started

The best way to make the transition to the OBT model is through a structured three-step approach. The initial phase recognizes the significant change management required. Substantial time is invested during this phase to identify a high-impact business priority and assign one or two OBT teams to prove the model works, manage the change, and develop the change agents who can enable the subsequent steps. To encourage buy-in, team members are urged to become advocates for OBT in the broader organization. (They are often surprised that they ever worked in such inefficient ways.) Typically, this phase spans 8 to 12 weeks.

The second phase involves stabilizing the initial teams and bringing additional teams onboard. As teams become more acquainted with OBT, the approach expands into new areas, providing a scalable blueprint that serves as a guide for future teams. The blueprint follows the seven principles described above and looks to structure work in a way that reduces handoffs and embeds team autonomy. It also follows a scaling model that transforms scrum teams to OBT teams according to rising demand from the business. Depending on the organization's size and adaptability, this phase typically lasts 8 to 16 weeks.

The third phase sees OBT scale up. The ultimate goal is to onboard every team in the organization to the OBT model, using the blueprint honed in the previous phase. Most companies establish regular forums to facilitate effective program management and ensure that as teams scale, the essence of OBT remains intact. This phase lasts between 12 and 16 weeks.