Unboxed roundtable: Avoiding the road to product failure
Graeme McCubbin and Martyn Evans
Aug. 10, 2022
Successful product management lies at the intersection of design, technology and business. Bearing responsibility for a product that concurrently delivers value to end users (desirability) and meets the goals of the business (viability), whilst operating within the technological, political, and economic constraints of the organisation (feasibility), makes the role of the Product Manager amongst the most challenging in any team.
Taking a user-centred approach may indicate how value can be delivered to end users, but internal challenges, such as lack of buy-in, team misalignment, unreasonable deadlines, demanding stakeholders, and conflicting priorities, add layers of complexity to the process.
Other factors including limited access to end users, mounting technical debt, Key Performance Indicators, gateway reports, assurance and governance, organisational policies, and recruitment, can be extremely difficult, if not impossible, to navigate - however agile you may be.
Unboxed recently facilitated a roundtable discussion with a number of product owners, managers, and leaders from across local authority, central government, charity, and the private sector to discuss this topic, starting with these questions:
- How can we align the needs of end users, your core team, stakeholders, and the wider organisation?
- When user needs and business wants clash, how can the voice of the user take priority?
- How can we balance “business as usual” delivery with continuous and incremental improvement?
- Which organisations, departments and teams are doing this well, and what can be learned from them?
Here are four discussion points from the session:
Around the product
Creating innovative new products that could help transform the services currently provided is really challenging, because much of the team's energy is focused on the day-to-day delivery of the existing service.
“The challenge around changing services is shifting values and mindset, which is a longer process than building new products, so the focus tends to fall on the latter rather than working on the two together.”
An example was given. A new digital healthcare platform to help support patients remotely may have all the required features and functionality but depends on a coordinator to actually monitor and respond to the information it provides. To merely create the product without providing this completely new role within the service team would be destined to fail.
A new product may be developed within a digital innovation team but at some point it needs to be integrated within Business As Usual (BAU). There needs to be an identifiable home for it, and a team to integrate, use, and support it.
Policy can also add a huge amount of complexity, especially when developing new products in the public sector. Without the ability to adapt the underlying policy, there are limits to how far product innovation can really transform services for the better.
Frameworks and tools for discovery
An effective discovery is crucial to the success of a product. Product discovery can take many formats, and use different frameworks. What are different teams and organisations using?
The Google Ventures Design Sprint is one useful approach to explore specific ideas or problems in a self-contained and relatively short process.
Whilst the tried and tested five-day sprint is particularly powerful, it can also be adapted to suit situations where participants find it difficult to free-up so much concentrated time from their day jobs. Some of our panel members have spread the five days over a longer period, whilst others have taken individual sprint activities into shorter, more focussed workshops.
Whichever form the design sprint takes, it is a really useful way to generate ideas, gain stakeholder buy-in, and create a shared understanding and bond amongst a team. There was a word of warning however. The resulting prototype and feedback can set very high internal expectations which need to be managed carefully. The design sprint is only the start of the process.
GDS Service Standard
The GDS Service Standard is widely adopted in the public sector but is also useful in more commercial environments.
By breaking the product development lifecycle into clearly defined phases (discovery, alpha, beta, live), the standard provides a common framework for teams with different levels of experience and expertise and helps them avoid long-running and risky projects. The panel specifically discussed the value of the discovery phase, noting that a completed discovery doesn’t necessarily lead to an alpha. Other discovery outcomes can be:
- a strong indication that more exploration is necessary before progressing
- no tangible user needs are identified and the project should stop
Without explicitly declaring these potential outcomes in advance, there is a danger that stakeholders expect a project to proceed regardless, defeating the object of discovery somewhat.
Still focussed on early stage product development, the group discussed Lean Startup and the associated concept of MVP (Minimum Viable Product). It’s another really useful approach to ‘product learning’ which is focussed on reducing risk by identifying and validating your assumptions through experimentation.
To disprove or invalidate an assumption by testing a product feature that nobody wants is considered success provided you learn fast enough, without too much time or money spent. “Failure” of this kind, however fast, can still be seen as a negative in many organisations.
Lean Startup also places great emphasis on the importance of identifying appropriate metrics to indicate what success and failure look like - a theme that ran through our conversation.
Key Performance Indicators (KPIs) enable some organisations to measure tangible impact. For example, high levels of user contact, such as complaints or support requests, may help you identify areas for improvement and quantify the impact of those improvements.
Metrics that measure intangible benefits are much harder to identify and capture. How will you know if your product brightens someone's working day? Did you help solve a wider problem that you never even anticipated? Recognising and celebrating intangible benefits that may not be measured by your KPIs is really important. It can motivate the team and even change the direction of your product completely. How can you make the intangible, tangible?
Sometimes the impact you seek is a long way down the line and you need some more immediate metrics to indicate that you are on the right track. Theory of Change is a useful model to help identify these leading indicators and something we’re keen to explore further with the group.
Managing the roadmap
Some of the group actively avoid the word “roadmap” as it has negative connotations in their organisation but representing any anticipated future development of the product (whilst avoiding jargon )is crucial to keep stakeholders engaged and happy.
Using the “Now, Next, Later” framework has proved effective when integration with other products in the organisation is a factor. Combined frameworks can highlight dependencies and allow others to gain a holistic overview, enabling collaboration and coordination.
Managing stakeholders expectations in this area is also important. As one participant put it, “often stakeholders may say they want a roadmap, but what they really want is a project plan”.
Other questions and topics
Some of the questions and topics raised that we didn’t have time to cover include:
- How can you balance continuous improvement with ambitious new product / transformation programmes and ensure MVPs get the attention they need to grow?
- How can you find the right balance between agility and process?
- When it looks like a product is heading for failure, are there any techniques that can help to pivot away from this (even a little)?
- What's the difference between 'product failure' and something being decommissioned?
- What does best-in-class product development look like and who's doing it?
If you have any thought on these topics, we’d love to hear them — tweet us @Ubxd with your contribution, including the hashtag #avoidingproductfailure.
If you’re interested in attending and contributing to a future roundtable discussion, get in touch to find out more:
We’d like to thank Unboxed customer Melissa Sabella, founder and CEO of The Honeycomb Works for her expert facilitation of this session.
Some useful links:
- Product Plan (https://www.productplan.com/) — having rejected spreadsheets and other tools, PP is nice and simple, visually, and a great tool for walking stakeholders through multiple different, but connected, workstreams, including your core product roadmap, and separate streams of unplanned activity to work out how to juggle your BAU
- Azure DevOps (https://azure.microsoft.com/en-us/services/devops/) — good for working with epics and user stories
- GDS Service Manual’s how the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
- (10) One Week Product Discovery Sprints: https://medium.com/yoursproductly/10-one-week-product-discovery-sprints-f19c5aae8ae8