post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

Building your own user experience and software stack: This week’s product news

Guest Post

Building for change: When transformation and product management meet

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Lessons from my first year as a Prod Ops Manager

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

What are product features? Definition, examples, and 5 types

Viktor is a product manager at heart. He loves to learn both from the users and his peers in the industry. In his spare time, he studies philosophy and practices a variety of sports.

Viktor Nagy

<p><span style="font-style: italic;">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</span></p>
<p>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.</p>
<p>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.</p>
<h2>Why do expectations matter?</h2>
<p>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.</p>
<p>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.</p>
<p><span style="font-style: italic;">Expectations </span><em>are</em><span style="font-style: italic;"> like fine pottery. The harder you held them, the more likely they were to crack. ― Brandon Sanderson, The Way of Kings</span></p>
<h2>Expectations and agreements in product management</h2>
<p>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.</p>
<p>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.</p>
<p><a href="https://www.mindtheproduct.com/transitioning-scrum-kanban/" target="_blank" rel="noopener">Read more about the Scrum concept. </a></p>
<p>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.</p>
<p>We already discussed the two most obvious places of expectations and agreements of the product manager role.</p>
<p><span style="font-weight: bold;">Let’s turn our attention to a few more nuanced areas.</span></p>
<h3>The Agile process</h3>
<p>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.<span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/why-mistakes-are-key-for-product-excellence/" target="_blank" rel="noopener"> Learning from our failures</a></span> is hard when we are frustrated! In these cases, some approaches, like the <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/how-to-use-the-5-whys-to-manage-stakeholders/" target="_blank" rel="noopener">5-whys</a></span> 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.</p>
<p>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.</p>
<h3>User interviews</h3>
<p>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.</p>
<h3>Being data-driven</h3>
<p>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.</p>
<p><a href="https://www.mindtheproduct.com/data-driven-product-management-by-matt-lemay/" target="_blank" rel="noopener">Explore more insights on data-driven product managers by reading this piece by Matt LeMay. </a></p>
<h2>The culprit: self-esteem</h2>
<p>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.</p>
<h2>Conclusion and recommendation</h2>
<p>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.</p>
<p>Thanks to Steve Chandler for the generic wisdom around the topic and to <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/jobs-to-be-done-by-joe-leech/">Joe Leech</a></span> for coaching me through this topic.</p>
<p>Explore more content on the <a href="https://www.mindtheproduct.com/category/product-development-process/" target="_blank" rel="noopener">Product Development Process.</a></p>

Expectations and agreements in product management

Viktor Nagy

Read more

Comments