POV

/

19.07.22

Why problems matter

Rebecca Evans

Senior Product Manager

Outcomes over output

‘Outcomes over output’ is central to all projects at iCrossing. It emphasises the importance of adding value, keeping us focused on delivering the right outcomes for our clients (and their customers), instead of being focused on delivering pre-conceived or unvalidated features.

What does this mean in the real world? In this article I review the impact of this statement on projects within an agency and balance the implications of outcome driven development over feature-driven development.

The content of this article is based around Marty Cagan's work, referencing both his book 'Inspired - How to create tech products customers love' and his blog with the Silicon Valley Product Group.

Outcomes vs features

To explain the difference between outcome and feature driven development, it helps to take a step back and understand the risks that must be mitigated during product discovery to ensure the delivery of successful products. In his book ‘Inspired’, Marty Cagan breaks these down:

  • Value risk: the need or want of the product, will the customer choose to use it?

  • Usability risk: the usage of the product, will the customer know how to use it?

  • Feasibility risk: the resources and technologies available, can this be delivered within the time and with the technologies and skills we have available?

  • Business viability risk: the wider organisation, does this fit in with our overall sales strategy, is it legally compliant, is it on brand etc?

In outcome driven development, the product team prioritises customer problems. They work collaboratively to ensure the delivered solution is loved by customers and works for the business.

This team is made up of three core roles: designers, who are responsible for the usability of the solution; engineers, who are responsible for the feasibility of the solution and product managers who are responsible for the value and viability of the solution. For outcome driven development to be successful, the product manager must truly understand the customer, the industry, and the business – ensuring that the product is not just suitable for the business and its customers, but that it brings value to both parties.

In feature driven development, value and viability are normally preconceived, and the decisions on what to build have usually been made long before a product team gets involved. In this scenario a product manager fills more of a facilitator role, overseeing designers and engineers while they work to ensure the product is both feasible and usable. The feature may be delivered on time, and it may be intuitive and easy to use, but often we find that customers simply are not using it as they cannot perceive the value, and it ends up going nowhere. In many cases this is down to the problem not being there in the first place, which is something that would have been flagged early on if a proportionally smaller amount of time had been invested up front in product discovery.

From experience, it’s the latter that continues to crop up, with a business being blinkered in delivering against a feature roadmap and not empowering their teams to ideate solutions that will make a real impact.

The Silicon Valley Product Group (SVPG) recently posted an article that discusses the importance of ‘falling in love with the problem rather than the solution’ and this really does resonate with us at iCrossing. By investing in a problem, we are empowering teams to be flexible, to really listen to feedback and to learn and adapt until they find that value.

Outcome driven development in practice

At iCrossing we strive to ensure our product objectives are outcome driven, but we appreciate the importance of keeping to a budget and often the need for work to be delivered before a certain date. We understand that iterations can’t continue in an infinite loop, and we need to strike a balance between achieving real value and ensuring the outcome is feasible.

To find this balance, we take a risk averse approach to new product development, validating unknowns and minimising risks as frequently and quickly as possible to reduce unnecessary investment. Our product whitepaper breaks this out further, but for the purpose of this article I have summarised the approach into three tangible stages:

  1. Discovery: In this phase our goal is to develop a deep understanding of your business, your industry and your customers. This allows us to understand the problem that you’re trying to solve and helps us to determine business viability when we start looking at potential solutions.

    Using a combination of workshop exercises, desk-based research, and data analysis we get insights on the behaviours, needs, and opportunities from the target audience segments. The insights are used to validate the problem space and drive actionable recommendations that feed the solution design.

  2. Solution design and validation: Using the insights as a baseline, we’ll work collaboratively to define a solution that we feel is fit for purpose. During this process there are undoubtedly assumptions that will be made, and we have several exercises to test and validate them.

    In my opinion the most effective way to validate is by getting feedback from real users. This not only minimises the usability risk, but it provides context and insights to ensure customers will want to make the switch.

    To minimise the time that needs to be invested, these user tests will be performed against a rapid prototype. If the feedback is negative, it is vital that we listen and adapt. That might mean making tweaks and iterating, or it might mean we need to go back to the drawing board. Although this may seem like a step in the wrong direction, it’s quite the opposite. The approach allows us to learn quickly and gives us the opportunity to change solutions before we’ve over invested.

    As the SVPG said, in its Discovery – Feedback blog: “If you really do want to create an amazing product, then far from this critical feedback being a setback, it’s a chance to find the insights we need to get this product to where it needs to be.”

  3. Lean development: Validation enables us to tackle the big risks early on, but it doesn’t eliminate all risk. Lean agile is a methodology that allows us to deliver in small increments, to learn from these implementations, and take these learnings on board in the next phase. This way of working is focused on delivering and assessing value as quickly as possible. It allows you to get your product to market early and provides clarity on what to invest in further.

Summary

Outcome driven development encourages companies to focus on the result or value they want to achieve, rather than the outputs or features that are delivered. For it to be successful we must focus on solving problems, we must collaborate on solutions, and we must validate value early on. It does require more investment up front, but the insights achieved through the approach will save you time and effort overall, ensuring the delivered product is loved by (and works for) both your customers and your business.

Continue reading

Report

/ 06.04.2022

The iCrossing Guide to Site Migration

SEE FULL Report

POV

/ 12.04.2022

Dyslexia in project management

SEE FULL POV

POV

/ 12.03.2015

Boost your content's SEO value using amplification

SEE FULL POV
ix-chevron-bg

Contact

Are you ready to make a digital step-change?

We believe that moving too slowly in digital is the biggest risk your business faces. If you are ready to move faster in digital, we are here to help.

Get In touch