Documenting Your Product – Part 5 – Sharing and collaboration
This is the fifth in a series of posts about documenting technology product builds. If you missed the intro, Part 1 – Use Cases, Part 2 – Requirements, Part 3 – Sequence Diagrams or Part 4 – Data Models go check them out. At the end of this series, I’ll be providing a bunch of templates and resources to make this process more manageable.
For this series, we’re building a product called PetSitPro, which matches pet sitters with pets in need of pet sitting. As a refresher, a Pet Sitter is someone who provides pet care, and a Pet Parent is someone who has a pet to take care of.
In this post we’re going to talk about how you share all of this work you’re creating with the rest of your team effectively. While this may seem like an obvious thing, putting processes in place for collaboration is critical to the success of this stage of your product development. Let’s dig in.
The “How” of Sharing
There are a few key components to sharing your documentation as you go through your product’s development.
- Others have to be able to comment on what you’re creating
- Ideally you’re able to assign tasks right in the documentation for others to address specifically
- The documents should be visible to everyone on the team, regardless of their perceived relevance to the topic
I use Google Drive for all of my documentation because, even though it’s not the world’s greatest document creation tool, it’s great for sharing and collaboration. I’ve not used Office 365 nearly as much so it may be just as good. If you have, please leave a comment in this post with your tips and tricks.
The Process of Sharing
Here’s how I typically bring the rest of the team into the process of product documentation.
- Create a template that you use for all of your product documentation (I’ll share mine at the end of this series)
- Take the first cut of creating the document yourself. As the product owner, it’s important to get all of your thoughts and ideas out of your head as the starting point
- Once you’ve gone a few rounds and feel really good about painting a reasonably complete picture, invite everyone on the team to dive in
- Others input should take the form of Comments or Suggestions, not direct editing of the document. This allows you to keep the document orderly and allows for conversation about a topic before it gets formally changed in the doc. Same with suggestions
- Put a time boundary on gathering comments and feedback. “I need your comments on this revision no later than end of day Wednesday.”
What you’re after is timely and vigorous debate on what’s been created. Repeat this process as much as you need to in order to get to a completed document. I find that typically 2-3 rounds with an active team is more than enough to get to a solid document.
If your team is not jumping into this process, you have either created an environment where people are scared to share their opinions or you have the wrong people on the team. Spending 15-30 mins reviewing something as important as product design documentation by anyone on your team should be a given. Either way, you need to fix it asap.
In our upcoming (and last) post in this series, we’ll talk about system component design and perhaps a bit of pseudo code creation. I’ll also be sharing out the links to artifacts and examples you can use going forward. This has been a pretty long and involved series. Thanks for hanging in there.
A New Series!
Also, I’m starting a new series that you might be interested in. I’m writing a brief blurb about all of the books I’ve read over the years. It’s been something I’ve wanted to do for a long time and I’m finally under way. If you’ve enjoyed any of my book recommendations over the years, this should be a treasure trove of goodies going forward. These book reviews will not show up in the regular subscription to this blog, as there’s likely to be a lot of posts. I may create a separate feed at some point, but for now you can just go to Books off the main menu of the site.