The practise of prioritization of features based on customer satisfaction levels & subsequent iterations of a complete “limited” set of features should form the bedrock of all Agile Software Development Processes
We at OOZOU feel lucky to have a diverse group of clientele ranging from Fintech, Telecommunications, eCommerce, Health and more. With a world class team of managers, designers & engineers, we strive to deliver quality products working closely with clients. However, as always, the road to excellence is not rosy. There are definite struggles on both sides, and quite often it’s due to an unorganized set of features or lack of proper analysis to develop a sound Minimal Viable Product (MVP).
A product development process can be analysed using a very effective model called Product-Market Fit Pyramid. This framework defines two spaces:
Problem space, which deals with the physical world facing an actual problem & the end users to whom the solution is being addressed to, and
Solution Space, which deals with the technological & managerial aspects of developing an effective solution.
With this clear distinction, the model further breaks down these spaces into five key components namely, target customer, customer’s underserved needs, value proposition, feature set, and user experience.
Fig. 1: Product-Market Fit Pyramid
Our clients, being experts in their respective fields, are always great in analyzing Market hierarchies: target customers & their underserved needs. However, they start to struggle in defining a sound Value Proposition & subsequently Feature Sets. In total fairness, it's not an easy task either. Being heavily invested in the product, it's quite natural to have a wider perspective and long term vision. However, this does not help in developing a MVP that’s quick to market and agile enough to adapt to analytics obtained from real world usages.
To that end, Kano Model, initially developed by a Japanese consultant Noriaki Kano, is a great tool to analyse customer needs with respect to their satisfaction levels and then build upon them to consequently develop a sound value proposition.
Fig. 2: Kano Model
Kano classifies features into four categories, depending on how customers react to the provided level of Functionality.
Must-be: These product features are simply expected to be in the product & the final product will be incomplete with them. These features do not affect customer satisfaction but are needed in the final product.
Performance: The more of these features we provide, the more satisfied our customers become.
Delighters: These features set you apart from competitors and bring a delight to your customers.
Indifferent: The presence (or absence) of these features doesn’t make a real difference. We should really avoid working on these because they’re essentially money sinks.
We, OOZOU, are an Agile Shop and as such we use User stories to document feature lists.
A user story is simply an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer .
We recommend classifying product benefits aka User Stories into three primary categories of Kano Model: Must-be, Performance & Delighters. Brainstorming principles apply in this stage & teams must be encouraged to add as many features as they can come up with. The richer this list is, more refined the final MVP will be.
Completion of this step will eventually form the backlog of the product.
Now comes the most critical phase of the process, defining a MVP candidate or as developers say Version 1. It’s very important to remind ourselves that a MVP has to be “minimal” but that “minimal” is in respect to value propositions and not to one set of features.
An MVP should still convey what’s the problem space of the product & the competitive edges of the solutions, just not all.
Building upon the backlog developed from the Kano model, we can now rank features in each category based on the relative importance & then devise a MVP candidate. As we need all of the must-be features, they stay in Version 1. We choose the most important Performance Benefits & Delighters features & that effectively gives us our MVP.
This practise produces a well thought-out MVP and a roadmap for further development. Quite obviously, the roadmap will change over the course of product development, but the practise of prioritization of features based on customer satisfaction levels & subsequent iterations of a complete “limited” set of features should form the bedrock of all Agile Software Development Processes.
If you are facing similar problems with your product development process, reach out to us: