Programming languages
Idea to product: the working model
Even with a brilliant idea and a strong product-market fit, the best product teams sometimes come up short. In 2011, the product failure was 48%, according to business guru R.G. Cooper, but these days figures range up to 95%, with many falling between 70-90%. So, whether you’re building new differentiated products, reimagining new customer experiences, or transforming into a product organization to improve your agility, you’re likely to come up against some challenges. In this article, we’ll explore five common challenges — and how you can overcome them.
Last summer, we worked with a client that was rebuilding its two most lucrative products — each worth hundreds of millions of dollars. The product team needed a vision for maximizing the products’ potential — and we were asked to partner with them to define the vision and a path to get there.
By talking to customers, we realized the client had a more fundamental challenge. Customers were paying for a product and unable to articulate the value they were receiving. That’s a recipe for losing customers.
This is something we often see with mature products: the value proposition isn’t updated even as customers’ needs evolve. And because product teams have lost sight of customer value, they end up focusing on features their customers are ambivalent about. Meanwhile competitors are creating differentiated experiences and taking market share.
Back at the client, the focus had gradually settled on feature parity, rather than exploring opportunities for innovation and automation.
To break them out of this rut and to focus their minds on customer value, we led them through a series of exercises to create strong value propositions for the two products. A few weeks later, we revisited these ideas but with specific customer feedback. That gave us a roadmap for how to refine the products. And we then aligned this to the organization’s goals for three months, one year, and five years out by showing that some of what was currently being built could be bypassed with higher-value, more innovative features like automation, machine learning, and a more interactive experience for customers.
Whether product teams have been recently created or been at the coalface for a while, it’s important to frequently revisit and redefine a strong value proposition for customers. Think about how this value proposition continually evolves as customers’ needs evolve, and allow everyone on the team to challenge it all the time, every step of the way. You’re more likely to succeed at this if you can foster a culture that questions perceived wisdom and learns from user research.
It will ultimately drive the overarching vision and successes of the organization. Align your team and push them to think big.
A product champion:
To strike the right balance, it can help to think of the distinction between a product blueprint and a product roadmap. A blueprint provides a high-level map to guide teams — the roadmap is a step-by-step plan of how to get there.
Product roadmaps become problematic because they encourage the rest of the organization to fixate on dates. Product roadmaps highlight the sequence of delivery, but many of those deliverables will be based on assumptions made at the outset: what happens when your vision for what’s needed changes during the project?
Getting your product blueprint right is hard. For instance, one team we worked with — who had been practicing Agile for a year — kept seeing disagreement about the future direction of the product between the CEO and product owner. The team had created their stories, they had prioritized these into two-week iterations, and further defined their backlog. But the mistake they made was using that backlog as the basis for discussions about future plans. Product backlogs are typically at a story, epic, or feature level and exist primarily to enable the team to align and prioritize near-term work.
Product backlogs don’t describe the compelling experience you are creating for your customers and are therefore not appropriate for an executive or stakeholder audience.
Your product blueprint should be a living document, ideally one that’s displayed near the product team. That visibility will encourage conversations that bring new ideas to be tested.
A product blueprint will typically have the following core elements:
But too often, we’ve seen teams get too caught up on how they plan to deliver and forget to look at what will work for them. At one large client, the choice of Agile methodologies proved explosive, as different groups argued about what would work for them. They ended up with projects where development was driven by what could be delivered within a six-week window — rather than by what would deliver customer delight. This limited the teams’ ability to experiment and explore new ideas and resulted in suboptimal products; in some cases it resulted in teams working on stories that were widely agreed to be unnecessary and irrelevant to the user.
How did they get to that state? There are many reasons why product teams fall short, but often, we see problems when the teams get fixated on methodologies that have worked for previous teams without considering whether it’s a good fit for the team at hand.
We recommend that before you implement specific methodologies across the business, try to pilot some methodological differences in a few teams first. We did just that at one company: we had two products using different methodologies that would allow for more experimentation. We hypothesized what would work for them, and along the way discovered what worked and what didn’t work and we changed it up.
The methodologies you choose for your product teams to deliver should support and not inhibit experimentation. There are myriad flavors, sizes, colors, and a vast spectrum of rigor for how to deliver a product, but what’s most important is not that it works for other teams or companies or industries, but that it works for the team you’re on and the product your team is building.
It’s tempting to focus on the numbers and features delivered, or to be qualitatively consumed by others in the organization evaluating “did they deliver exactly what they said they would?” The answer to the last one depends on how it’s framed. If the teams experiment and have shorter feedback cycles and learn from them in a way that allows the product direction to evolve, even if those set of previously agreed-upon features changes, then yes.
A hyperfocus on predictability as a key measure of success is common in larger organizations. The head of engineering at one of the retail companies we’ve worked with explicitly called out that this “predictability didn’t make sense” but he wasn’t sure how to motivate the methodology and product teams to do it differently. Another stakeholder said she didn’t care if they were predictable, stating the elephant-in-the-room, that “predictability doesn’t matter…. we might find we need to develop something more valuable and then our predictability would drop or go away and that’s ok.” Many times product teams and those supporting the product teams know that this type of measure can harm product development but are unsure of how to pivot to a measure that maximizes team learnings.
We were working at a healthcare organization that had been adopting agile ways of working for the past five years. They currently had measures in place to track predictability and velocity (how fast teams can churn out requirements) and compared throughout the organization, but those were the only measures put in place. The values were aggregated on a dashboard and shared at the program level. Teams were growing frustrated at the lack of leadership support for measuring real customer value. When we spoke to leadership, they were equally frustrated. The PMO responded to the teams’ requests for a different way of reporting by giving them a shinier, more aggregated view of team predictability.
When we asked product leads, they told us to come to showcase!
Showcases were run every two weeks, and it was difficult and inefficient to attend every single one, make sense of what every team was working on, then decide whether we were doing the right things by the customer and the organization. There had to be a better way.
As we worked with teams we found two problems: teams were lacking an effective way to measure customer value, and they didn’t know how to measure the value. Working team by team, we identified what they were building and why it was important for the organization. We brought in stakeholders to help us define and agree on the set of metrics that were important to the organization (these were business benefits such as revenue, profit, market share). Next, we took the product hypotheses — the things teams were validating and considered valuable to customers — and applied an experimental approach to validating with customers. These experiments had a set of leading indicators — early measures that gave immediate feedback into whether the teams were focusing on the most important things for the customer.
It was important to get stakeholder alignment on these leading indicators because they become the early measures of success for the product or service. Breaking down the measures in this way (into leading and lagging indicators) enabled leaders to steer more effectively, and created a richer dialogue between the stakeholders and the teams.
Examples of leading and lagging measures and where they are effective:
If you’re part of a product team, regardless of your product’s maturity or product team’s maturity, challenges will inevitably come up. It isn’t about how many challenges the team encounters, but how quickly the teams are able to resolve the challenges. Everyone on the team is responsible for the success of the product. By having a clear customer value proposition, and using measures of success to guide decisions, you will more effectively iterate and evolve your product without bringing in individual biases and opinions.
Articulate a clear customer value proposition
Everyone thinks they understand the value of their products, but dig a little deeper, and problems can quickly emerge.Last summer, we worked with a client that was rebuilding its two most lucrative products — each worth hundreds of millions of dollars. The product team needed a vision for maximizing the products’ potential — and we were asked to partner with them to define the vision and a path to get there.
By talking to customers, we realized the client had a more fundamental challenge. Customers were paying for a product and unable to articulate the value they were receiving. That’s a recipe for losing customers.
This is something we often see with mature products: the value proposition isn’t updated even as customers’ needs evolve. And because product teams have lost sight of customer value, they end up focusing on features their customers are ambivalent about. Meanwhile competitors are creating differentiated experiences and taking market share.
Back at the client, the focus had gradually settled on feature parity, rather than exploring opportunities for innovation and automation.
To break them out of this rut and to focus their minds on customer value, we led them through a series of exercises to create strong value propositions for the two products. A few weeks later, we revisited these ideas but with specific customer feedback. That gave us a roadmap for how to refine the products. And we then aligned this to the organization’s goals for three months, one year, and five years out by showing that some of what was currently being built could be bypassed with higher-value, more innovative features like automation, machine learning, and a more interactive experience for customers.
Whether product teams have been recently created or been at the coalface for a while, it’s important to frequently revisit and redefine a strong value proposition for customers. Think about how this value proposition continually evolves as customers’ needs evolve, and allow everyone on the team to challenge it all the time, every step of the way. You’re more likely to succeed at this if you can foster a culture that questions perceived wisdom and learns from user research.
It will ultimately drive the overarching vision and successes of the organization. Align your team and push them to think big.
Have a product champion and orchestrator
A strong value proposition is a great start but your product team will need a champion to own and drive the product forward. There are hundreds of blogs, lists, bullet points, and books describing what makes a great product person and the many hats they wear. Here, we’ll narrow it down to three non-negotiables of product leadership.A product champion:
- Fully understands customer needs. A product champion believes in the value proposition because they know it’ll deliver something the customers love. They understand users’ pains and delights and use this understanding to make informed, forward-thinking decisions. A product person out of touch with the customers cannot brilliantly orchestrate product delivery.
- Aligns product teams to organizational goals. Your product should directly support organizational goals and vice-versa. At one company we heard that the “value proposition is better for the business than for our customers. It’s easy to lose sight of why you are building something. Making organizational goals and aligning to what you are building and clarity of why this is important for the customer keeps you on track to always delivering value.
- Embodies coaching and not gatekeeping. A cross-functional team of developers,designers, testers and data scientists should be empowered to make their own decisions as a team and to contribute their unique perspectives of the problem. Don’t control or tell teams what to build, but allow other perspectives and ways of solving problems to take flight. The crew needs to be inspired and the product person needs this skill that is integral to ensuring the product’s success.
Prioritize product blueprints over product roadmaps (and agile backlogs)
There’s a myth in the agile community that if we’re “doing agile”, then we don’t need to plan. Yes, too much upfront planning can be wasteful, but some future gazing is needed to reduce your project’s risks.To strike the right balance, it can help to think of the distinction between a product blueprint and a product roadmap. A blueprint provides a high-level map to guide teams — the roadmap is a step-by-step plan of how to get there.
Product roadmaps become problematic because they encourage the rest of the organization to fixate on dates. Product roadmaps highlight the sequence of delivery, but many of those deliverables will be based on assumptions made at the outset: what happens when your vision for what’s needed changes during the project?
A product blueprint is a communication tool to help align the organization and create a shared understanding of the future direction of the product.
Getting your product blueprint right is hard. For instance, one team we worked with — who had been practicing Agile for a year — kept seeing disagreement about the future direction of the product between the CEO and product owner. The team had created their stories, they had prioritized these into two-week iterations, and further defined their backlog. But the mistake they made was using that backlog as the basis for discussions about future plans. Product backlogs are typically at a story, epic, or feature level and exist primarily to enable the team to align and prioritize near-term work.
Product backlogs don’t describe the compelling experience you are creating for your customers and are therefore not appropriate for an executive or stakeholder audience.
Your product blueprint should be a living document, ideally one that’s displayed near the product team. That visibility will encourage conversations that bring new ideas to be tested.
A product blueprint will typically have the following core elements:
- How the product aligns to organizational goals
- Key measures of success
- Hypotheses to be validated and those that have been validated
- Customer goals
- Customer journeys
- Prototypes that bring the product vision to life
- Customer adoption plan
- A history of key decisions made and why they were made
Use a methodology that supports product experimentation
How your team does delivery drives what product is ultimately delivered. Everyone on the team — designers, engineers, testers, data scientists, product people — should be able to experiment and innovate at every level of product development.But too often, we’ve seen teams get too caught up on how they plan to deliver and forget to look at what will work for them. At one large client, the choice of Agile methodologies proved explosive, as different groups argued about what would work for them. They ended up with projects where development was driven by what could be delivered within a six-week window — rather than by what would deliver customer delight. This limited the teams’ ability to experiment and explore new ideas and resulted in suboptimal products; in some cases it resulted in teams working on stories that were widely agreed to be unnecessary and irrelevant to the user.
How did they get to that state? There are many reasons why product teams fall short, but often, we see problems when the teams get fixated on methodologies that have worked for previous teams without considering whether it’s a good fit for the team at hand.
We recommend that before you implement specific methodologies across the business, try to pilot some methodological differences in a few teams first. We did just that at one company: we had two products using different methodologies that would allow for more experimentation. We hypothesized what would work for them, and along the way discovered what worked and what didn’t work and we changed it up.
The methodologies you choose for your product teams to deliver should support and not inhibit experimentation. There are myriad flavors, sizes, colors, and a vast spectrum of rigor for how to deliver a product, but what’s most important is not that it works for other teams or companies or industries, but that it works for the team you’re on and the product your team is building.
Use valuable team measures that maximize learnings
It’s important teams are rewarded for successes in developing a product; how this is measured and how teams are motivated can be the difference between a product that fails or succeeds.It’s tempting to focus on the numbers and features delivered, or to be qualitatively consumed by others in the organization evaluating “did they deliver exactly what they said they would?” The answer to the last one depends on how it’s framed. If the teams experiment and have shorter feedback cycles and learn from them in a way that allows the product direction to evolve, even if those set of previously agreed-upon features changes, then yes.
A hyperfocus on predictability as a key measure of success is common in larger organizations. The head of engineering at one of the retail companies we’ve worked with explicitly called out that this “predictability didn’t make sense” but he wasn’t sure how to motivate the methodology and product teams to do it differently. Another stakeholder said she didn’t care if they were predictable, stating the elephant-in-the-room, that “predictability doesn’t matter…. we might find we need to develop something more valuable and then our predictability would drop or go away and that’s ok.” Many times product teams and those supporting the product teams know that this type of measure can harm product development but are unsure of how to pivot to a measure that maximizes team learnings.
We were working at a healthcare organization that had been adopting agile ways of working for the past five years. They currently had measures in place to track predictability and velocity (how fast teams can churn out requirements) and compared throughout the organization, but those were the only measures put in place. The values were aggregated on a dashboard and shared at the program level. Teams were growing frustrated at the lack of leadership support for measuring real customer value. When we spoke to leadership, they were equally frustrated. The PMO responded to the teams’ requests for a different way of reporting by giving them a shinier, more aggregated view of team predictability.
When we asked product leads, they told us to come to showcase!
Showcases were run every two weeks, and it was difficult and inefficient to attend every single one, make sense of what every team was working on, then decide whether we were doing the right things by the customer and the organization. There had to be a better way.
As we worked with teams we found two problems: teams were lacking an effective way to measure customer value, and they didn’t know how to measure the value. Working team by team, we identified what they were building and why it was important for the organization. We brought in stakeholders to help us define and agree on the set of metrics that were important to the organization (these were business benefits such as revenue, profit, market share). Next, we took the product hypotheses — the things teams were validating and considered valuable to customers — and applied an experimental approach to validating with customers. These experiments had a set of leading indicators — early measures that gave immediate feedback into whether the teams were focusing on the most important things for the customer.
It was important to get stakeholder alignment on these leading indicators because they become the early measures of success for the product or service. Breaking down the measures in this way (into leading and lagging indicators) enabled leaders to steer more effectively, and created a richer dialogue between the stakeholders and the teams.
Examples of leading and lagging measures and where they are effective:
| Leading indicators | When to use |
| Positive feedback from qualitative user interviews | During early product concept validation (e.g. prototypes of the user experience) to guide product direction. |
| A/B tests |
When there are two or more possible versions of a product element (e.g., button placement on a mobile app, marketing content that drives call to action) and you want a statistically rich sample of customer feedback. |
| Customer uptake from pilots |
When validating whether the product or service meets the needs of a specific customer segment. The early definition of a pilot should not include all the ‘bells and whistles’ of the full product features, instead it should focus on the key value proposition to the customer. |
| Ratio of hypotheses proven correct/incorrect | To obtain a sense for whether the teams are validating the right opportunity. If the ratio is low (more hypotheses are proving incorrect) this should identify a change in approach, for example, is it time to redefine the value proposition? Look to a longer horizon of future value? (is the market ready for this type of innovation?), validate with a different customer segment? |
| Lagging indicators | When to use it |
| Profit | Evaluating the long-term commercial viability of a product |
| Revenue | Evaluating near-term commercial viability of a product |
| Market Share | Validating share of potential market opportunity |
| Net Promoter Score | Gauge loyalty of customers |
| Customer Lifetime value | Understanding the value a customers have brought to the organization during the relationship (measured by net profit for any given customer). |
If you’re part of a product team, regardless of your product’s maturity or product team’s maturity, challenges will inevitably come up. It isn’t about how many challenges the team encounters, but how quickly the teams are able to resolve the challenges. Everyone on the team is responsible for the success of the product. By having a clear customer value proposition, and using measures of success to guide decisions, you will more effectively iterate and evolve your product without bringing in individual biases and opinions.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
