Collaboration is the Shock Absorber for Inadequate Documentation

Jonathan Velasquez

In the product development lifecycle, there comes a point in time when we must write down what is needed. We refer to this documentation by a variety of names:

• Requirements
• User stories
• Feature lists
• Use cases
• Design specifications
• Supplemental specifications
• Success criteria

These artifacts represent our attempt to completely capture what the user needs. We fill out forms and declare that our work at capturing what is needed is complete. Milestone achieved. Check the box. Move forward in building the product.

Not so fast. Documentation by itself is inadequate.

It is in adequate because it represents a one-size-fits-all approach for connecting what is needed to the person or team who will be responsible for designing and building it.

A sage friend of mine recently opined, "It is a rare person who can look at a list of requirements and fully understand the context of the user."

Think about how commonplace it is to misunderstand someone else's words or intentions in our daily lives and interactions with people. This reality is also true in the world of product design and development.

Thus, the necessity of collaborative conversation reintroduces itself into our product management reality. When solution designers and architects begin to consume these documents, they rarely seek more specificity, Rather, they almost always seek increased understanding and clarity regarding the context of the person experiencing the problem.

That clarity comes most efficiently and effectively through collaborative dialog, a series of questions raised by designers and architects who have consumed the documentation and the people who have the answers. Only when an adequate level of understanding is obtained can they proceed with confidence with their product design and development activities.

By way of example, Scrum (the agile development framework) recognizes that a critical function that a Product Owner performs is to answer questions that Developers have regarding user stories. In other words, Scrum assumes that it is normal for requirements to not be fully understood by those who read them.

The handoff between those writing documentation of needs and those consuming them represents a predictable speed bump in the process of designing and developing solutions. The shock absorber that is best suited to absorb that bump is a collaborative conversation between those in the know and those who need to know in order to proceed.