Product Knowledge Management

 

In Product Development, Management, and Ownership, I mentioned that a comprehensive understanding of how the software currently works is essential for a product manager to drive the evolution of the software required to address changes to the customer's needs and expectations.

​

In the past, product managers used to create comprehensive specifications for the software they needed to have developed.  From these specifications, the developers would create development or technical specifications and the testers would create test specifications.  However, the problem with these types of specifications was that they would be regarded as one-off documents and would eventually become outdated.  New versions of the software would see new specifications created, or at the very least, new versions of the specifications.

 

However, this would quickly become unmanageable as products evolve with small changes here and there over time.  What is needed today is living documentation.  Product documentation that is always current and one-off documents are no longer adequate for this.  Instead, we need a product knowledge base that is intentionally managed and kept current.

​

With the complexity of modern software, such a product knowledge base also needs to capture who the stakeholders are for each of the product's capabilities.  Stakeholders are those people who have expectations of specific capabilities of the product to whom we must listen and who therefore have the authority to tell us how the product should behave.  For example, the head of the Finance department may have specific expectations of the financial capabilities and a certain individual in Finance may be the expert who tells us how tax amortization should be calculated.  Someone in legal may be the expert who tells us how the product should behave with regards to privacy concerns or contractual obligations.

​

In other words, not only should the product knowledge base contain specifications for how the product currently behaves, but it should also allow us to know who the stakeholders/experts are who provide this information.

​

Additionally, there are relationships such as dependencies, inclusions, etc., that are important to document.  For instance, different sales portals might all be dependent on the same user account capability, which means that a change to the user account capability might impact all the sales portals and may require changes to some or all of the portals as well.  Without understanding such relationships and whom to speak with, changes can easily result in defects and even in major business risks that could lead to massive financial losses.

​

In complex software solutions, some individual capabilities may require dedicated product managers whom I prefer to call Capability Managers.  These capability managers are responsible for keeping the knowledge base current for their capabilities, which means they are responsible for obtaining this information from all their relevant stakeholders.

 

I have found that the use of Behavior-Driven Development (BDD) and Behavior-Based Analysis and Design (BBAD) is perfect for this responsibility and results in precise and unambiguous product specifications for such a knowledge base.

​

I've created such product knowledge bases at companies like AT&T, Fannie Mae, and Fujitsu.

​​

I've trained and coached people to create and manage such product knowledge bases at the following companies:

• AT&T/DirecTV

• Core Digital Media

• EBSCO

• Expeditors

• Expedia

• Fannie Mae

• Fujitsu

• Microsoft

• MuleSoft

• Premera Blue Cross