3 Reasons Why Product Management Can Fail

Tomorrow (Tue, May 18) there's an excellent chance to hear one of the best bloggers and practitioners on the topic of Product Management - Steve Johnson of Pragmatic Marketing is giving a talk to the Cambridge Product Management Group.

The Pragmatic Marketing Framework is a design classic, and mandatory reading for anyone in the field.

Much of my work has been in a Product Manager role even though I didn't always have that title at the time. In the high-tech and semiconductor sector, it was often a simple split between Marketing (the people who set up tradeshows and talk to customers) and Project Managers (the engineers who get the product out on time). Smart readers know this conflates Product Marketing and Product Management. Really smart ones will see the slip in terminology between Project and Product Management. There is a difference between the three titles, and the Pragmatic Marketing website will answer all questions.

Thinking about tomorrow's event made me consider what makes Product Management so difficult and frequently prone to failure?

My inclination is that there are 3 basic problems that make even good intentions into the paving stones leading to Product Hell.

1. Lack of a product workspace containing technical and commercial documentation makes it difficult or impossible for new joiners to become familiar with the product. Before you know it, the old issue of "knowledge is power" raises its head. Or, "Scientia potentia est", if you want to be fancy. Gaps appear in product documentation, and this usually means a shortfall in marketing collateral when it is most needed.
2. Lack of a standard process or workflow causes product decisions to be made in an ad hoc way. At best, it is inefficent as good practices have to be re-discovered. At worst, product decision-making quality varies between instances.
3. Release fragmentation leading to / caused by customer variants makes for a configuration management nightmare. Bringing all the customer versions back into one main branch or trunk build can make publishing a future roadmap very hard to achieve.

For the past 10 years, the solution to these problems for me has been to use CogniDox. Here are a couple of illustrated examples of ways that CogniDox has helped me and other Product Managers / Project Managers have an easier time of it.

The first example is creating a category or workspace for all documents relevant to the project or product release. This can have as many sub-categories as needed, as long as the core requirement is met - a logical place to start when you want to navigate through the product documents.

There's nothing revolutionary about this, but the number of companies I encounter who don't have a structured, common repository for product documents means I have to mention it. The example above illustrates how the category contains everything - software release packages included - that will go into the release.

The second example is something we call a "document holder" in CogniDox. It's a type of document written in XML that has placeholders for other documents. Other documents can be any file format, including video tutorials if you want.

As you can see, the web page view (icon on the left) is automatically created from the XML file (icon on the right).It's especially helpful because it ensures that the document actually exists, and/or makes sure that correct process is followed e.g. you can't release a draft version, it has to be issued and approved.

What we've tended to do is create a document holder that reflects the structure and contents of the category, because an important point is that we can release the document holder as a deliverable to customers. It will help them understand the product's structure.

When a user from a customer company logs into the customer web portal access that we provide as part of standard CogniDox, they see the product documents that the Product Manager has licensed to them.

If we create one of these per product release or release variant, we know that the licensing manager module in CogniDox will automatically ensure that users only see what we have licensed them to see. There's less danger that the product variants will cause us to make an error of including a file we shouldn't, or leaving out something critical and looking quite unprofessional as a result.

When we start a new project or release, we can copy the category structure from a similar product that we know worked well. Best practices start to become reinforced without any need for heavy-handed mandates.

The next example that I want to cover is the use of Reports to help a Product (or Project) Manager understand the product status. These reports provide a unfied console to assess projects in the pre-release process. If I have a Gate 1 milestone next week and we have collectively agreed that twenty documents will be prepared in support of it, then I can see at a glance how many have been uploaded, reviewed, issued and approved. It saves valuable time at the Gate review meeting itself.

CogniDox tools have been critical to me and others as we make Product releases, and have become as essential as our software code version control or bug tracking systems.