What is a Taxonomy?

From dictionary.com

taxonomy
[tak-son-uh-mee]
noun, plural taxonomies.

1. the science or technique of classification.
2. a classification into ordered categories: a proposed taxonomy of educational objectives.

Classification of elements of any collective is an important aspect of human need. It helps us make better sense of our world, while its original use may have been in biology, development of a Taxonomy is a standard tool in most professions.

In Project Management, for example, SEI has published a Taxonomy of Risks within a software project.

A Taxonomy can help ensure that we at any given time try to look at the complete picture and not miss any elements. The top-level classification for Software Risks categories as per SEI’s Taxonomy are;

1. Product Engineering Risk
2. Development Environment Risk
3. Program Constrain Risks

These 3 are then further divided in sub categories of risks. This ensures that whenever you are looking at identifying risks for your Software Project, if you cover each on of these, you would have not missed any category or source of risk(though you may still fail to identify all the risks within that category).

Product Context

Coming to product development, is there a Taxonomy that can help us classify every type of product requirement?

Product requirements taxonomies of course already exist. The BABOK® (Business Analysis Body of Knowledge, published by www.IIBA.Org ) elaborates a Taxonomy. A simple break-up into functional and non-functional requirements is a useful and basic classification. There are several other models, like Kano’s, that helps Prioritize the product requirements.

However, in my own journey in trying to build products (3 to be precise, and without success) I have my own learning.

Trying to balance all the development needs of a product in terms of new ideas both user visible features as well as the non-visible aspects of the product, that needs to be built (therefore time and money need to be allocated) along with other ongoing changes just to keep the product current, I have come up with my own Taxonomy.

I remember a long time back in early 2000, the great management guru Michael Porter was in Mumbai and a reporter asked him, how internet will impact business. His answer was short and crisp ‘The basic of any business is Revenue minus Cost equals Profit. That will not change no matter how you do business”. That sentence has always remained with me. Simple yet easily forgotten fundamental of business.

A New Taxonomy for Product Development

The Key labels for my Product’s Requirements Taxonomy come from the immutable law of business:

A business is for Profit and Profit is Revenue minus Cost.

Here we will stretch our definitions a bit, profit would mean all benefits, tangible in money terms or intangible and revenue would mean not just the money earned through sales of the product, but total adoption, both in terms of number of users and the amount of time spent by the user. This extension of the definition of revenue and profit is needed to accommodate the success of software products whose success is determined by the number of users, who do not necessarily pay for the product. Higher usage subsequently translates into higher revenue through other revenue models, be it data insights or advertising on the platform.

Even in the non-software product like a Car or a Tractor, it needs to be seen in terms of not just how many are sold, but once bought how much are they used. Can a feature be added in the tractor so that a farmer can use it for multiple purposes and thereby engage the machine for longer number of hours in a season.

The purpose of any product owner would be to increase profit through the product.

So, any effort spent on the Product has to either Increase Revenue or Decrease Cost.

That is the universal principle of any business endeavor. As I have already mentioned, the same model applies to Not-For-Profit endeavor, you would try to increase product adoption instead of counting the direct revenue from sales. So social projects under taken in rural areas would need to look at product requirements and design from the same point of view: How to improve adoption? There is no point creating a product, even if free, that does not get adopted by the intended end-users.

Kap’s 14 – Product Requirements Taxonomy

The above classification could be used by Project Managers, Business Analysts, Scrum Masters, Agile Practitioners etc., while collecting requirements by identifying and understanding all relevant stakeholders and using suitable methods like brainstorming, user interviews, competitor’s product review etc.

The requirements then need to be prioritized based on Value at Stake and Urgency. This Taxonomy classifies the ‘requirements’ from the point of view of what needs to be built into the product, from the Improve Profit/Adoption point of view rather than the traditional Functional and Non- Functional. It also accounts for effort that needs to be spent on aspects of the product that is not adequately covered in other classification models like Kano or MoSCoW (Must, Should, Could, Won’t).

1. Customer / Market Feedback

This is self-evident. Listen to the customer. No matter how much thinking and designing goes into a product, the end-user would always have a view that may surprise you. Listen to the what the customer wants, especially what the end-user of the product is specifically asking for.

2. Benchmark / Competitive Necessity

This is the standard set of features and performance that a product of a particular grade is expected to have.

3. Operational Necessity

Customer doesn’t ask for it, but the product just cannot be used unless this feature has been built. The operational necessity is from the point of end user using the product. In a way this maps to the part of ‘Minimum Viable Product’ definition from the usability point of view. A typical example would be ‘Password reset’ feature in a website.

4. Response to Risk

