Product Feature Prioritization- KANO Model

New requirements are always bombarding product managers. A new requirement can be in the form of :
               enhancing an existing feature    or               adding entirely  new features in product

list of features to be developed is long 
                        => time & resources  to develop are low

While some choices are straight forward , often their are competing features and its difficult to pick the priority of one feature vs the other feature.

Kano Model is a solution to this problem

Why Product feature prioritization is crucial ?

• A poorly conceived product can result in user dissatisfaction
• Features in product are selling points for the product. It is important to come up with right set of features to attract potential customers
• Absence of a certain feature at certain point in product evolution can lead to user dissatisfaction which may lead to drop in usage

Why Product prioritization is required ?

Usually product development is constrained by 

• Cost
• Resource
• Time

What ever is desired cannot be developed in one go

During initial  development phase :
        It is important to come up with minimal viable product (MVP). An MVP is basically the minimum feature set required to make product usable & acceptable by customers

After the initial release :  
       It is important to prioritize feature development based on factors such as

• Customer needs
• Pain areas in using product
• Performance 

      Features which are more critical need to be put first in the row to provide an early relief.

How to set priority ?

This is one area where the art and science of product management converge!

You must be passionately committed to your customers and stakeholders. At the same time you should be able to objectively set priorities to help them. 

It is important to delight your customers , but at the same time it is important to understand your constrains and take the right decisions.

Choosing the right tool and mechanisms for making decisions is very critical.  Kano Model is one such tool.

Kano Model for prioritization

The Kano Model is a theory that was developed by Noriaka Kano in the 1970s and 1980s while studying quality control and customer satisfaction. 

Kano Analysis allows you to classify product (or service) features according to their impact on customer satisfaction. 
It not only helps you in deciding but also explaining your decisions to stakeholders.

As per Kano model any feature should fall in any one of these three categories:

 1 Basic ( customer expect these )

A basic product feature is one that is essential for a product.  
Not having this type of feature will leave customers dissatisfied. However having this feature will not add to satisfaction level as these features are taken as granted by customer.

For example if you are buying a car , a basic product feature for a car would be a steering wheel or an engine. A car needs both to function. 

If these features are not there , customers cannot use the product. However having then is not adding to satisfaction level. In other words these features are noticed only if they are absent.

2 Satisfiers ( customer demands these : more the better)

Customers wants these type of features as opposed to expect. The more we deliver, the happier the customer. Doing well here allows us to create satisfied customers.

Some examples could be lower prices, larger amount , faster delivery , greater reliability etc.

For example a satisfier feature  for a car is fuel efficiency. People tend to prefer cars with a better fuel efficiency.

More of these types of features are there in product , more satisfied the customer will be.

 3 Delighters ( customer do not demand but is highly satisfied to have them)

 Delightful feature are ones that are neither necessary nor demanded by customer . But if they are added they really can really excite and raise satisfaction level to very high level. 

For example for a car, a delightful attribute could be a convertible roof. On the right sporty car and for the right customers, a convertible roof can be really fun. But it’s not essential for the car to work, and also doesn't enhance the car’s performance.

How to use KANO Model

Map your features as per KANO Model to determine :

1. What are the basic features  that users simply expect to be there and where would the absence of these features lead to frustration? Only develop these features to a level that they fulfill the requirement. Remember that any further enhancement after satisfaction level will not increase satisfaction.
2. Which features are Delighters? Focus  efforts here and make sure you’re constantly developing new ones.
3. Monitor your customer satisfaction and competition to ensure that features you think delight users haven’t slid into basic expectations and no longer help your customer satisfaction.
4. Find and focus on sustainable delighters that truly differentiate your product and continue to deliver customer satisfaction over time

Changes in feature categories

It is important to remember that category of features may keep on changing due to following factors:

• New competitive products emerging in market
• Higher expectation from customers after using a feature
• Tendency to take a feature as granted ( basic) after using it for long time.

Therefore it is important to ensure that category of features is revised from time to time.

Product managers need to keep track that which delightful features have become satisfier and eventually basic features. It is also important to keep on adding delighters to keep customers excited.

The Kano Model in action

Now that what Kano model is all about , how can you go about gathering data to plot features as per kano model. Customer Survey is a great method. Basically two questions are asked about each proposed feature:

1. What do you think of the product if it includes feature X?
2. What do you think of the product if it does not include feature X?

There can be three valid responses to these question:

1. I Like It
2. It Does not matter
3. I dislike it

The answers to these questions determine the Kano categorization as follows:

