Moving from project to product: The traits that help product-oriented businesses win

Ringing the Wall Street opening and closing bell. Blowing out an extra candle on a birthday cake. An annual pilgrimage to a much-loved vacation destination.

It’s not always necessary to discard traditions, whether personal or professional, just for the sake of something new. But when traditions become less about nostalgia or important symbolic gestures, and more about doing the same things in the same ways simply because that’s how it’s always been—well, that’s when you consider whether it’s time to make a change. 

Organizations, just like people, can place tradition on a pedestal. Sometimes that’s OK. But sometimes tradition can bog you down, keeping your business mired in the past and preventing it from being successful in the present—and in the future.  
 
One organization that understands this: Radio Flyer. The company still makes its classic toy red wagon, even after more than a century in business. But in the late ‘90s, when leadership recognized the legacy wagon model comprised just 25% of sales, the company began introducing more modern iterations to its product lineup, such as mini Tesla Model S replicas. The result? Radio Flyer generated $120 million in revenue in 2017, four times its 1997 sales revenues, which climbed to $200 million in 2021. 

Many other businesses know they need to modernize and digitize their strategies, technologies, product portfolios, and in-house skillsets. But if their organizational structures and conditions remain solidly stuck in the past—via set-in-stone hierarchies, functional silos that limit collaboration, and individualized incentive systems—they run into implementation challenges.  

Such “traditions” keep these organizations project-oriented—focused on completion—rather than product-oriented: focused on value. And project-oriented conditions and structure seriously limit an organization’s ability to deliver killer products and services to customers, at speed and at scale—as well as quickly adapt to meet new market needs and customer requests.  

That’s why product-oriented organizations don’t let their organizational conditions dictate their product strategy, design, development, and delivery. Instead, they build structures and processes that revolve around their key stakeholders. And they leverage digital strategies and tools to connect with customers and deliver major value—consistently, efficiently, and at scale. 

How? They: 

• Enable multidisciplinary collaboration; 
• Support cross-functional, Agile digital workflows; 
• Allow for continuous cycles of testing, learning, and iteration; 
• Create shared accountability; 
• Empower employees at all levels with data-driven insights to inform decision-making; and 
• Focus on outcomes rather than output.  

Agile workflows and test-and-learn processes spur continuous innovation 

In many cases, being fast—getting to market with an MVP that functions but isn’t fully built out—is better than being perfect. That’s why product-oriented organizations establish processes that support Agile workflows. These workflows break projects into smaller individual cycles, shortening development lifecycles—and allowing teams to quickly get an MVP into customers’ hands  

But these organizations also recognize that products are never really “done.” And while being fast is great, you also have to be right. That means you can’t rely solely on assumptions and historical and anecdotal data. You have to make customers active participants in the product development process.  

Guided by Agile practices and workflows, product-oriented teams thus work in continuous innovation cycles. They release an early version of a product or service into the market and then gather user data to understand: Do people like it? Are they using it, and if so, are they using it the way we assumed, or in new ways? Is anything creating friction within the user experience? Are some features going completely unused—and if so, why?  

Then, after learning what’s working and what’s not, the team iterates and releases the 2.0 version—then tests it again and iterates it again for as long as it makes sense.  

By working in ongoing cycles of testing, learning, and iteration, product teams learn where they can add value via new features and benefits. What’s more, they also uncover hidden opportunities to develop a totally new product that will meet customer needs.

A plus: Adopting these types of Agile workflows decentralizes product-specific decision making. Executives should be engaged when defining the desired business outcome and result, of course. But decisions about tactical ideas (the “how”) should remain within the domain of subject-matter experts—those designing, building, and delivering the solution.  

A caveat: Organizations will need to build a new governance model that realigns decision-making rights across the delivery system. That will ensure the right people are brought in at the right time, and can guide decisions that align with their specific area of expertise.  

Team structures are flexible, multidisciplinary, and built around common goals 

In the previous section, we refer to “product teams.” Now we’ll explain what we mean by that. 

There are two common misconceptions inherent to a project-oriented mindset: 

• Product teams consist only of “product people”—UX/UI designers and developers, software engineers, etc. 
• Only “product people” need to work in Agile workflows.    

Why are these ideas misguided? Consider what goes into ensuring any flavor of product—a physical object, an end-user service, a digital asset powering a customer experience—works well, meets the customer’s needs, and provides a seamless user experience. “Product people” play a major role, naturally, but delivering a successful product doesn’t begin and end with them. 

Say a mid-sized bank wants to build an AI-powered self-service portal that helps customers learn about the bank’s various products or perform simple tasks, such as transferring funds or reviewing monthly spending by category. Yes, the bank needs “product people” such as UX/UI experts (e.g., information architects and visual designers) to build the front-end interface. And it needs technologists (e.g., software engineers and AI experts) to build the back-end infrastructure and the AI models. But it also needs to bring in: 

• Data engineers, to build the master data management and governance processes that ensure data quality; 
• Cybersecurity experts, to keep users’ personal data secure; 
• Risk management and legal teams, to ensure regulatory compliance; 
• Marketing, sales, and customer success teams, to provide the right materials for the front-end customer experience and ensure people are directed to the right info; 
• Analytics and data-science experts to report on user trends and surface data-driven insights;  
• And so on.

