Product Expert - Missing Role

I don't usually like to write about process and organization, but I am going to now. The primary reason is because the efficiency of a programming team primarily comes from roles outside that team. What I mean by this is that everyone agrees that you need engineers to produce a software product, but the other roles can seem less critical. And what happens is that the engineers take on the roles of product management, UI designers, release engineers, infrastructure specialists, and so on. This makes engineers less efficient at engineering because they spend their time doing things they may or may not be good at. It should be noted that most engineers are particularly bad at product management.

So when you have the other roles filled with strong people it not only takes work from the engineers, but gives them direction and support and allows them to work very quickly. Now I am a believer in Agile and trying stuff that may or may not work out, but direction and focus from outside the engineering team is still key.

All the above it pretty obvious. The part I wanted to mention is a new role that I think should be added to every product over maybe two to three years old. Product expert. It has been my experience in multiple companies that there is a lack of people who know what the product does. Sure, everyone can give a rough outline of how to use the product, but no one can tell you every piece of functionality. When I worked at Brainshark I went to a senior QA engineer and asked her if she describe a walk through every piece of functionality of the product. The answer was an unequivocal no. Now she was a manual tester who kept good notes and had worked there for over 8 years. She did not know the full extent of what the product did and no one had that knowledge. In the organization there was no person who had a full grasp of what the product was. This is not a Brainshark only thing. This is endemic. Companies engineering groups produce product, but quickly lose grasp on the functionality of what they had built.

One of my current engineering tasks is to figure out what our product does. This is a role that I am not particular well suited for. So the solution seems simple. You create the role, "Product Expert". The Product Expert is part of Product Management but is more focused on already delivered functionality over functionality that will be delivered in the future. Their job is to study the product and understand everything it does. They should have the ability to define requirements for the product that exists such that an engineering team could take those requirements and rebuild the product.

Now, maybe you might say, "Hey, I will just write out documentation". Well, a living human being encapsulating, processing, and distributing knowledge is massively more effective than a handful of documents that may or not be complete. You might think that people with this knowledge already exist in your organization, maybe in your support staff, but I have not seen people who have this knowledge and are able to support the many parts of an organization that need this knowledge.

So my advice for people running software companies is once your product is two years old you hire some kid out of college and tell them they are to become a product expert. They are to learn every behavior of the system. They should be generating documentation and even training or tutorials. They are to act as support for both engineering, support, and product management. Their career growth will probably be towards product management.