1. Temporary Work Versus Persistent Responsibility

Projects have beginning and ending dates. Products continue as long as they serve an important need. A project team may exist for twelve months, release a new system, and disband. The product itself may remain in operation for ten years. Once the project ends, responsibility is frequently distributed across maintenance teams, infrastructure groups, vendors, support desks, security departments, and future project teams. The people who understood the original decisions disappear, but the consequences of those decisions remain. A product team is durable. Its members may change, but responsibility for the product remains clear.

The team retains knowledge of:

Users Business rules Technical architecture Past experiments Operational behavior Security risks Product economics Strategic priorities This continuity reduces the repeated cost of rebuilding context. It also makes faster adaptation possible. A durable team does not need to wait for a new project to be approved and staffed before responding to customer feedback or market changes. Thoughtworks’ product-mode model describes the ideal team as long-lived, cross-functional, aligned to a business capability, empowered to solve problems, and responsible for improving outcomes rather than simply delivering scope on schedule.

2. Predefined Scope Versus Evolving Problems

Projects usually begin with a requested solution. “Build a new portal.” “Replace the claims system.” “Add artificial intelligence to customer service.” “Create a mobile application.” These statements may sound strategic, but they are solution descriptions. They do not necessarily explain the underlying problem. A product team begins by examining the desired outcome.

For example:

Reduce claims-processing time from twelve days to four. Increase digital account-opening completion from 48 percent to 70 percent. Reduce customer-service contacts caused by billing confusion. Cut developer environment setup from five days to thirty minutes. Increase the percentage of first-time customer issues resolved without escalation. The team might eventually build a portal, modify a workflow, simplify a policy, automate a decision, improve communication, or remove a feature entirely. The solution remains flexible. The outcome provides direction.

3. Deliver-and-Leave Versus Build-Measure-Learn

In the project model, launch is often treated as completion. In the product model, launch creates evidence.

The team studies:

Who adopted the product Where users became confused Which features were ignored Whether the desired behavior changed What support problems emerged Whether operational costs improved What technical constraints appeared Whether the original hypothesis was correct This feedback shapes the next decision.

Product teams therefore operate through continuous cycles:

Identify an important problem. Form a hypothesis. Design the smallest meaningful intervention. Release it safely. Observe behavior and performance. Learn from the evidence. Improve, expand, replace, or stop the intervention. The objective is not endless development. The objective is continuous value management. Sometimes the correct product decision is to stop building.

4. Temporary Funding Versus Persistent Investment

Projects compete for approval through business cases. Once approved, the project receives a budget based on estimated scope, duration, and resources. This creates several problems. First, the business case may require unrealistic certainty. Leaders are asked to estimate the benefits and costs of a solution before sufficient discovery has occurred. Second, once the project receives approval, teams become motivated to protect the approved scope rather than revisit whether the assumptions remain valid. Third, funding stops at project completion, even though the digital capability requires operation, security, improvement, and adaptation. Product funding works differently.

Leadership allocates capacity to enduring products or value streams based on:

Strategic importance Customer impact Economic performance Risk Market opportunity Product maturity Regulatory necessity Evidence of progress The team receives relatively stable capacity but not an unconditional promise of permanent funding. Investment should increase when evidence demonstrates strong value. It should be reduced when opportunities decline, performance remains weak, or the product no longer supports strategy. This allows the organization to manage technology as a portfolio of investments rather than as a queue of disconnected projects.

5. Handoffs Versus End-to-End Ownership

Traditional technology delivery frequently divides responsibility across specialized groups:

Business analysis Architecture User-experience design Development Testing Security Infrastructure Release management Operations Support Specialization itself is not the problem. The problem is that work must repeatedly move between departments with different priorities, managers, queues, and performance measures.

Every handoff creates:

Delay Lost context Additional documentation Coordination effort Ambiguous accountability Rework Risk of misunderstanding Product teams reduce unnecessary handoffs by placing the required capabilities within, or directly around, a durable team.

The exact composition varies, but a product team may include:

Product management Engineering Design Data Quality engineering Operations Security Business-domain expertise Marketing Legal or compliance support McKinsey reports that one consumer-products company reduced various coordinating roles that were generating excessive handoffs during its transition to a product model. The change increased team capacity and reportedly produced substantial recurring savings. The lesson is not that every project manager, analyst, or quality professional should be eliminated. It is that an organization should not require a large coordination bureaucracy merely to move work through its own structure.

