Which Features and How Many Users?
You should analyze the number of users using each of the features in your product. The feature used by most users for most of the time they are in your product - is the core value of your product.
For e.g. if a majority of LinkedIn users, spend most of their time searching for jobs on LinkedIn, then that is its core value. The feature to share posts, comment on others posts may be used by a small number of users, this isn't the core value.
The intersection of what most users do most of the time is the core value, the intersection of what few users do some of the time is poor adoption. Exclude administrative features like change password, contact details, etc from this exercise.
If you plot a bar chart of features versus adoption and notice that only 1 or 2 or 3 features are being used heavily, then you're product could be open to disruption. A competitor could launch a simpler application which would focus on just those 3 features and outperform you.
The product manager has four options for features with low adoptions -
1. Kill them
2. Increase adoption (more users)
3. Increase frequency (more time)
4. Make it better
Consider Twitter's Messaging feature, it looks like something rarely used by its users. Lets analyze how the company is working on options 2 to 4 with this feature. Recently Twitter has started providing real time notifications (via messages) e.g. local trains and bus services are now providing updates on delays/cancellations through this feature.
Increase Adoption
Twitter competes with messaging apps which have a larger user base. To increase the number of users of its own messages feature it needs to somehow generate incoming traffic, through one way notifications, which would then feed into an increase in outgoing traffic or 1-to-1 communication between users.
Increase Frequency
Users could start checking for updates before they start their commute to/from work, which could spill over into checking the latest news headlines and updates from the people they follow.
Make it Better
The messaging feature is being used as a one way broadcast instead of two way communication. Twitter is educating people that the default way of messaging does not have to include responses, it could be limited to just announcements.
How is this different from tweets? Not much, yet the company is trying to position tweet timeline and messaging as two separate use cases.
When to say No
A number of times, the product manager has to say No to new features, repairs or minor changes in order to keep the focus on the roadmap.
Data Looks Good - selective data analysis, usually involving a small number of users to represent the entire universe, may point to putting in a feature but eventually it may not serve the larger user base.
Small Change, Takes a few minutes - increasing the scope of work just because its a small change isn't a sane rational. Similarly, completing an item earlier although its marked to be done at a later stage on the roadmap isn't justified by a small effort requirement. Changes in roadmap should be done but not when looking at the task backlog, these need to be separate roadmap decisions.
This customer will quit - we're not building for one customer, succumbing to a blackmailing customer leads to a product built for just that customer.
Making it optional - product features shouldn't be put in because they can be turned on or off optionally, complexity in development remains even if the feature is disabled and needs to be managed in subsequent releases.
Nothing else is planned - if the roadmap has a hole, don't fill it up by doing unnecessary additions, rather spend time clearing the technical debt.
Competition has it - doesn't mean they have a great product or that they are on the right path. Don't let your competition define the battle.
When to say Yes
Any feature or change to a product should qualify on a majority of the following arguments.
Fits the vision - the product vision and the company vision define if any proposed change/feature fits. External experts/media may demand that a company provide feature xxx in their product, but that doesn't mean they are right, if it doesn't fit the vision it doesn't go in.
Who benefits from it - if a request comes in multiple times in a short span of time, its usually thought that this is what all the customers want. There is a 'fre-cently' bias to things heard frequently and recently. Don't fall in this trap.
Does it improve or complement an existing flow - think about increasing adoption and frequency.
Can we support the increase in usage - if the new feature becomes successful, do you have the resources to support growth in users and usage? Don't launch something you can't support, otherwise it will end up being a failure.
You should analyze the number of users using each of the features in your product. The feature used by most users for most of the time they are in your product - is the core value of your product.
For e.g. if a majority of LinkedIn users, spend most of their time searching for jobs on LinkedIn, then that is its core value. The feature to share posts, comment on others posts may be used by a small number of users, this isn't the core value.
The intersection of what most users do most of the time is the core value, the intersection of what few users do some of the time is poor adoption. Exclude administrative features like change password, contact details, etc from this exercise.
If you plot a bar chart of features versus adoption and notice that only 1 or 2 or 3 features are being used heavily, then you're product could be open to disruption. A competitor could launch a simpler application which would focus on just those 3 features and outperform you.
The product manager has four options for features with low adoptions -
1. Kill them
2. Increase adoption (more users)
3. Increase frequency (more time)
4. Make it better
Consider Twitter's Messaging feature, it looks like something rarely used by its users. Lets analyze how the company is working on options 2 to 4 with this feature. Recently Twitter has started providing real time notifications (via messages) e.g. local trains and bus services are now providing updates on delays/cancellations through this feature.
Increase Adoption
Twitter competes with messaging apps which have a larger user base. To increase the number of users of its own messages feature it needs to somehow generate incoming traffic, through one way notifications, which would then feed into an increase in outgoing traffic or 1-to-1 communication between users.
Increase Frequency
Users could start checking for updates before they start their commute to/from work, which could spill over into checking the latest news headlines and updates from the people they follow.
Make it Better
The messaging feature is being used as a one way broadcast instead of two way communication. Twitter is educating people that the default way of messaging does not have to include responses, it could be limited to just announcements.
How is this different from tweets? Not much, yet the company is trying to position tweet timeline and messaging as two separate use cases.
When to say No
A number of times, the product manager has to say No to new features, repairs or minor changes in order to keep the focus on the roadmap.
Data Looks Good - selective data analysis, usually involving a small number of users to represent the entire universe, may point to putting in a feature but eventually it may not serve the larger user base.
Small Change, Takes a few minutes - increasing the scope of work just because its a small change isn't a sane rational. Similarly, completing an item earlier although its marked to be done at a later stage on the roadmap isn't justified by a small effort requirement. Changes in roadmap should be done but not when looking at the task backlog, these need to be separate roadmap decisions.
This customer will quit - we're not building for one customer, succumbing to a blackmailing customer leads to a product built for just that customer.
Making it optional - product features shouldn't be put in because they can be turned on or off optionally, complexity in development remains even if the feature is disabled and needs to be managed in subsequent releases.
Nothing else is planned - if the roadmap has a hole, don't fill it up by doing unnecessary additions, rather spend time clearing the technical debt.
Competition has it - doesn't mean they have a great product or that they are on the right path. Don't let your competition define the battle.
When to say Yes
Any feature or change to a product should qualify on a majority of the following arguments.
Fits the vision - the product vision and the company vision define if any proposed change/feature fits. External experts/media may demand that a company provide feature xxx in their product, but that doesn't mean they are right, if it doesn't fit the vision it doesn't go in.
Who benefits from it - if a request comes in multiple times in a short span of time, its usually thought that this is what all the customers want. There is a 'fre-cently' bias to things heard frequently and recently. Don't fall in this trap.
Does it improve or complement an existing flow - think about increasing adoption and frequency.
Can we support the increase in usage - if the new feature becomes successful, do you have the resources to support growth in users and usage? Don't launch something you can't support, otherwise it will end up being a failure.
