Originally published on www.mindtheproduct.com, 2021-11-25.
We have two choices in life when we relate to other human beings. One is to have expectations, and the other is to create agreements. — Steve Chandler
The first time I heard about the importance of contrasting expectations and agreement from Steve Chandler. Since then, I realised how important this topic is every day in my job as a product manager. Most friction and tension in our everyday life comes from situations where our expectations differ from reality. This is especially true about situations with multiple participants involved, like family or a workplace.
Realizing the problem of mismatching expectations, the solution is to create agreements. Agreements might have a variety of forms from contracts, to a lightweight “gentlemen’s” handshake, or might be embedded in a process without us being aware of it. As product people, expectations management is all around us in our daily job. In this article, I summarize a few areas where expectations play a crucial role, and what we can do to manage them well or sometimes turn them into agreements.
Why do expectations matter?
Before discussing specific examples of how expectations and agreements appear in a product manager’s job, let’s discuss first why they matter. The basic idea is, that we have expectations about every situation in our life. When we get married, we expect to stay together for the rest of our lives, still many marriages end with a divorce. This example shows not just that we have expectations, but that all the parties have expectations, and we might not be aware of them. Expectations on the other hand are far from agreements as proved — in the case of marriages — by prenuptial agreements.
Turning our attention back to product management, we have expectations around the growth of our user base, the likely delivery of a feature, our career growth, how much help we can receive from other teams, etc. Most of these expectations are unspoken. Moreover, most workplace tensions rise from the realizations of these expectations. In the case of a marriage, often the best solution is to make the expectations clear, discuss them openly, and create agreements around them to avoid unpleasant surprises. But this is not always true in our profession as we will see shortly.
Expectations are like fine pottery. The harder you held them, the more likely they were to crack. ― Brandon Sanderson, The Way of Kings
Expectations and agreements in product management
Let’s start with a situation where expectations are discussed openly and turned into an agreement: sprint planning. In sprint planning, the product person is the “customer”, we set the priorities of the backlog, and expect a specific scope to be delivered at high quality, within budget and in time. Thankfully, we learned that we can not control all these aspects. Except for prototypes, we give no concessions in quality, we do not control our budget, so we have to play with the scope or the estimated time of delivery. The agile movement and Scrum especially provide us with clear guidance here. We work in short sprints and when we plan these sprints we discuss the expected scope with “good enough” confidence. When we enter sprint planning, everyone has expectations about the complexity of each item on the backlog. The process, like the planning poker, helps us to discuss these expectations and come up with a shared expectation, that is an agreement. The Scrum process and especially the sprint planning turns our expectations into an agreement.
Using Scrum or another process, the product team can turn the expectations around product delivery into agreements. At the same time, the product person is responsible to communicate about the future of the product to the stakeholders outside the product team, including customers, users, sales, etc. One of the first rules of product management that we learn is to never commit to any deadlines. This is in sharp contrast with the process-oriented agreement setting in sprint planning. Our customers are often not much interested in the bi-weekly increments that we can deliver. Moreover, the pool of interested parties is way harder to reach and communicate with than the single development team that we are in charge of.
At the same time, we should not forget that everyone has expectations about everything, especially if they have any interest in a topic. As a result, all our users have expectations about the feature they are waiting for. They expect a specific way of working, their problem to be solved, and they expect a timeline for the solution to land. Our job is to understand their problem and expectations around the solution. On the other hand, we never commit to a deadline but manage their expectations around it without an agreement. If you work for a company like GitLab, that has its backlog openly available to anyone, then you put the scope of the solution into an agreement in the form of a public issue. At the same time, there are no agreements around the expected delivery until the very last months. Managing the expectations around deliverables is probably the hardest part of a product manager’s job given the complex communication channels and the stakeholders’ vested interests.
We already discussed the two most obvious places of expectations and agreements of the product manager role.
Let’s turn our attention to a few more nuanced areas.
The Agile process
The Agile process recommends running regular retrospectives to facilitate team learning and to improve the processes. Expectations and agreements have a very important effect on learning. If we work out of expectations, and someone fails our expectations, frustration emerges naturally. Learning from our failures is hard when we are frustrated! In these cases, some approaches, like the 5-whys might help us to get away from the initial frustration, but it will happen again and again and again, as the true culprit is the hidden expectations.
If we have agreements and we fail them, the agreement could set us up for a blameless learning path, as we can focus on the agreement from the very beginning. Both parties agreed to the terms of the agreement, so there is no single party who failed the other; there is no reason to be frustrated with each other. If the team understands the role agreements play in an organization, they might have a special interest in improving their agreement setting. Retrospectives can become the place for improving how we agree and learn about the failures we made around previous agreements or missing places for agreements.
User interviews
Another interesting area of expectations and agreements are the user interviews. As product people, we often speak with users to learn about their problems and how they might use our product. These calls might be organized by sales, UX research, or ourselves. In either case, the participants will have some kind of expectation about the call. For example, in the case of a sales-initiated call, the expectation might be that we are going to present various features and best practices, and might try to convince the user why they should start using these features. As a result, if we want to have a user interview, we should set the scene beforehand, and make it clear what the call will be about. We should manage the expectations of all the participants before the call happens.
Being data-driven
The final example I want to present is around hard (or not that hard) data. These days it’s fancy to say that we are data-driven, at the same time, I have not met many product managers who are truly data-driven. One of the most common misconceptions I see is that we are afraid to speak about our expectations for data. Do you have targets for adoption in the current quarter? Have you discussed these with your team and management? Many product managers claim that they can’t estimate these numbers, there is so much uncertainty involved. I do not want to deny the uncertainty, but I would like to emphasize the fact that even in the case of uncertainty, we have expectations. Moreover, we, humans, perform relatively poorly in statistical intuition, thus writing and discussing these expectations openly will likely improve them, not speaking about the alignment it might give and the ideas that might emerge from such a discussion.
The culprit: self-esteem
By now, you might agree with me that expectations management and agreement setting plays a crucial role in our job. So, why don’t we practice it all the time? Looking at my practices, I identified two reasons. The first problem is, that often we are not aware of our expectations, we do not notice when we form them, and thus we can not stand up and speak about them. Once we overcome this issue (for example thanks to a process, as the sprint planning), the second problem is that we are afraid of writing down our expectations. Writing down expectations, and providing them as a basis for an agreement, makes us vulnerable as we might identify with our expectations. Having a high-trust culture or a culture of experimentation might help here. In the former case, vulnerability is removed from the system, in the latter case experiments help with removing our bond with the expectations we put forward.
Conclusion and recommendation
Both expectations and agreements play an important role in the product managers world. Learning when to turn expectations into agreements and when to manage expectations as they are is one of the subtle aspects of our job. At the same time, just going through the examples provided above, might have convinced the reader that we would be better off by turning some of our expectations into agreements. Doing it is rather easy! Let’s start to communicate about them clearly and once we share our expectations let’s ask for the others to share them as well.
Thanks to Steve Chandler for the generic wisdom around the topic and to Joe Leech for coaching me through this topic.