6. Output Metrics Versus Outcome Metrics

Project dashboards commonly report:

Percentage complete Requirements delivered Budget consumed Milestones achieved Story points completed Team utilization Features released These indicators may help manage execution. They do not prove that the work matters. A product dashboard should connect four layers of performance. Customer or User Outcomes Conversion Adoption

Retention Satisfaction Task completion Time saved Error reduction Business Outcomes Revenue Margin Cost to serve Customer lifetime value Risk reduction Working-capital improvement

Market share Product Health Active usage Feature adoption Abandonment Support demand Reliability Accessibility Product-market fit indicators Delivery and Engineering Health Lead time Deployment frequency

Change-failure rate Recovery time Defect escape rate Technical debt Developer experience A product team needs all four. Business outcomes without product and engineering indicators can hide a fragile system. Engineering indicators without customer and financial outcomes can create highly efficient teams that build the wrong things.

7. IT Alignment Versus Business-and-Technology Integration

Traditional organizations often speak about aligning IT with the business. The phrase itself reveals separation. The business develops strategy. IT receives requirements. A genuine product model integrates business and technology leadership around shared outcomes. Technology is no longer merely the delivery mechanism for someone else’s strategy. It helps shape the strategy because software, data, platforms, automation, and artificial intelligence increasingly determine what the business can offer, how quickly it can respond, and which economics are possible. McKinsey’s product-and-platform model brings business, technology, operations, and other relevant functions together within teams focused on customer experiences and reusable services. Its research also associates greater operating-model maturity with stronger operating margins and shareholder returns, although correlation should not automatically be interpreted as proof that the operating model alone caused those results. The strategic implication is clear: technology should not be treated as a supplier waiting for instructions from the “real business.” Technology is part of the business.

What a Product Team Actually Owns A product team should own more than a backlog. A backlog is simply a list of possible work. Ownership requires responsibility for the product’s performance and consequences. A mature team usually owns the following areas. Product Purpose Why does this product exist? What customer, employee, or business problem does it address? Defined Users Who receives the value? What are their needs, behaviors, constraints, and alternatives? Outcomes Which measurable changes should the product create?

Discovery How will the team understand problems, test assumptions, and identify viable solutions? Delivery How will the team design, build, test, and release improvements? Operation How will the product remain reliable, secure, compliant, observable, and supportable? Economics What does the product cost to build and operate? What revenue, savings, productivity, or strategic value does it generate? Lifecycle Should the product be incubated, expanded, maintained, repositioned, consolidated, replaced, or retired? Without this lifecycle responsibility, product management becomes little more than backlog administration.

The Product Manager Is Not a Renamed Project Manager One of the most common transformation mistakes is changing titles while preserving the old system. Project managers become product managers. Project plans become product roadmaps. Requirements become user stories. Steering committees become product councils. Annual projects become annual product initiatives. Nothing fundamental changes. A project manager is traditionally responsible for coordinating execution within agreed scope, schedule, budget, and dependencies. A product manager is responsible for maximizing the value created by the product.

That requires different work:

Understanding users and markets Defining product strategy Prioritizing problems Connecting product outcomes with business strategy Evaluating evidence Managing product economics Making tradeoffs Communicating direction Working closely with engineering and design Deciding what not to build The product manager should not dictate every solution.

The strongest teams combine three complementary forms of leadership:

Product leadership: Is the solution valuable and strategically relevant? Design leadership: Is it understandable, accessible, and desirable? Engineering leadership: Is it feasible, secure, scalable, reliable, and maintainable? Business-domain, data, operational, legal, risk, or marketing leadership may also be essential depending on the product.

Product Boundaries: The Most Difficult Design Decision An organization cannot establish effective product teams until it determines what its products are. This is more difficult than creating an application inventory. Applications are technical assets. Products are units of value and accountability. One product may depend on many applications. One application may support several products. A customer journey may pass through dozens of systems and organizational departments. Poorly defined boundaries create two opposite problems. Boundaries That Are Too Narrow Every small application, feature, or service becomes a separate product. This creates too many teams, excessive dependencies, fragmented ownership, and administrative overhead. For example, a retailer probably should not establish completely independent product teams for every checkout button, promotional code, payment screen, and receipt function.

