It didn’t take too long until I realised that most of my time was consumed by meetings, emails, internal discussion and communicating with key stakeholders. Having tried some tactics to boost my productivity, namely time-boxing and standard operation process, I still end up spending too much time and effort finishing documentation at the end of the day. In my previous post, I used to mention the importance of documentation and there is no doubt that it’s one of the core and most fundamental skillsets a professional product manager must have. As for most-used document types, product requirements documents (PRD), product roadmaps, user flow diagram, product wireframe, product strategy and competitive analysis, OKRs and release notes. Surely, documentation is part of our daily job, we wouldn’t want to spend too much time on maintaining it or let it cannibalise our attention to job responsibilities.
Luckily, for each type of document, there are a bunch of tools out there automating the process and making our life easier by avoiding dull, repetitive and less creative work. These tools, targeting the stage of operation procedures, provide a wealth of templates, pre-defined tasks as well activities, and other customisable elements for product managers to create, maintain, and manage the documentation processes. While taking advantage of automated processes thanks to these creative tools, we also need to bear in mind that these tools are designed to help streamline our daily tasks, make it easier for cross-functional communication and support timely execution. We shouldn’t fall into a trap of over-reliance on these tools. Upon the adoption of documentation tools, below are a few tips you should consider in order to work on your documentation more efficiently.
1. Keep diversified document types and choose the one that fits communication needs
Document types vary from a word file of requirements specification to a screenshot of a whiteboard containing agreements reached in a key stakeholder meeting. That’s why a growing number of documenting tools have supported uploading various types of documents and even offer the function to scan and recognise the content in the uploaded file then covert the file into a different format or extract the content from the file and put them into a pre-defined template. In this way, product managers don’t have to worry about “translating” the notes into a “common language” that developers and designers should understand when communicating requirements with the development team. Instead, we only need to choose the most appropriate documenting format that is easy to share, understand, communicate and retrieve. Let the tools do the hard work and make it fit into the templates created within the tools.
On the other hand, depending on the purpose of documentation, the document types also vary. For instance, product requirements specification would be a word file or a presentation containing text and charts about the description of the objectives, product features, user flow and release notes. whereas product wireframe and design prototype are high fidelity images. If it’s a demo session or a release meeting, it’s better to use video recording. No matter which format you choose, the key is to help you build a shared understanding of the outcome among your team and make it easy for you to store, change and retrieve the information.
2. Maintain a strict change control process in the documentation and stick with it
Compared with the Predictive development approach and the Waterfall development method, in the Agile delivery process, activities are divided into iterations with deliverables so the tasks are performed iteratively. As the requirements are not fully clearly defined, the feedback, reviews and changes to the requirements are fairly ad hoc and informal. With the change requests mounted, so the documentation. Product managers should build up a standard change control process to ensure the requests are reflected in documentation and shared with the team immediately. If the changelogs are not documented and shared in time, the version control problem could be triggered and it’s quite hard to trace the changes, which will hurt the quality of deliverables and delay the delivery process. As a result of this, the documentation no longer serves its’ own purpose of recording information, informing and communicating messages or making team accountable for their tasks.
3. Do minimum, focus on essentials
Some product managers may spend quite a while managing and maintaining documents in good “condition” as much as they can. If you are a junior product manager only working in the industry for one or two years, I would agree that taking time to polish your documentation skill in terms of formatting documents and way of presenting necessitates your professionalism. However, we should always bear in mind that to get documentation right, the purpose of documentation, the users of documents, the right amount of process, changes to the requirements and liabilities (e.g. legal dictates) should be considered first. Additionally, using the framework (e.g. PRD framework) and principles (e.g. SMART principles) would make the documentation more effective and precise. Don’t be obsessed with document format or overuse of documentation.
Originally published at http://chrissylovesmarketing.com on February 20, 2021.
