In my last article, I introduced the concept of specification disconnect — when the way a product specification document is perceived doesn’t match up with how it was actually documented. In short, somebody may think feature A looks like X, while another thinks it looks more like Y.
This concept is something that every product manager faces as specifications evolve from words to finished product. In a world where everybody writes and reads things slightly differently, this is bound to occur.
Spec disconnect happens through a seemingly limitless number of ways, from misinterpreted words to a lack of clarity around future requirements. As Product Managers, we should be concerned about perception issues within our documentation — for good reason.
Why? Teams can end up lacking a clear and consistent vision for what they are working towards. Features may end up incomplete or misinterpreted. Smaller details have been created without the end-goals in mind. Work needs to be re-completed. Teams become frustrated at the need to go back over their work, when they could’ve done it right the first time. Political issues begin to arise. At the end of all of this, you could end up late to market as a result.
I’m a big believer in reducing perception differences in product and software teams. Nobody wants an unhappy team or a late product. Here’s my take on how it can be reduced.
1 — Use more than just words to craft your specs.
Words make up the majority of various documentation types, but they are only one medium available to use. Using different mediums can reduce the reliance on words, which are prone to misinterpretation. Mock-ups, prototypes, diagrams and whiteboard sessions are great ways to help keep perceptions in check. Be sure to capture these and keep them within your documentation.
2 — Don’t let your requirements document remain static
A static document cuts off the ability for members of your team to ask questions and provide input. Throughout the product development processes, it is only natural that your team will ask questions that could be of use to the entire team. Consider using mediums that allow two-way communication and maintain the integrity of the documentation. Examples of this could include questions/answers board alongside documentation with the ability to import into documentation if they’re deemed relevant or a comments section that allow people to ask questions.
3 — Encourage open and honest dialog throughout your team.
Many people don’t ask questions in public forums for a range of reasons, such as feeling embarrassed they may come off as not smart enough or worried about seeming incompetent at their job. The reality is, nobody knows everything — but different people have different strengths, and bringing a group of such people together means ending up with a group of many strengths. Questions are the natural way to get this knowledge out from one another, and build everybody’s individual knowledge. Achieving open honest communication channels is difficult to achieve, but with sponsorship from senior managers, can be achieved. The transfer of knowledge between members is key to ensure everybody’s strengths are used, and everybody is on the same page about what needs to be achieved.
4 — Constantly check your progress through periodic scrums.
This may seem an obvious part of Agile for some readers, but scrums are important because they give you a regular chance to “judge” the perceptions of your team. You will quickly be able to tell if certain members of your team have misinterpreted items, or are on the wrong track. Whether you run scrums daily or not, check in with your team regularly to keep the ship on course.
5 — Make sure your team knows the bigger picture.
Building something that suits the requirements of version 1 is often very different to building with version 5 requirements in mind. Building a product riddled with technical debt is a great example of this. Your team needs to be constantly aware of the bigger picture and the product’s northern star to ensure you are all on the same page. While factors such as timelines and costs may come into play, there is really no excuse for a team to not know clearly what they are working towards. A team with a product’s end game clearly in mind helps ensure end-user’s needs are met and products are built the right way from the ground up.
If you enjoyed this read, please tap the clap! Your support is appreciated.