Boundaries That Are Too Broad One team owns an enormous domain such as “customer experience,” “sales,” or “data.” The scope becomes too large for meaningful accountability. Outcomes are difficult to assign, priorities conflict, and teams cannot operate independently.

Useful product boundaries often follow:

Customer journeys Employee journeys Business capabilities Value streams Customer segments Platform capabilities Distinct economic models Persistent problem domains

A retail organization might define products around:

Product discovery Cart and checkout Payments Fulfillment Returns Loyalty Customer identity

A bank might organize around:

Customer onboarding Deposits Lending Payments Financial advice Fraud prevention Regulatory reporting The correct boundary should be large enough to produce meaningful value but focused enough that a durable team can understand and improve it. Deloitte recommends beginning with value streams that connect defined customer segments and journeys to the points at which the enterprise creates value. Organizing around these end-to-end flows can also encourage clearer ownership and more reusable architecture.

Product Teams Need Platform Teams A product organization cannot scale efficiently if every customer-facing team must independently solve infrastructure, security, deployment, data, identity, and integration problems. This is where internal platforms become essential. A platform provides reusable capabilities through clear, self-service interfaces.

Examples include:

Cloud environments Continuous delivery Identity Payments Messaging Customer data Observability Security controls Machine-learning infrastructure API management Experimentation Feature flags

Design systems A good platform reduces the cognitive and operational burden carried by product teams. Instead of submitting a ticket and waiting two weeks for an environment, a team may provision one safely within minutes. Instead of designing authentication independently, it consumes a standardized identity service. Instead of manually producing compliance evidence, controls are embedded within the delivery platform. Platform teams should not behave like internal monopolies that impose technology on captive users. They should operate as product teams.

They need:

Defined users Product research Adoption metrics Service-level objectives Documentation Support Roadmaps Feedback mechanisms Measures of developer productivity and satisfaction The value of a platform is not the number of services it creates. Its value is the improvement it enables across the teams that use it.

Why Product Transformations Fail Many organizations announce a product transformation and discover two years later that they have created new titles, ceremonies, and reporting structures without achieving better outcomes. Several failure patterns appear repeatedly. Renaming Projects as Products A fixed package of scope still receives temporary funding and must be delivered by a specified date. It is called a product, but it operates exactly like a project. Keeping Annual Project Funding Teams must repeatedly create business cases to preserve their existence. This undermines stability and encourages exaggerated promises. Creating Product Owners Without Product Authority The product owner maintains the backlog but cannot make meaningful decisions about strategy, funding, staffing, architecture, risk, or release. Preserving Functional Silos Engineering, design, data, operations, and security still report into separate queues. The product team exists mainly as a coordination layer over the unchanged structure.

Measuring Delivery Instead of Value Leaders continue demanding features, milestones, utilization, and delivery dates while telling teams to become outcome-oriented. People respond to the measures that affect funding and careers. Ignoring Engineering Modernization Teams are called autonomous but cannot release without months of manual testing, approvals, environment provisioning, and integration coordination. Product autonomy requires technical capability. Treating Every System as a Strategic Product Not every legacy application needs a fully empowered innovation team. Some systems should be maintained efficiently, replaced, consolidated, purchased as commercial software, or retired. Eliminating All Project Discipline The opposite mistake is assuming that product thinking removes the need for planning, risk management, dependency coordination, or deadlines. It does not.

Product organizations still manage:

Regulatory deadlines Mergers Data-center exits Market launches Major migrations Contractual commitments Cross-product initiatives Product thinking changes the permanent operating structure. It does not abolish temporary coordination.

When Projects Still Make Sense The argument for products over projects should not become an ideology.

Projects remain appropriate when the effort is:

Truly temporary Highly predictable Constrained by a fixed deadline Based on stable requirements Primarily administrative or physical A one-time migration or closure Controlled by an external mandate Unlikely to require continuing product discovery

Examples might include:

Closing a data center by a contractual date Moving an office Completing a defined regulatory remediation Integrating systems after an acquisition Replacing standardized hardware Implementing a commercial package with limited customization Retiring a legacy product Even then, the project should normally deliver its result into a durable product, platform, or operational owner.

