New Feature Validation Framework
A useful framework to validate any new product ideas and ensure that the products and services we design and build add value to the customer and bring business benefit.
Ideas can come from anywhere, everyone has opinions; that is no bad thing, without them, ideas will dry up and innovation will most likely stall. There’s always a need for people to share their thoughts, fears and ideas to ensure product progress.
For innovation to happen then all ideas should be given the time to flourish, but firstly are they the right things to do? Anyone within the business from the CEO to a Marketing Assistant, current customers and prospective customers alike — everyone has ideas. However all opinions, regardless of where they emanate from, should be validated.
If the team has no structure for this then often the highest paid person will have the power to establish their ideas, regardless of whether or not they are truly valuable. Ideas could also be accepted at face value and the time and effort it takes to design and build those new features could be a costly waste.
Every idea needs to be validated, just like all assumptions, and this framework will help with both containing, exploring and validating those opinions.
There are three reasons why this is crucial.
Primarily, this will ensure that any potential innovative thought is grounded in solid investigation. Secondly, it helps those people in the business with understanding the discovery and design process that technology teams undertake. Lastly, it should prove to the business that through customer validation comes more potential for business success.
The Framework
This article will take four product management techniques and combine them in a way that will attempt to prove whether new ideas are really worth the time and effort to design and build. We will look into:
- Lean Value Tree
- Impact Mapping
- Kano Model
- Cost of Development
These techniques might be relatively well-known to experienced Product Managers, but they are combined in a different way here. This framework will make the assumption that the reader has some experience or knowledge of these and will only give a brief overview with links for further reading.
Equally the framework detailed below should be used for new features ideas or functionality requests. Challenging or accepting minor changes to interaction, layout, design elements or copy should be managed by the experts dealing with each of these aspects.
It’s important to note that this process is most valuable when conducted along with any stakeholders, or even customers, that formulated the idea. However that is not always a reality in most large corporations. Try and include them throughout in smaller parts of the validation process, but if they are too busy or just not interested then it’s important to fully document and present the findings when finished. Regardless of the outcome this is an essential step to future collaboration and stakeholder engagement.
(Lean) Value Tree
It’s vital for any product or service to have a strategy. This should, although often isn’t, be based on the business strategy it feeds into. If that business strategy doesn’t exist (it almost certainly does), is inaccessible, confused or misrepresented then create the product strategy in isolation.
This obviously isn’t the ideal situation, but the belief is that once something like this demonstrates an element of value the wider business will start to take note. Sometimes it’s crucial to be pragmatic, in reality it can be very difficult to get access to a business strategy and having something to go on is most certainly better than having nothing at all.
More often than not businesses are not in a position to be Lean and even though the ‘Lean Value Tree’ can be viewed as sacrosanct in Product Strategy circles, as my friend and colleague Andy Birds once said: “… if your ‘Lean Value Tree’ ain’t ‘Lean’ then it’s just a Value Tree, and that’s ok.” So don’t be too concerned if the tree isn’t Lean, just focus on why the product being built exists.
Regardless of the naming conventions used for the tree (some like to have ‘Mission’ first, I prefer ‘Vision’ for example) there are four main levels to an LVT. In the very basic template below there’s; a product vision, mission or plan of how to achieve it, a number of goals that will aid that mission and multiple initiatives aimed to achieve those goals that will allow the continuation of the mission.
Notice here the cascade from the overarching vision to specific goals the team can focus on — each step should be contributing to the overall business strategy, whether that’s known or assumed.
Remember that using business language when defining the strategy will help with broader adoption of the framework. What business goal is it trying to achieve? Is it to make money or reduce costs? Are the team tasked with finding new customers or retaining current ones?
As Jared Spool points out in his UX Strategy workshop, there are always five key business strategic priorities. Even if the business strategy is unaccessible it’s fair to say it will be based on one of these five; increasing revenue, decreasing cost, increasing new business, increase existing business or increasing shareholder value.
Product visions can often fall down on actually understanding what parts should be truly ambitious and where a more concrete understanding of what needs to be done should be presented.
I like to the follow the ‘ABAC Principle’ that assigns a greater degree of clarity to each level as it goes down the the tree:
- Where Vision is Aspirational, presenting a bold and ambitious claim,
- the Mission has to be Believable, to ensure people accept that claim.
- Goals must be Achievable; to ensure actions stay grounded in reality,
- and Initiatives should be Conceivable, allowing the team accountability.
The team can now understand both their place in the business and where their day to day work fits into that. There are now goals that measures can also be applied to.
Ask the question: if the idea is not achieving a strategic goal and therefore providing some value to a customer and having some benefit to the business then what is it achieving?
It’s hard to prove that a new idea doesn’t fit to a goal if there aren’t any goals, it’s easy to make an argument to say that it does.
Reverse Impact Mapping
Taking the goals created in the Value Tree the team can now investigate exactly which of their customer types are most likely to help them achieve each one.
Impact mapping is a great tool that can help frame the conversation, extending from the product goals to customer types and how each of them may be impacted. From here the team can collaborate and generate possible features or functionality that will have the most impact.
Impact Mapping can also help encourage mixed disciplinary teams to participate and will aid their understanding of how their ideas could achieve a higher aim.
For this framework we’ll use Impact Mapping in the opposite way; to thoroughly validate ideas that may have come from the business, team or customers. Here is the basic layout of the Impact Mapping tool:
Now consider how this can be used in reverse; taking the idea first and rolling it backwards to the impact, customers affected and all the way to a goal:
During the process at each step only one thing will happen:
- The idea will either have an impact or no impact
- The idea will either have a customer or no customer
- The idea will either be aligned to a goal or not aligned to a goal
As the idea is worked backwards through the flow, if at any point there is no affect, then the idea stops there and should be communicated that it didn’t align to the strategy of the product or business.
If however, there is an impact or a customer or group that was previously unknown, then these can be added to the impact mapping tool for the next idea generation. It might also be that there is a new goal discovered, the idea created has helped the team reevaluate their product strategy and most likely aligned it to the business even further.
If the idea is aligned to one of the current goals then this is also fantastic, there’s an idea generated that could really benefit the business and probably customers, whether known or unknown, before the activity was undertaken.
Should the team go ahead and build? It’s one thing to be aligned with the business, whether with the original strategy or with a new understanding. But it’s entirely another thing whether or not this is actually valuable to customers. Anything not valuable to customers is either not going to be, or will struggle to be, beneficial to the business.
Kano Model
Now that the team has identified the idea is sound (i.e. it aligns to a goal, affects a particular customer and has some level of impact) it’s time to actually validate with real customers whether not they view this as useful or not, in other words, will they use it and crucially, will they be willing to pay for it?
We’ll start to look at this using a method called The Kano Model. This article will outline a basic view of The Kano Model, for more insight then I suggest this fantastic article.
The Kano Model is a method of determining whether or not a particular new feature is actually an expected piece of functionality or, if it’s an added extra performance feature or even a delighter. The catch with new features is that over time customer’s interests wane and what once was a delighter turns into a basic requirement, this can often happen quite quickly.
Kano is equally as useful at mapping new features as it is at mapping existing features over time, to highlight feature-rot and the moving landscape of the market, customers and products.
If the idea generated and then confirmed with Impact Mapping, is indeed aligned to an existing or new goal, it’s time to find out whether or not it’s important to customers.
The best way to find this out is by speaking to real customers using the question format that Kano provides. It’s also advised to insert this new feature into a list of existing or planned features for the customer, helping to reduce any bias. This can then be measured alongside previous Kano exercises or help to place the new feature along with existing ones in order of importance to customers.
If the new feature is seen as a basic requirement, the idea is valid and the team has found an untapped area to investigate even further. It might be that something has been missed in the original discovery, or that a new customer problem has been revealed. This can now be used to discover even more new features and expand the team’s understanding of customers’ behaviours and needs.
If the new feature is seen as a performance feature, a ‘nice to have’, or even as an innovative delighter, then it might be something to consider and place on the customer problem focused roadmap to investigate further or work through some possible options to aid making a decision.
Cost of development
Now it’s been recognised as desirable, is this new idea actual feasible?
Cost of delay will give a clear enough picture to the business that allows them the ability to prioritise the backlog based on the money lost by delaying features to the market. By understanding the cost of delay, they will be able to calculate the cost of not releasing the feature now, compared to releasing it at a later date.
This will often be the determining prioritisation factor but what’s missing here is the cost it takes to actually design and build the feature in the first place. Regardless of the validation process and outcomes it’s important that the team is able understand and communicate the cost of analysing, designing, building, testing and iterating upon the new feature.
Decisions of what and when to build become much more straightforward when the cost of development are understood along with the potential cost and revenue generated.
If the new idea turns into functionality that costs the business £20,000 to build and they forecast that it could make £100,000 a month in revenue then, it’s a no brainer. However, if it was just an idea that they envisage that will generate little revenue, then they have to make the hard decision of whether it’s worth the cost.
In addition, by forecasting the cost of development the team can suggest the most appropriate time to build based on other determining factors. Cost of development could decrease over time when new technology is introduced or the team are able to work on refactoring code, dealing with tech debt or implementing new libraries. This cost can also take into account the time it could take for further research, design and testing multiple devices.
It’s surprising how often business stakeholders don’t have a view of how much revenue they expect to make from certain features, providing them with a cost of development compared to revenue lost by delay will help them to rationalise the potential value of the new feature and whether or not to go ahead.
Pushing back the HiPPOs
Challenging the ‘Highest Paid Person’s Opinion’ (HiPPO) can often be a struggle but with this four step framework the team should now have all the material and data they need to validate new ideas, no matter where they’re generated from.
It’s a great feeling when you are able to go back to a stakeholder and show them their idea was actually valuable to the business, there’s nothing better for getting them onside with the processes of the product team. Be sure to fully detail the steps it took to get these decisions, as it’s vital that people know the effort it takes to realise the true value of ideas.
If the idea doesn’t make it, then it’s crucial to still detail the iterative process it took to get there. There’s learning in all perceived failure and even though the idea might not be right for now, it could still succeed in the future as customer behaviour or views change. Of course this is a much harder conversation to have with a business stakeholder, but with the thorough process the team has taken they will find it difficult to challenge the decision.
I’m a Product Enablement & Ops Consultant with over a decade working in technology organisations, enabling product leadership to maximise their performance and impact.
Visit chriscompston.com to find out more.
