Management is an overused term that could mean almost anything. There are myriads of professions somehow aligned with management. But the general purpose of this process is to define the object of management and set goals that the object should achieve. In the case of product management, your product or part of this product is an object. Diving into a new project or during a brainstorming process on how to boost the current ones, it is crucial to have a clear understanding of what you are managing: pros and cons of the current product, the overall set of features, and product limitations. The creation of a new product is pretty fun. You have a nice idea and a clear vision. You could use brand new technologies and modern standards. According to current practices, it is more likely that a new product will contain only “must-have” features to prove the hypothesis. The team is engaged, and if you build a sufficient development process, you will successfully bring something new to the market. But after the release, the product will start to evolve. You may find that the pivot hypothesis may be incorrect, and it’s necessary to change product positioning. Or the hypothesis is fine, but you also have to develop additional features to compete or to deliver additional value. After a few years of development, a brand new product may not be as easy to comprehend as the mint version 1.0.0. Rich functionality requires a systematic approach to keep changes at bay. If you were in the beginning of the development process and you were in charge of this product during its changes, it may not be such a big thing. But what if you are a new product manager and have a task to reach new heights for old software or even relaunch the product? Proper decisions can be achieved only with a deep understanding of your object. If you want to manage something, you have to understand what you are managing and what your object consists of. If you want to manage something, you have to understand what you are managing and what your object consists of. This article covers part of the product management job and reveals a method for how to work with a mature product. It works fine for someone who is just starting a new job with a new product or someone who would like to streamline the current product. Step by step, it helps to reach an understanding of what you are managing to make your own decisions based on data. What are we doing here and why? Let's imagine a mature B2B product with a few hundred features. Every Agile sprint, the development team fixes old issues and creates brand new features. Changes must have a goal linked to the money. New features should increase customer bills.


Completion of technical debt tasks will increase product stability or security which helps to keep the product running in the long run.


We have to fix bugs, just because it demonstrates the overall product quality. New features should increase customer bills. New features should increase customer bills. Completion of technical debt tasks will increase product stability or security which helps to keep the product running in the long run. Completion of technical debt tasks will increase product stability or security which helps to keep the product running in the long run. We have to fix bugs, just because it demonstrates the overall product quality. We have to fix bugs, just because it demonstrates the overall product quality. Some parts of the product may be maintained by different teams with different development processes according to the platform or traditions. This is a large amount of input data we need to deal with. The aforementioned product bugs may lead to interesting insights. Some bugs can be a part of the stabilization process for the new features. They are not important in this topic, but still it’s necessary to analyse them if there are a lot of them during the sprint to reveal some dysfunction between product and development. But also, you may have in your backlog old production bugs from badly maintained ancient features. These bugs can appear time by time and consume a lot of money because, for example, years ago the feature was created fast and without proper engineering. Should your team fix these bugs if the feature were so badly created? Is this feature used a lot? Maybe you should reimplement it? With what other features will this feature compete? Resources are always limited, and it’s crucial to have a clear picture of your product and the cost of every part of the software. To answer all these questions, you should have a whole product decomposition, which will help to prioritise product components according to their impact on product value and show the real cost of every product decision. Form and instruments don't matter, but any type of spreadsheet is the best and easiest option. After providing this decomposition, you should have an understanding of core product features and a bunch of additional function blocks that provide direct or indirect value (the best way to express value is money).  How can we start building this decomposition? How to achieve product decomposition? A complex task for the new manager of a mature product, or someone in charge of a product where decomposition wasn’t necessary before, is to find how to start. The first thing to do is to collect all input data. The goal is to build a list of features that can be groomed later into groups of functionality. This is going to be the Feature Registry Document. Balance is necessary - the result should be detailed but maintainable. Still, it’s okay to have a few hundred features for a grown-up product. A system of filters and groups helps to navigate. The easiest way to work with data is using sheets. Also, it’s necessary to choose an instrument that can be used by any team member. Depending on the current state of a company, product, or project, it’s possible to gather these five sources for the feature registry. Because of dozens of reasons, some of them may be accessible, and some may not be. But it’s better to obtain all of the possible sources and combine the data: User documentation If any other sources are inaccessible, it is a great way to highlight the core product functionality. As usual, product documentation consists of the most used and necessary features. If there are any additional options, they may be documented in some appendices or side sections. The original structure of the product documentation is a great way to start. You may begin from the “Getting Started” section and add to the registry some basic features such as “Authentication”, “2FA authentication”, “Password restoring,” you name it. Product specifications If the product is well maintained, this is the most detailed and useful source of data. Specifications may already be separated by logical or architectural modules, which helps to reveal the product structure based on the history of software evolution. It’s better to dive into specifications after comprehending some level of the product, but later it is absolutely necessary to collect all available articles and schemes to build a management system. On the other hand, this level contains so many details that it is critical to have some filter to avoid over-detailing. User Stories or Product Backlog Items in the tracking system Sometimes they can mirror product specifications, but it's possible that during some stages of product evolution, time to market was more important than documentation, and these artefacts are the only way to find some details about a part of the functionality. They are great candidates to add to the table after adapting the titles of the items for the registry style. Product bugs or product tasks The lowest level of artefacts that requires a lot of time to analyse and find useful information. But if the product is not so big, or if there are no other sources, it’s necessary to dive into these small objects. Product itself The great source of information that could tell a story by itself. The only problem is not to miss some additional function hidden in a rarely used feature toggle. Every form can be a function. For example, we could open the user creation dialogue. That's the new feature to our registry: “User creation.” But, as usual, creation means future maintenance and all CRUD operations, so we could add functions such as “User edit,” “User deletion,” and “List of users view.” The complex sheet is fine. It’s better to work with all available data. How to build a manageable dashboard based on a complicated table? During User Story and Product Backlog Item analysis, an understanding of the product structure should be obtained. Some things are well-developed and evolving release after release. Some artefacts look like they are rarely used. The main goal of this stage is to find the product core. Any other features could be product modules. There are no useful secrets; this is a routine and creative task. Still, it is necessary to follow common sense to locate core functionality and additional domains. The results of the work will affect the whole team's strategy, so it’s better not to hurry. Depending on product size, it’s fine to establish no more than ten domains, including the core product. Some domains may be so obvious that they could consist of only one product function, and this is great. Some features may look multi-domain, and it would be hard to make a decision about them. For example, we may establish an “Integrations” domain that contains all connectors to third-party software. But imagine that one of these integrations is necessary for another domain's business process. There are a few options here: Rethink the decomposition approach. Maybe this situation happens because of the wrong idea that integration itself is something separable. Integrations made to achieve some business flow and business domains are better than architectural ones.