The principle is:

Use projects to coordinate temporary change. Use products to own enduring value. Thoughtworks also acknowledges that project thinking can remain effective where requirements are known and stable, a capability is being frozen or retired, or the organization has little influence over a third-party product.

A Practical Roadmap for Moving from Projects to Products The transformation should not begin by redrawing the entire organization. It should begin by proving that a different system of work produces better results. Phase 1: Diagnose the Existing Model Map how technology work currently moves from idea to outcome.

Examine:

How priorities are selected How funding is approved How teams are staffed How many handoffs occur How long approvals take How frequently software is released How success is measured Who owns performance after launch Where customer feedback enters the process Which delays come from organizational structure The goal is not to blame departments. It is to expose the system. Phase 2: Identify Strategic Value Streams

Select a limited number of persistent areas where better technology performance could produce significant business value.

Good candidates have:

Clear users Important outcomes Executive sponsorship Meaningful digital interaction Sufficient demand for continuous improvement Measurable performance A manageable scope

Possible examples include:

Digital customer onboarding E-commerce checkout Claims processing Employee onboarding Developer productivity Customer identity Pricing Fulfillment Phase 3: Define Product Boundaries

For each value stream, determine:

The users The problem domain The value created The systems involved The dependencies The lifecycle stage The outcomes The appropriate team boundary Avoid simply converting the application inventory into a product catalog. Phase 4: Establish Durable Cross-Functional Teams Assign the minimum capabilities required for meaningful end-to-end ownership. Create clear decision rights.

The team should understand:

What it owns What it may decide Which outcomes it must improve Which policies constrain it Which platforms it can consume How performance will be reviewed Phase 5: Replace Feature Roadmaps with Outcome Roadmaps A feature roadmap promises solutions.

An outcome roadmap communicates:

The problems the team will address The users affected The desired measurable changes The hypotheses being tested The strategic sequence The evidence required for further investment Features may appear as possibilities, not irreversible commitments made before discovery. Phase 6: Introduce Persistent Funding Fund the team or value stream for a defined investment period.

Review funding based on:

Strategic alignment Evidence of value Product health Learning velocity Opportunity size Risk Cost Alternative uses of capital Stable funding should not mean permanent entitlement. It should mean that teams do not need to reconstruct themselves for every improvement. Phase 7: Modernize Engineering and Operations Product teams require the ability to release and learn safely.

Invest in:

Automated testing Continuous integration Continuous delivery Observability Security automation Infrastructure automation Self-service environments Modular architecture API standards Data quality Feature experimentation Incident learning

McKinsey reports that more mature product-and-platform models can be associated with shorter time to market and lower defect rates, but those benefits depend partly on accompanying changes in engineering practices, governance, platform design, and business partnership. Phase 8: Redesign Governance

Traditional governance asks:

Is the project on schedule? Is it within budget? Has the agreed scope been completed?

Product governance should ask:

Are we addressing a strategically important problem? What evidence shows improvement? What did we learn? What risks have changed? Is investment still justified? Should we accelerate, maintain, pivot, or stop? Are teams constrained by dependencies or policies? Are platforms improving enterprise-wide performance? Governance should establish boundaries and accountability without prescribing every implementation detail. Phase 9: Build a Balanced Measurement System Each product should maintain a small, meaningful scorecard.

For example:

Customer outcome: Account-opening completion rate Business outcome: Cost per successfully opened account Product health: Monthly active users and abandonment points Operational health: Availability and incident rate Delivery health: Lead time and deployment frequency Risk: Fraud loss and compliance exceptions Avoid producing fifty metrics that no one uses. A metric should support a decision. Phase 10: Scale Through Evidence

After six to twelve months, evaluate whether the pilot products have improved:

Customer outcomes Time to market Product quality Employee engagement Operational performance Business results Learning speed Decision clarity Use the evidence to refine the operating model before expanding it. Thoughtworks recommends beginning with a small group of strategically important products, defining their boundaries, forming cross-functional teams, and gradually extending the model rather than attempting an immediate enterprise-wide conversion.

How Leadership Must Change The product model asks executives to give up a comforting illusion: that detailed plans create certainty. Leaders still establish strategy, risk tolerance, investment boundaries, and accountability. They stop pretending that every valuable digital solution can be fully specified in advance. Their role changes from approving large packages of predicted work to managing a portfolio of evidence-based investments.

Leaders must become skilled at:

Defining outcomes Allocating capital Evaluating evidence Removing systemic constraints Creating clear decision rights Developing product and engineering talent Balancing autonomy with enterprise standards Stopping low-value work Protecting long-term capability from short-term pressure They must also tolerate responsible learning. If every unsuccessful experiment is treated as failure, teams will avoid experimentation and deliver only what leadership has already approved.

Responsible experimentation is not uncontrolled spending. It requires:

A clear hypothesis A limited investment Defined success and failure signals Safe implementation Rapid measurement A decision based on the evidence

What Success Looks Like A successful product organization is not defined by how many product managers it employs. It is visible through behavior. Teams can explain which users they serve and which outcomes they own. Product priorities are connected to business strategy. Funding follows enduring value streams rather than temporary lists of features. Teams remain together long enough to build domain knowledge. Customer research and operational data affect decisions. Business, technology, design, operations, and risk work toward shared outcomes. Platforms reduce duplication and make safe delivery easier. Leaders can stop weak investments without dismantling the entire organization. Products have lifecycle strategies, including retirement.

Engineering quality is treated as an economic capability, not merely a technical concern. Product teams release, learn, and adapt without repeatedly waiting for new project approval. Deloitte emphasizes that sustainable product transformation depends on the wider operating system, including value streams, outcome setting, shared services, performance measures, transformation leadership, integrated tooling, and modern engineering. Merely creating product teams is insufficient.

Key Takeaways

Technology products are enduring value-creating capabilities, not merely applications sold to customers. Projects optimize temporary delivery. Products optimize continuous outcomes. Completing scope on time and within budget does not prove that customer or business value was created. Durable teams preserve domain knowledge and respond faster than teams repeatedly assembled around temporary projects. Product teams should own discovery, delivery, operation, measurement, and lifecycle decisions. Product funding should provide persistent capacity while remaining accountable to performance and strategic value. Outcome metrics must complement delivery and engineering metrics. Product boundaries should follow meaningful user journeys, business capabilities, value streams, or platforms rather than the application inventory alone. Internal platforms are products whose customers are other teams. Renaming projects, roles, and committees does not create a product operating model. Technical modernization is necessary because teams cannot be autonomous when releases depend on slow manual processes and centralized queues. Projects remain useful for temporary, stable, deadline-driven work. They should not be used as the permanent ownership model for evolving digital capabilities.

The transition should begin with a limited portfolio of strategically important products, not an immediate enterprise-wide reorganization. The product model is a business transformation, not an IT initiative. The ultimate goal is not to produce more software. It is to create more value with better software, better decisions, and less organizational friction.

Frequently Asked Questions

Is a product operating model the same as Agile?

No. Agile practices may help teams work iteratively, but many Agile teams still operate inside project funding, fixed scope, temporary staffing, functional silos, and output-based governance.

A product operating model addresses the larger system:

Strategy Funding Team design Product boundaries Governance Measurement Engineering Operations Talent Leadership Agile may support the model, but it does not automatically create it.

Does every application become a product?

No. An application is a technical asset. A product is a unit of value and accountability. One product may use several applications, and one application may support multiple products. Some applications should simply be maintained, purchased, consolidated, or retired.

Do projects disappear completely?

No. Projects remain useful for one-time, predictable, deadline-driven changes. The critical distinction is that enduring capabilities should normally have enduring owners.

What happens to project managers?

The answer depends on the person’s capabilities and the organization’s needs.

Some project managers may become:

Program leaders Delivery managers Product operations specialists Portfolio managers Transformation leaders Product managers Agile coaches Risk and dependency managers A title change alone is not sufficient. Product management requires customer, strategic, commercial, analytical, and discovery capabilities that may differ from traditional project management.

How are product teams funded?

Organizations commonly allocate persistent funding to products, platforms, or value streams for a defined planning period. Investment is reviewed according to strategy, evidence, performance, risk, and opportunity rather than approved solely against a fixed list of features.

How long should a product team remain together?

As long as the product or problem domain remains strategically important. Individual members may rotate, but the team’s ownership and accumulated knowledge should remain durable.

What is the ideal size of a product team?

