Do you find yourself not being sure exactly what it is that was agreed to at the last Product Review meeting? Do you find yourself thinking you are right about what the feature changes are and wondering why the others remember it all so differently? As a Product Owner, do you find that what was built is not what you thought you said you wanted? Do you find yourself delivering a product where people are scratching their heads about how we got the feature set we have? Is no one updating the user stories? You are not alone.
With everyone trying so hard to move quickly it becomes harder and harder for people to slow down enough to write down the decisions that were made at a feature decision meeting and to check those decisions against the previous set of decisions. The assumption is often made that everyone in the room heard all the decisions and therefore there is no need to write them down. After all, everyone nodded their heads in agreement. Why bother, the reasoning goes, writing down what everyone clearly agreed to? Let me count the ways.
The single most important reason to write down the decisions that were made is to make sure that everyone really knows what was agreed to. Not everyone listens to everything in a meeting. Not everyone understands everything in a meeting. The words used in a meeting are often less than precise. People sometimes agree when they heard incorrectly what it is that was stated. When decisions are not written down, you can have as many interpretations of what was decided as there were people in the meeting, if not more. A clear record of decisions can avoid a lot of re-work.
In a long meeting with lots of issues it is hard to cross check all the decisions being made. The conflicts can be obvious or subtle. Getting them all flushed out during the meeting can be asking too much. I know this is usually the reason for a review, but it is still hard to do. At one particularly long product review meeting I ran we took out some product features that were necessary for the decisions we made at the end of the meeting, nobody caught it. This conflict only came out when the notes were being written and integrated. Sitting at my desk looking at all the decisions at one time made the connection easy to figure out. If you want to move quickly, you need to make clear product decisions that last. Writing down the decisions and reflecting on all of the product decisions is a good way to do that.
Not everyone who needs to understand what went on at a review meeting goes to the review meeting. Having a written record of the decisions allows others to follow what went on. If I know that the decisions are written down then I am more willing to delegate the attendance and decision making to others. If the only communication is verbal, then too many people feel they need to attend the meeting. Meetings that have a lot of people in them who do not contribute are not productive. It is also a poor use of people’s time.
Writing things down prevents people from drifting in their own directions after the meeting. How many times have you found yourself discussing some feature with someone only to realize they had a completely different conception of that feature, based on attending the same meeting you attended? You drag in a third party and they partially agree with each of you, just on different issues. Understanding of features will drift over time as people’s thinking evolves. This is a good thing. What is bad is that they do not know they have drifted and there is no way to know if people are still in sync. Keeping the User Stories up to date helps avoid these issues. It is one thing to decide to change a feature it is another thing to not know that you have changed a feature. A written record stops this vicious cycle.
It is not like the notes from a Product Review are an enormous burden. Too often someone tries to capture everything that was said at a meeting. The goal is not to recreate the meeting on paper, the goal is to document the decisions made so that people know what has changed. Decision meetings change what is to be done and thus the decisions need to be documented. The reasons for those decisions being made are useful, but not strictly necessary. As the Product Manager/Product Owner you should be the one to make sure feature changes and requirements changes are documented and shared on a regular basis.
© 2011-18 Westerly Consulting LLC, all rights reserved