Imagine all of these people working in linear, waterfall workflows—only tagging in the next functional team when it’s “their turn.” How long do you think it would take the bank to get an MVP into the market? Not soon. When product work is handed back and forth and carried forward by only one team at a time, like an Olympic torch, development lifecycles stretch out far longer than necessary.  

Plus, if organizational structures force this team to operate in functional silos—rather than enabling them to collaborate as a single multidisciplinary team, right from the start—the bank faces a slew of potential problems. Just two examples: 

• A lackluster or frustrating customer experience—because the people who have a deep understanding of customer personas and needs weren’t moving in lockstep with the people building the software and information architecture that drive the customer journey.  
• An early version without the proper KYC compliance conditions encoded into the back end’s custom rule sets—because risk-management, compliance, and data-science teams weren’t brought in until the product was half-built. That makes more work for the software engineers who have to recode the back end, further delaying the anticipated MVP release date.  

Enabling functions (financial, commercial, legal, cybersecurity, etc.), therefore, are embedded into the work from the very start. (They may not be “product people.” But they need to be part of a product team when their expertise is necessary to accomplish the ultimate goal: driving value for the end user.) 

Then, these multidisciplinary teams leverage Agile workflows, with multiple activities occurring simultaneously and moving in sync—which speeds up time to market. Critical data is shared automatically, communication flows organically, and people are able to collaborate across functions with ease—an attribute reported by 63% of high-performing, highly agile organizations, according to West Monroe’s Signature Research report, “Building a Digital Organization.”

As an added benefit, having flexible, decentralized teams boosts your overall organizational agility. If anything changes internally or externally—because of new customer needs, regulatory updates, M&A activity, etc.—product-oriented organizations can quickly restructure teams as needed and shift to a new strategy.  

The result? The business keeps moving forward, without missing a beat. 

Measurement processes support responsive, data-driven decision making 

Data about product performance and usability is obviously critical. But so is data that informs internal processes and guides business-critical decisions.   

Product-oriented organizations therefore establish and track key metrics (KPIs, OKRs, etc.) specific to product development lifecycles. Enabled by real-time, continuous data collection and data analytics, teams can measure progress with smaller, more frequent milestones—versus plodding toward a completion date on a years-long roadmap.  
 
This allows them to solve problems responsively: If they miss a milestone, they quickly see they’ve gone off course, and can take action. Compare that with a project-oriented organization—where teams often don’t realize how far off track they’ve fallen until they've reached the end of their scope or budget. 

What’s more, measurement processes give leadership more visibility, which can help remove funding roadblocks that prevent product teams from delivering value quickly and responsively. 

Budgets can end up dictating how good (or bad) a project-oriented organization’s offerings are. If the product team runs out of funding, but lacks the data to quantify expected value and make a case for more budget, they have to stop where they are. Customers therefore may end up with a half-baked or poorly functioning product or service (if it ever even sees the light of day), even if the concept itself was likely to be a winner. 

But if teams can produce data that proves the value of what they’re putting into the market—for example, by showing the C-suite a cohort of potential buyers that would increase the company’s market penetration—they’re more likely to have the appropriate level of funding allocated to their planned initiatives.  

Some product-oriented organizations even revisit their annual budget on a more frequent cadence, or set aside an “innovation fund,” so they can adapt in real time to new customer needs or evolving market conditions—as long as the data supports it. 

(This works both ways, of course. Using data to evaluate the value of new product/service may mean some initiatives don’t get funded—because, no matter how excited a team is about their idea, or how innovative it sounds, sometimes the juice really isn’t worth the squeeze.)   

Data-driven incentive structures create shared accountability and universal buy-in 

Traditional bonus structures reward individual performance in a vacuum, which disincentivizes the level of collaboration that is critical to successful product delivery—as well as for running a successful modern business. In fact, during a 2022 survey, Source Global Research found 80% of U.S. firms admitted achieving their corporate goals depends on collaboration between different parts of their organization 

That’s why product-oriented organizations create incentive structures that encourage—and then reward—cross-functional collaboration.  

Every role has performance goals—with clearly defined KPIs and trackable metrics—tied to one or more tenets of the business strategy and vision. These ladder up to their team’s KPIs, some of the metrics for which are related to market success—profit and loss, sales revenues, performance versus target, etc.—so team KPIs in turn ladder up to overall organizational goals.  

The results? 

• When teams know where the company wants to go, they can frame out a set of potential outcomes, and identify the best opportunities and KPIs for each—so they’re better positioned to then deliver the best possible outcome.  
• When people can see the role they play in business wins, it embeds accountability into their day jobs and helps individuals understand their place in the broader strategy.  
• And when everyone collectively shares in the incentives that result from the right outcomes, it boosts employee engagement and drives buy-in for the organization’s strategic goals. 

Deliver external value via internal evolution

Rearchitecting your organizational structure and processes isn't exactly a light lift. We haven’t even covered everything that goes into it here. But we believe it’s worth the time, effort, and resources.  

And, in fact, becoming product-oriented has benefits even beyond that lofty goal. It also helps organizations become more agile overall: They can react faster to internal and external changes while supporting continuous innovation. And organizational agility is what drives better business outcomes—positioning your organization for success and growth, now and in the future, in our ever-changing digital world.