Software Product Documentation – Wasted efforts?
I just completed a quick consulting assignment with a company back in the East Coast. It was a Oracle E-Business Suite Implementation and specifically implementing one of the products (Oracle Procurement Contracts) that I managed and had a big role in building while at Oracle.
It was one of those interesting cases of implementations. Unknowingly or led by circumstances the client had embarked on a implementation project where they had chosen a product that they thought meets their needs only to realize there were gaping holes in the implementation strategy. I cannot seriously blame the client for taking the route they took. They had two or maybe three products within the same product suite all which could fit the bill to varying degrees. And I am not talking about Oracle E-Business Suite, PeopleSoft, JD Edwards. These are products all within Oracle E-Business Suite. So naturally it was easy to get misled. Going with the product they did, they were confronted with the proverbial “this product does not meet our needs so we will need to customize” dilemma. And that is when I got involved with this project.
With the goal of least customization and identifying the best fit product, I started analyzing their need. As I understood their need better and started mapping it to the products that were available, one thing became very apparent. The documentation that came with the product was not in any way guiding the customers in making the best choice. To be fair they do not claim to purport that. TheUsers Guide and Implementation Guide never got into the scenarios customers typically have. Instead they are designed to give information on what the product does and leave the customers to their own wits to figure out how to adapt it to their businesses. I have never been a believer in the usefulness of software product documentation. In my opinion it(the product documentation) is something product companies do because they have to, for every product every release. There is scant attention paid to their utility and neither is there any feedback loop to adjust it to meet the requirements. Considering the flux in product footprint thanks to all the patches, updates, the manuals released by product companies quickly get outdated. More importantly, despite the edict of RTFM, I don’t know of many who actually read the manuals or have the time to read those large documents.
Now having said that, what could a software product company do better cater to the needs of their customers?
Here are 5 strategies to adopt to provide useful product usage and implementation information – coming from real life cases.
- The software companies should voluntarily create knowledge based communities around the product and use that to share the product information and foster knowledge sharing amongst customers to share their experiences. Collectively all the contributors stand to benefit from this crowd-sourced effort.
- These communities should have focused knowledge bases for areas like Product Training, implementation strategies, industry specific best practices, Day-in-a-life of a user narrations. Most companies consider their job done by just throwing a Q&A forum with absolutely no involvement from Product teams.
- Conduct periodic web-based Open Houses for Products where new customers can listen and discuss things with the product teams. This will help customers get to hear from horse’s mouth and not just from some over-zealous me-too system integrator claiming expertise.
- Provide opportunities for “Review-with-the-Product Team” sessions with the product where clients can review their would-be implementation strategies with the product team to ensure they are not pursuing a wrong path.
- Maintain and Manage a product specific wiki for product documentation and have customers, System Integrators, consultants update it and keep it up to date with the product usage and administration information.
Would love to hear other ideas in this area that has worked for your product companies.
All in all I was happy that I ended up helping customer from realizing all the benefits of a product we thought it would provide and did it while not needing elaborate customization or taking a work around.