This includes all security and safety features. Some of these features would not even be visible to the end-user, however they have to be designed and implemented in the product.

5. Legal / Regulatory

Be it a car or banking, e-commerce or social networking website. There are always going to be legal/regulatory aspects that need to be built in the product. These include changes that are needed when government policies change.

6. Technology Catch-Up

As technology matures, certain changes will be needed in a product even if you are not an early adopter. After a certain time, the technology will have to be adopted. The technology adoption may not change the features or functions of the product. The key point here is that it is not possible to now postpone taking up these changes. Example of these include, moving from RDMS to NO-SQL databases for certain use. Also, change in system software version may also necessitate product change. Compatibility with new versions of browser, operating systems or form factors etc. all fall in this category of change.

7. Customer / Market Demand

This is the basic use-case on which a product is premised. Some Market need that you intend to fulfill Faster-Cheaper-Better.

8. New Innovation / Bets

This is different from Market Demand. Where no evident demand already exists, however new innovative features and services that you may want to test in the market. New markets get created by such innovation. People like Steve Jobs are legendary for creating products and a whole new market that didn’t exist till that point.

9. Improve Offering / Customer Experience

Features that you may already be providing but need a re-look to improve the overall experience of the customer. It could be the look and feel or a new layout or change in underlying technology.

10. New Technology Adoption

Entrepreneurs will keep pushing the boundaries and keep adopting new technologies into the products. It may serve the same feature and function but done with completely new technology. This is where you are at cutting or bleeding edge. This is different than the Technology Catch-up as the risk, need, urgency and cost-benefit analysis is very different. Classic examples include moving not only from Film to Digital platform, but within the digital platform moving from CCD(Charged Couple Devices) to CMOS(Complimentary Metal Oxide Semiconductor) based chips.

This distinction between New Technology Adoption and Technology Catch-up is primarily where on the Technology Hype Cycle you catch it.

11. Marketing / Publicity / Networking Necessity

This is often not explicitly understood as a separate requirement. This is purely the effort that will need to be put to modify the product to help ‘Market’ the product better. The end-user doesn’t drive any additional benefit, but this feature is needed for improving the marketability of the product. In online products, this would mean a ‘Tell a Friend’ feature. Also, you may need to build analytics to understand which market segment your product is doing well, so that you can identify your Target Group better. In traditional products, it usually means a different packaging or visual design for higher visibility of the product in the retail store or simply how it is stacked in a retail store or stored in warehouse. This should not be confused with ‘Minimal Marketable Product’.

12. Remodel / Re-Engineer Platform

A products platform may finally need to be re-engineered to improve the overall design and make it more efficient. This change may have got postponed due to basic need to get the product out early, but sooner or later requires attention. Also, due to constant minor enhancements the product(especially software) may have become unwieldy and now may need a clean-up for improved maintainability. This is not to be confused with change in technology.

13. Change Service Provider / Interfaces

A product may be using third party services. Example in software products could be say a ‘instant notification’ service provider. While it may be cost effective initially, it may require you to change to a different service provider or build the capability in-house or within the product.

14. Operational Efficiency

Products need changes to improve overall operational efficiency. Example the back-end process for handling returns in an e-commerce platform or site terms violation detection process for a social media platform.

Money and Time

The Value at Stake or the Money associated with any requirement, needs to be seen along with Time. Each requirement would need to be evaluated through Cost-Benefit/ROI analysis. It can then be plotted on a simple 2-dimensional graph. This can help understand where these requirements are relative to each other, on these two parameters, and therefore help in prioritizing.

This Taxonomy understands the dynamic nature of product in today’s fast changing world i.e. it is based on the premise that no Product is final and a Product will need to constantly evolve.

The Product Road Map’s Diamond Route

Diamond Route

As a product owner you would prioritize and move from HVI followed by HVL/LVI followed by LVL. Between HVL and LVI, the requirement that is more likely to move to HVI would perhaps demand higher priority.

The requirements themselves will move in the opposite direction.

A requirement that is ‘Later’ in urgency, with time will become ‘Immediate’ and a requirement that was ‘Low’ in value could move to ‘High’ with time.

Finally, the broad classification in terms of ‘Increase/Sustain Revenue’ and ‘Reduce Cost’ is as open a classification as ‘Bosons & Fermions’ in particle physics. All fundamental particles which have been found and those that are yet to be discovered have to be classified as either Bosons or Fermions.

If a 15^th Type of Requirement needs to be added, it will ultimately have to either ‘Increase/Sustain Revenue’ or ‘Reduce Cost’.

 

Main Image Courtesy Natalia Y
Download free do whatever you want high-resolution photos from Natalia Y