‘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.

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.