There is no universal number. The team should be small enough to communicate effectively and large enough to own a meaningful outcome. Larger domains may require several teams organized as a product group or value-stream structure.

Who owns the product?

Ownership is shared but not ambiguous. Product leadership typically owns value, priorities, and product direction. Engineering leadership owns technical integrity and delivery capability. Design leadership owns the quality and coherence of the user experience. Business, operations, data, security, legal, risk, and other functions participate according to the product’s needs.

How should product teams be measured?

Use a balanced scorecard covering:

Customer or employee outcomes Business outcomes Product health Operational performance Engineering and delivery health Risk and compliance Avoid evaluating teams primarily by feature counts, story points, or utilization.

What is a platform team?

A platform team provides reusable technical capabilities that other teams consume. Its product may include cloud infrastructure, identity, data, deployment pipelines, payments, security controls, or developer tools. The platform should reduce friction and improve the speed, quality, safety, or economics of product delivery.

Can vendors participate in product teams?

Yes. The relationship must support durable ownership and knowledge retention. A company should avoid outsourcing accountability for a strategic product entirely. Critical product, domain, architecture, and decision-making capabilities should generally remain inside the enterprise.

How quickly can an organization make the transition?

A pilot can begin relatively quickly, but enterprise transformation usually occurs over several years. Funding cycles, architecture, leadership behavior, career structures, vendor contracts, governance, and organizational incentives do not change through a single reorganization.

What should an organization transform first?

Begin with products or value streams that are strategically important, measurable, and constrained by the current project model. Choose areas where improved speed, ownership, customer understanding, or engineering capability can produce visible value.

Conclusion

The project model helped organizations control technology investments when software was slower, more isolated, and less central to competitive strategy. That environment has changed. Today, digital products shape how customers discover companies, purchase services, receive support, manage accounts, interact with employees, and experience brands. Internal platforms determine how quickly teams can innovate. Data and artificial intelligence influence decisions across the enterprise. Security and reliability affect revenue, trust, and reputation. These capabilities cannot be responsibly managed as temporary assignments that end at deployment. A project asks whether the organization delivered what it promised. A product asks whether the organization improved something that matters. That shift sounds simple, but its consequences are substantial. It changes what receives funding. It changes how teams are formed. It changes what leaders measure. It changes who makes decisions. It changes how business and technology work together.

It changes whether software is treated as a completed asset or as a continuously evolving source of value. The goal is not to remove planning, accountability, budgets, deadlines, or discipline. The goal is to apply those disciplines to the right objective. Companies should not measure success by how efficiently they complete technology work that customers do not value, employees do not adopt, and the business does not need. They should build durable capabilities for understanding problems, testing solutions, operating reliable products, learning from evidence, and continually directing investment toward the greatest opportunities. That is the real meaning of shifting IT from projects to products. It is not a change in vocabulary. It is a change in how the enterprise creates value.

Relevant Articles and Resources

1. Thoughtworks: “Shift IT from Projects to Products: Part 1, What Is a Product?”

The original source concept explains the distinction between project and product thinking, defines digital products, discusses different product forms, and recommends beginning the transition with a limited portfolio of strategically important products.

2. Thoughtworks and Martin Fowler: “Products Over Projects”

A detailed explanation of durable, cross-functional, outcome-oriented teams and why organizations should align teams with persistent business capabilities rather than temporary delivery assignments.

3. Martin Fowler: “Outcome Over Output”

A useful explanation of why software teams should evaluate the customer and business effects of their work instead of relying primarily on feature counts and other production measures.

4. McKinsey: “The Big Product and Platform Shift”

Research and recommendations covering product boundaries, platform design, business partnership, governance, and software-engineering practices required for product-and-platform transformation.

5. McKinsey: “The Bottom-Line Benefit of the Product Operating Model”

An examination of product-and-platform operating-model maturity and its relationship with business performance, team structure, governance, talent, and tooling.

6. McKinsey: “What Makes Product Teams Effective?”

Research focused on product-team effectiveness, role clarity, automation, reduced handoffs, engagement, and organizing teams around measurable value.

7. Deloitte: “From Project to Product: The Next Frontier of Value Creation”

A product-operating-model framework covering value streams, objectives and key results, shared services, performance indicators, transformation leadership, integrated tooling, and modern engineering.