Make an exception for this integration if this case is completely different from others. It’s fine, but shows some incoherence in the idea and may lead to other special cases that will make the system hard to maintain and comprehend.


Establish the domain dependency to create a chain of domains that have to be maintained in the product for this function. Bad decision, but still possible. Rethink the decomposition approach. Maybe this situation happens because of the wrong idea that integration itself is something separable. Integrations made to achieve some business flow and business domains are better than architectural ones. Rethink the decomposition approach. Maybe this situation happens because of the wrong idea that integration itself is something separable. Integrations made to achieve some business flow and business domains are better than architectural ones. Make an exception for this integration if this case is completely different from others. It’s fine, but shows some incoherence in the idea and may lead to other special cases that will make the system hard to maintain and comprehend. Make an exception for this integration if this case is completely different from others. It’s fine, but shows some incoherence in the idea and may lead to other special cases that will make the system hard to maintain and comprehend. Establish the domain dependency to create a chain of domains that have to be maintained in the product for this function. Bad decision, but still possible. Establish the domain dependency to create a chain of domains that have to be maintained in the product for this function. Bad decision, but still possible. After a few iterations, all problem spots must be solved, and a final product feature registry with domain decomposition will be achieved. What to do next? The whole process of functional decomposition solves the task of onboarding into product complexity and understanding the scope. But the main insights from the master sheet will be ahead. What is the cost of each feature per year?


Does this cost consist of salaries, or do we have some third-party dependencies?


Could we switch to open source to decrease the amount of proprietary third-party dependencies? How popular and important are these features?



What are the features that generate maximum value (money), and what features do not?


Can unpopular features be removed from the product?


Could we improve the value of existing functions and make them popular? What is the cost of each feature per year?


Does this cost consist of salaries, or do we have some third-party dependencies?


Could we switch to open source to decrease the amount of proprietary third-party dependencies? How popular and important are these features? Does this cost consist of salaries, or do we have some third-party dependencies?


Could we switch to open source to decrease the amount of proprietary third-party dependencies? How popular and important are these features? Does this cost consist of salaries, or do we have some third-party dependencies? Does this cost consist of salaries, or do we have some third-party dependencies? Could we switch to open source to decrease the amount of proprietary third-party dependencies? How popular and important are these features? Could we switch to open source to decrease the amount of proprietary third-party dependencies? How popular and important are these features? What are the features that generate maximum value (money), and what features do not?


Can unpopular features be removed from the product?


Could we improve the value of existing functions and make them popular? Can unpopular features be removed from the product?


Could we improve the value of existing functions and make them popular? Can unpopular features be removed from the product? Can unpopular features be removed from the product? Could we improve the value of existing functions and make them popular? Could we improve the value of existing functions and make them popular? Answering all these questions and additional analysis helps us to switch into data-based management that may drastically improve product quality and market position. Understanding the cost of every feature in the past helps to predict and correct future estimates. All this information is a great base for discovering the true market cost of the product. Blind management leads to mistakes that can even destroy a business, so as quickly as possible, it’s necessary to reveal the details of your object and know what you are managing.

This story contains new, firsthand information uncovered by the writer.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Want Better Software? Write Less, Talk More, and Let Engineers Do Their Job

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Know Your Product: A Practical Guide to Functional Decomposition

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Developers Love to ‘Fix’ Code—Here’s Why That’s a Problem

3-Tier Software Architecture Tutorial For Non-Developers

6 Ways Business Analysts Contribute in Software Development

A Brief Introduction Into A Typical Data Science Project Life Cycle

[A Response] to the Citron Research Report on Nanox

Developers Love to ‘Fix’ Code—Here’s Why That’s a Problem

3-Tier Software Architecture Tutorial For Non-Developers

6 Ways Business Analysts Contribute in Software Development

A Brief Introduction Into A Typical Data Science Project Life Cycle

[A Response] to the Citron Research Report on Nanox

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps