How Product-led Software Companies can Move from Idea to Delivery

The topic of product-led growth in the high-tech and software space is expansive. We published a point of view in January on how to keep up with this rapid change, and we received a number of responses around one common question: How do product-led companies work from idea to delivery in the most efficient and collaborative way? 

It’s a great question—with multiple angles within its answer. We believe the ability of an organization to drive new value to market is directly related to their future trajectory. Leading digital product organizations optimize ways of working so that they can move from an identified opportunity to product delivery in the least possible time. This makes it possible to respond to changing macro conditions and consumer expectations faster than competitors, allowing them to maintain or strengthen their lead in the market. Digital leaders spend considerable effort to address the issues that slow down this opportunity-to-delivery value chain.  

Many maturing organizations optimize speed to deliver anything over speed to deliver the right thing. Instead, organizations should strive to improve speed to deliver the product with the most value.

This, however, is no easy feat. Opportunity-to-delivery can represent a wide variety of activities and people involved. But our experience has revealed a handful of critical components in driving the right approach: mapping and measuring, properly assessing risk, and constant discovery and delivery. This is how each approach can lead to delivering that value. 

Mapping and measuring: Find the right course and stay with it 

Legacy organizations often conclude that their opportunity-to-delivery challenges are a result of not having enough engineering velocity in their product teams. If you’ve optimized your ways of working to increase only development velocity, it’s likely that you’re delivering features to your users that aren’t utilized, aren’t driving preference, and/or aren’t driving the right outcomes back to the business. The result is most often adding engineering velocity that delivers the wrong product faster. 

The better approach is to map out the steps your organization goes through in the product value chain: from the moment an opportunity to add value is identified to the moment that it’s released to users. Then, measure the time it takes to complete the journey and how long each opportunity spends in each step on that chain. Don’t worry about how your total time compares to others—focus on areas to reduce time within each step of that process. 

A large healthcare organization we worked with cited their product team as the single biggest factor in their struggles to deliver products and asked us how to increase development velocity. Once we mapped and measured their product value chain, we learned that the organization was often spending 6 to 12 months scoping, shaping, estimating and funding project teams to do that work before a team was even assigned. 

In addition, completed features often sat in a testing environment for months while waiting for quarterly or semi-yearly product release windows. In an 18-month total opportunity-to-delivery timeline, the product team accounted for 1 to 2 months of the process. The return on improvement investment was clearly weighted toward optimizing the process rather than the team delivering work itself.  

Conducting a clear and honest assessment of where the time is really being spent will help ensure that changes are being made to the areas of biggest impact to the primary objective: delivering value to the market. 

Properly assessing risk: Avoiding inefficiencies and delays 

Almost every opportunity identified to deliver value in a product is actually a hypothesis. There are few certainties in software delivery. Every feature, or hypothesis, has inherent risks that it won’t work the way we believe, and most maturing organizations don’t have an effective way to understand and address those risks.

One of the challenges we often see with product teams is that they don’t share the risks associated with a specific feature or function across the organization. These risks come in several forms: 

• Feasibility: Can it be done? 
• Usability: Will people understand how to use it? 
• Desirability: Will people want to use it? 
• Viability: If people use it, will we make money? 

Failure to systematically characterize, assess, and prioritize these risk factors could result in inefficiencies and delays in the development funnel or investment in a sub-optimal product. We often work with clients to help segment the risks in their development backlog by establishing a set of criteria and a framework that systematically evaluates their feature sets. Those with low risk should be managed in a standard work prioritization manner. 

For example, one of our enterprise software clients in the human capital management space uses a hybrid of a Delphi method and capacity allocation to make sure low-risk backlog is managed with minimum overhead. A cross-functional team made up of an experienced product manager, architect, support manager, and development engineer are responsible for reviewing the backlog monthly and voting on the ‘no-brainer’ (low risk/high impact) projects to prioritize. 

That prioritized list is managed against a fixed allocation of the team capacity, which is reviewed quarterly to make sure that the right balance is being struck between these projects and other portfolio priorities (new features, functions, etc.). The Delphi team members rotate annually, with the rotations being offset (only 1 or 2 reps change out at a time) to ensure that historical context is maintained. 

Features or functions that have higher risks need to be evaluated and managed with tools or frameworks that are contextualized for that risk. Often, it’s uncertainty that is underpinning the risk—so having an agreed-upon approach for peeling back that uncertainty and conducting experiments can help reduce the risk and move the feature into standard backlog. 

A recent example of this comes from one of our clients in the safety and security market. While the client maintains a strong brand presence and share of market in the public sector, they were unsure how their products and services might be used beyond that market domain. Specifically, there were multiple elements of risk: Would safety officers working for a multinational corporation want to use these products, or were their needs being satisfied through other workflows, tools, and systems? Would there be use cases or additional requirements for features and functions that were specific to commercial users that would require redesign or new capabilities? How would the evaluation and decision-making process work for companies looking to acquire these tools? 

Through a series of in-market qualitative and quantitative interviews and surveys, we were able to identify the buying process for solutions in this space. We also gained an understanding of the key challenges and issues facing users by testing reactions to our client’s offerings. In addition, we helped our client identify several potential prospects who expressed interest in the product(s), which served as a catalyst for entering the new market.

Properly assessing the risks associated with new products or features will allow your company to efficiently release the right products to the market, saving you both time and the misallocation of money invested.

Constant discovery and delivery: What do your customers need? 

The best digital product teams are constantly seeking to understand what users of their product actually need, while continuously releasing products to market. In maturing organizations, those activities are disjointed and conducted by separate groups of people, often resulting in the failure to transfer key information. 

The best approach is to create cross-disciplined product teams that are responsible to both discover and deliver the best product. West Monroe helped one client, a large retail organization, launch cross-disciplined product teams, reducing the delivery of value to internal users from 6+ months to 7 days. This allowed stakeholders in every facet of the business to discover the underlying need and define the solution from the same backlog, using a consistent set of criteria.

While there are countless frameworks and methodologies that can help, implementing these types of changes does not necessarily require significant effort. After understanding where the inefficiencies in your process lie, there are simple ways to test small-scale changes to expedite the assessment of risk and balance product discovery and delivery.

At scale, when your product teams are focused on both speed from opportunity-to-delivery and producing the right product, your organization will become the most resistant to change and a leader in the market.