• Basic: Neutral for presence, Dislike for absence
• Satisfiers: Like for presence, Dislike for absence
• Delighters: Like for presence, Neutral for absence

Once the features are categorized , you can think about next release in terms of customer satisfaction. Note that there is no "right" mix. The pick of feature will vary based on market conditions and state of product development cycle 

Story points for estimation

Most of the Agile team use story points these days for estimation. In this write up I have attempted to explain about story points , when to use it and when not to use it.

What is a  story point?

Story point is a random measure for estimation used by Agile teams. This is used to determine the size of  effort required to complete the development of a user story.

Remember Story points measures size of effort and this should not be confused with person days required

A story point is usually assigned after considering following factors

• Effort required in development of story
• Complexity of story
• Unknowns or risk factors in the development

While all these may be factors for determining story points one should remember that the purpose of story point is to get an idea of the size of effort required to develop the story.

How to assign story points ?

Pick a baseline story

In the beginning team picks up a baseline story and assigns some story point to that story. Rest of the stories are assigned story points based on their comparative size with the baseline story.

Baseline could be different for different teams. For example one team can assign 5 where as other can assign 3 to the same story.  This is perfectly fine as long as same baseline is used for estimating all the stories of the backlog. Normally these baselines are fixed at organization levels so that matrix from one project can be used for planning other projects.

Planning Poker for estimation

Planning poker is among one of the popular techniques for story point estimations.  Here a team is formed for estimation. It may constitute the entire project team or some selected representative depending on project structure. It is recommended to have representation from QA and design team also while doing estimation. 

Each story is discussed and individual estimations are made for each of participants. If there are wide difference between estimators then brainstorming is done with reasoning for each estimate. After discussion re estimation is done. This process  continues for each story until estimations converge.

Use Estimation series 

Most commonly modified  form of Fibonacci series is used to assign story points. It looks like           1,2,3,5,13,40,100. 

Some teams also use powers of two, or have a scale like 1, 2, 5, 8, 20

The idea is to use a non linear scale which help in making decisions. for example its much easier to say it is more 8 than 5 to say its more 6 than 5.

How can story points be used?

This is used for relative measurement.It is used to compare user stories in a product backlog and give a long term prediction about product release.

Average Velocity of the team can be calculated based on story points completed each sprint. This average velocity can then be used for preparation of release plan .

For Example let say a development team comes up with following data during first 6 sprints :

Sprint 1 - Velocity 28 story points

Sprint 2 - Velocity 28 story points

Sprint 3 - Velocity 32 story points

Sprint 4 - Velocity 30 story points

Sprint 5 - Velocity 34 story points

Sprint 6 - Velocity 28 story points

Based on this data average velocity for this team would be : 30.

This figure can be used for assessing time required to complete items in product backlog.

One should remember that these are high level figures and efforts should also be allocated to some other standard activities while preparing release plan. Some example of the standard activities are :

• Scope for addition of new features and enhancements 
• Effort for bug fixing and re factoring
• Effort for deployment

When not to use story points?

For Sprint Planning

Story point are good tool for doing release planning , they  should not be used for sprint planning. For sprint planning each story should be broken down into required task and effort estimation should be done for each task in hours. This is important because a sprint target is commitment from the team and they should be absolutely clear on what they are committing on.

For measuring productivity of team

Using story points or ideal days to measure productivity is a bad idea because it will lead the team to gradually inflate the meaning of a point.  Team might tend to assign higher story points if   they are being evaluated on productivity as measured by the number of story points finished per iteration.

Productivity can be measured by other means like number of backlog items delivered or % of backlog items completed Vs planned

For relating story points to hours

Story points are not directly related on hours so they should not be compared.

Why use Story points vs Hours / mandays ?

Help in separation of size and productivity

The amount of time it will take to complete an item depends on factors like skill set , productivity etc.

For example consider the distance between two cities in 200 miles. It will take more time to travel if we go walking, less if we go by a car and even less if we fly using a helicopter.  While the distance between the cities is constant , the time it takes to travel vary on the means of transportation chosen. 

Similarly while the size of an backlog item is constant , time it will take to complete the item varies based on team chosen to complete the item. 

Using story points we are measuring the constant which was distance in our example. 

Takes away need to commit time  

Story point based eliminates removes commitment of time from developers. This helps them in focusing on size of problem rather than worry about making commitments.  This is especially important because during initial phases only high level requirements are known and its difficult to give exact time commitments.

Metrics for Agile Product Development

Metrics play an important part in any project. They provide data points to analyse performance and identify improvement areas . They help us study the trend so that we can assess  how we are doing.

Why Care for Metrics

• Metrics provide important feedback to the team which is important promote continuous improvement
• Metrics helps project team evolve to get maximum output 
• Metrics provide facts based on data collected and can be used for strategic decisions making
• Its impossible to optimize a process if you don't know how to measure it.

Reasons why metrics fail

• Measuring unnecessary data
• Measuring too much data
• Failure to define  a compact set of metrics that are aligned with business priorities

Business Metrics

Business metrics are focused on measuring how we are doing and how we can get better. Here are some useful hints :

• Time to market : Time taken for each feature from introduction till deployment
• Return on investment : Revenue vs Costs of production 
• Product quality : Number of post deployment defects reported
• Product Design : Number of UI related enhancement requests received 

Development Metrics

Metric	How to collect	Why Collect this metric
Mean Velocity	Average of story points completed in each sprint	Long term strategic release planning
Actual Velocity vs Mean Velocity	Actual velocity in a sprint compared to team mean velocity	Determines the deviation from average productivity
Sprint Burn Down	Starting from day one of the sprint  till end of the sprint effort  remaining after end of each day	Monitor  health of ongoing sprint
Release Burn Down	Starting from first sprint , story points remaining till present day	Monitor progress for release
Defect Density	Defects in following buckets compared to total number of defects    -  Missed Requirement -   Defect as per priority -  Code Review -   UI	Analyze the root cause of problems in development
Effort Breakdown	Breakdown of effort in following buckets vs Total Effort -  Feature Development -  Big Fixing -  Refactoring -  Enhancements	Analyze and enhance productivity of team
Product Backlog Tracking	-  Pending user stories after each sprint -  Number of new user stories added /deleted after each sprint -  Number of user stories without estimation	Monitor work completed and new requirements which are added

Critera for selecting Project Management Tool

Choosing a tool to be used for project management is very critical as this has impact on smooth project execution and productivity.  If careful analysis is not done while choosing a tool, a project team may suffer with following problems :

• Loss in productivity due to ambiguity or lack of instructions
• Problems in communication between various groups/stakeholders
• Problem in publishing targets/goals

At a high level choosing a tool is a three step process:

1. Identify problem you want to solve with the tool
2. Evaluate potential Tools available
3. Identify Best Fit 

Step 1 Identify Problem you want to solve with the tool

Following could be the reasons you are looking for a project management tool : 

• Product Road map management :  This requires:
• Keeping a list of features/ enhancements
• Ability to document requirement for each feature
• Ability to prioritize requirements and put them in development buckets
• Log defects and prioritize them

• Tasks for getting it done : This could involve

• Managing list of proof of concepts / research required to be done
• Doing competitor analysis
• Plans for items like
• Product release
• Testing
• Code Review
• User Acceptance testing
• Re factoring / Architectural improvements

• Integration with other tools
• Integration with source code management system
• Integration with build release process
• Integration with automated build and acceptance testing
• Integration with defect tracking system
• Integration with public interface for publishing product updates to end users

• Other Documentation :
• Decisions taken
• Design Guidelines 
• Code Guidelines
• Technical documents
• Business documents

Following could be the key questions:

• Search : How easy and fast is to search for required information?
• Customization:
• Do I get the flexibility to categorize and view items based on my preferences?
• Can a add new fields /item types ?
• Prioritization :What is the ease of moving items up and down?
• Flexibility:
• How easily can I add an enhancement request and schedule it for development?
• Can i maintain a hierarchy /inter dependency between items?
• Usability:
• Do I have the visibility about the stage  of development a particular feature is currently in?
• Can I have a report on open defects in my product ?
• Am I able to communicate requirement to development team efficiently?
• Is their a facility to document the comments/ discussions or queries about a feature requirement?
• Can different stakeholders customize the view to see information relevant to them?
• Are their email notification facility? Can a user update an item by sending email?
• Does it provide interface for bulk operations?
• Does it support import /export from outside source?
• How easy it is perform tasks like:
• update status
• re assign
• add comment
• change priority
• Availability : It the tool available as web interface?
• Performance : How fast can I search, add , edit?

Step 2 Evaluate potential Tools available

Once step one is done , you are clear about your objectives. You can create a comparative analysis of tools available with your specific objectives

	Tool 1	Tool 2	Tool 3
Objective 1	5	6	8
Objective 2	8	3	10
Objective 3	9	7	5
Total

Step 3 Identify Best Fit 

You can attach ratings to different objective and based on total rating decide a tool perfect for you.

Dilemma in Organizing Development team

There can be various ways of organizing a software development team

1. Vertical Organization : This approach is concept of total separation between the front end, middle tier and database layer of software development and have specialist dealing with different tiers with no overlap.
2. Horizontal Organization  : In this approach , there is no separation. Any team member can work across different layers of software. We call this generalist approach.
3. Hybrid organization : This is a mixture of 1 & 2 above, where we can have generalist to deal with simple problems and specialists to take care of complex scenarios.

There are pros and cons for each approach and what organization is chosen depends on various factors like:

• Team Size.
• How mature is architecture and coding standards.
• How smooth is communication between various team members
• How well documented your software process are
• What type of output is required
• What is the response time required
• Is the team doing software maintenance or new development
• How complex the project is

Vertical team organization

A vertical team is composed of generalists. Use cases are assigned to individuals or small groups, who then proceed to implement the use case end to end.

How this works

• There is an integrated development team responsible for all layers of architecture.
• Single development team can be divided into smaller sub teams and assigned individual targets. They take up tasks at each layer.
• There is a project lead and several module leans for leading sub teams.

Advantages

• You have smooth end-to-end development on an individual use case basis.
• Developers gain a wider range of skills.
• Ownership of modules and focus on delivery.
• Flexibility to use team members in any area as per requirement.
• Faster response time during bug fixing and while implementing simple enhancements

Disadvantages

• Generalists typically do not have the specific technical expertise required to quickly solve detailed problems.
• Subject matter experts may have to work with several groups of developers, increasing their burden.
• A focused approach at each layer is compromised if architectural standards are not well defined.
• May result in redundant code if communication is not centralized among developers.

Success factors

• Everyone is working to a common set of standards and guidelines.
• Good communication between developers is required to avoid common functionality being implemented by various teams.
• Common, and agreed to, architecture needs to be developed early in the project.

Horizontal team organization

A horizontal team is composed of specialists. This team works on several use cases simultaneously, each member working on their own aspects of the use case.

How this works

• Development team is divided in 3 sub teams namely:
• UI /Front End Team
• Middle /Business Layer Team
• Database /Back end team
• Each requirement is broken down into these three components and respective teams are responsible for their part.
• There is lead for each layer

Advantages

• A focused approach at each layer.
• Easier to maintain code quality and  discipline responsibility at each layer.

Disadvantages

• Specialists often do not appreciate the importance of other specialties, resulting in disconnects between various aspects of the project.
• Information required by "back-end" people may not be gathered by the "front-end" people.
• Project management is more difficult because of competing priorities, visions, and needs of specialists.
• More coordination required between different team layers.
• More Dependencies resulting in greater time to develop
• Lack of ownership and responsibility of a complete module.
• May result in dissatisfaction in developers as they are restricted to one area of product.

Success factors

• Good communication is required between team members so that they understand where each person is coming from.
• Defined processes and quality gates that specialists must follow to promote effective hand-off to other specialists are required.
• Very well defined requirements so that iterations between teams of various layers are minimized.

Hybrid team organization

A hybrid team is made up of both generalists and specialists. The generalists stay with a use case throughout its development, supporting and working with specialists who work on portions of several use cases.

How this works

• There is an integrated team with some team members assigned as owners for each of 3 layers.
• All the assignments are taken by a team as single module but an owner for each layer is consulted and involved in design of any new solution.
• There is a single lead and module leads for sub teams. There are leaders/owners assigned for each layer

Advantages

• You get the best of both worlds.
• External groups interact with a small group of experts.
• Specialists focus on what they are good at.
• Individual use cases are implemented consistently.
• Flexibility to choose a generalist for a simple task and associate a specialist for a complex requirement.
• Ownership of modules as well as each layer of application.
• Greater control over code quality

Disadvantages

• Specialists still may not appreciate and work well with other specialists, although this should be tempered by the generalists.

Success factors

• Good team communication is required.
• Common architecture needs to be developed.
• Common processes, standards, and guidelines must be well defined.

Comparison

Factor	Vertical	Horizontal	Hybrid
Chances to Deliver  fast	High	Low	Medium
Chance to Development fast ( New Development)	High	High	High
Chance to develop fast ( Bug fixing and enhancements)	High	Low	Medium
Chances to have high Code Quality	Medium	High	Medium
Chance of Code Reusability	Medium	High	Medium
Focus on delivery	High	Low	High
Ownership	High	Low	Medium
Ability to work independently	High	Low	Medium
Ease of operation in agile requirements	High	Low	High
Flexibility to use resource	High	Low	Medium
Ability to solve complex problems	Low	High	High