post

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! 🎉

What we learned at Pendomonium and #mtpcon: Day 1

How internal product teams drive growth at Wise

Optimizing teams: A dual perspective on Team Topologies

From DataSnipper to ComplianceWise: Youssef Hounat on succeeding as a startup’s first product person

How to improve your relationship with data – Heather Williams (Director of Product, Elsevier)

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Sunday Rewind: How to avoid product discovery pitfalls, by Navin Nair

Guest Post

What a product manager does in three films and a box set 

Stanisław is a Product Manager with 10 years of experience in business software and lean management. He is an expert with passion for people. He is a certified Professional Scrum Product Owner and a postgraduate in psychology in management. Currently he helps his team to develop a B2B product and searches for the synergies between fatherhood and the craft of product management.

Product Manager

Stanisław Plebanek

<p>As product people one of our most important skills should be the ability to say no. We may have to use it when the stakeholders want to implement certain features or when the developers at our startup try to refactor the MVP code. But there is an additional power that you should master when developing new products or features. It’s the capacity to say “I don’t know”.</p>
<p>I work with a team of very bright developers on innovative enterprise off-the-shelf software. Recently one of the team asked me about the acceptance criteria for a user story that was somewhere in the middle of the product backlog. I tried to make up some criteria on the fly but finally had to let it go.</p>
<h3>Not Knowing Really is Okay</h3>
<p>“I don’t know” was my answer. I didn’t know because I hadn’t been working on that user story &#8211; it was low in the backlog and not a priority. I&#8217;d planned to refine it with the team in five weeks time, and no sooner. In the meantime, I had other tasks to take care of. I didn’t stop with my “I don’t know” answer, I also explained to my coworker why I didn’t know so that they could better understand my thinking.</p>
<p>A few days later, during the daily scrum, another developer raised an issue: “Do we want to implement functionality X because you mentioned it some time ago? Now is the time to make up our minds on it. Deciding on X influences how we will implement functionality Y as both are partially connected.”</p>
<p>“I don’t know yet,” I answered. How could I know what we’d be doing in the future? I didn’t know if users would buy our product so I had no clue whether we should add anything to it &#8211; and if we did, whether it should be that specific functionality. Deciding on implementing X wasn’t important. The developer himself had mentioned a few days earlier during planning that the cost of implementing Y wouldn’t change much whether we prepared ourselves for X or not. Therefore the decision of whether or not to implement X could be postponed.</p>
<p>So from one perspective, you could say, “this product manager doesn’t know anything. He can’t make the decisions he’s paid to make”.</p>
<p>I’m aware that I don’t need to know the answer for each and every product-related question.<a href="https://www.mindtheproduct.com/good-product-management-is-the-key-to-organisational-happiness/" target="”_blank”" rel="”noopener” noopener noreferrer"> I work in an organization with a healthy culture</a> that enables me to say the “I don’t know” phrase openly. I know that sometimes it’ s better to admit that I have no clue rather than to bluff in order to sustain some authority.</p>
<figure id="attachment_20798" aria-describedby="caption-attachment-20798" style="width: 864px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-20798" src="//wp-content/uploads/2020/07/stanislaw-plebanek-1-shutterstock_365392142-300x200.jpg" alt="" width="864" height="576" srcset="/wp-content/uploads/2020/07/stanislaw-plebanek-1-shutterstock_365392142-300x200.jpg 300w, /wp-content/uploads/2020/07/stanislaw-plebanek-1-shutterstock_365392142-768x513.jpg 768w, /wp-content/uploads/2020/07/stanislaw-plebanek-1-shutterstock_365392142-1024x683.jpg 1024w" sizes="(max-width: 864px) 100vw, 864px" /><figcaption id="caption-attachment-20798" class="wp-caption-text">Even with plenty of plans in place, you can&#8217;t have the answer to everything (Image: Shutterstock)</figcaption></figure>
<h3>1. Say “I Don’t Know”</h3>
<p>Many of us don’t like to admit that we “don’t know”. It’s not a popular thing to say in many cultures. The influence of others &#8211; our teammates or stakeholders &#8211; creates a sense of conformity.</p>
<p>We are seen as experts responsible for a product. Being an expert &#8211;  or rather feeling that we’re perceived as one by others and believing in it &#8211; makes us act in certain ways. We want to meet social expectations, so we make decisions on topics we know very little or nothing at all.</p>
<p>Letting others know that you don’t know is the matter of respect to them. It means you are honest with your team and with the stakeholders. This helps to establish relationships built on trust and will eventually pay off. So, next time somebody asks you a question you don’t know the answer to, don’t be afraid to say “I don’t know” and explain why you don’t know. If you’re doing your job right and acquiring the knowledge you should have, then you will show them respect and you can build your authority without making things up.</p>
<h3>2. Create Space for Developers to Engage in Customer Discovery</h3>
<p>If used wisely, the “I don’t know” phrase may be a way to engage the developers in the process of learning about customers and their needs. Working in a startup environment as a product person means I have lots of different tasks: from defining user stories, discussing them with the developers or testing to acting in a promo video, preparing sales talks or working with lawyers to establish license agreements. So, to be honest with you, I have many “I don’t know” situations, where it would be beneficial to find information as quickly as possible.</p>
<p>Having <a href="https://www.mindtheproduct.com/empowered-product-teams-by-marty-cagan/" target="”_blank”" rel="”noopener” noopener noreferrer">an empowered team</a> helps. When I admit that “I don’t know” and we all feel the urgency of that information, the developers step up and help us to find out. Recently we started working on a server application to be implemented at the customer’s site. I tried to discuss this with the customer representative but our meeting didn’t bring us closer to successful implementation. Rather than go to the team with direct requirements I said we needed to stop because we didn’t have enough information. When I told them that I didn’t know how to approach the topic in order to give them the necessary information they proposed contacting the customer themselves. They contacted the IT department directly and were able quickly to solve the technical issues with the implementation. It delayed implementation by a week, but it was better to stop the development when we didn’t know what to do than follow a blind guess. If our blind guess had been wrong our work would have been redundant and required rework. It’s about doing things right the first time.</p>
<figure id="attachment_20799" aria-describedby="caption-attachment-20799" style="width: 848px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-20799" src="//wp-content/uploads/2020/07/stanislaw-plebanek-2-shutterstock_746228473-300x200.jpg" alt="" width="848" height="565" srcset="/wp-content/uploads/2020/07/stanislaw-plebanek-2-shutterstock_746228473-300x200.jpg 300w, /wp-content/uploads/2020/07/stanislaw-plebanek-2-shutterstock_746228473-768x512.jpg 768w, /wp-content/uploads/2020/07/stanislaw-plebanek-2-shutterstock_746228473-1024x683.jpg 1024w" sizes="(max-width: 848px) 100vw, 848px" /><figcaption id="caption-attachment-20799" class="wp-caption-text">Admitting when you don&#8217;t know the answer, creates space to invite support and important conversation (Image: Shutterstock)</figcaption></figure>
<p>I encourage you to stop bluffing if you don’t know and let your coworkers be aware that as a team you have a knowledge gap to fill. This may create space for the team to engage in customer discovery and to understand your work better. And it will prevent them from working on the wrong specification or even on the wrong features.</p>
<h3>3. Don’t Make Decisions too Soon</h3>
<p>Not knowing when we don’t have data is okay. What about making a decision based on data? Is it always relevant? Research shows that we shouldn’t make decisions too early &#8211; even ones that are based on data. How can that be? To understand this let’s look at Ancient Greek philosopher <a href="https://en.wikipedia.org/wiki/Heraclitus" target="”_blank”" rel="”noopener” noopener noreferrer">Heraclitus</a> who tried to explain the elementary changing of objects with the flow of time. His most famous saying is <em>ta panta rhei kai ouden menei</em>, everything flows, and nothing stays. This is true nowadays and it’s true for data as well. As time goes by our information gets out of date. Research from MIT’s Jin Kato shows that information in a development setting gets out of date at the rate of 6% a month.[1]</p>
<p>Let’s look at a straightforward example. How many of you have sent a B2B mailing recently? How many bounced back to you due to outdated email addresses? Business emails get out of date, so if we don’t update the email database we will get more and more bounced-back emails after every mailing. The same applies to the data we use to make product-related decisions. The longer it takes from making a decision to using the results of that decision then the larger the risk of failure due to information degradation. I admire the words of one Toyota senior product development manager, who said that his job is “to prevent people from making decisions too quickly”.[2]</p>
<p>Remember, the next time you have all the data for your report, all your requirements for a user story written down, or all the information necessary to make a decision &#8211; plan some time to review the information you’ve gathered and update the deliverable.</p>
<h3>4. Be Grateful for all the Things you Know</h3>
<p>Most of us have been influenced by the COVID-19 pandemic. How long will it last? How will it influence our social life, our economies in the long run? What will the world look like in a year? These are the questions we don’t know the answers to. So keep in mind this global state of imponderability and remember to be grateful for all the things you are certain about, for all the questions you know the answers to.</p>
<p>At the end of the day, our job, as product people, is to know. We seek to find answers to the most important questions in relation to our products. Certainty comes from somewhere, or rather someone. Please, don’t forget that there are people around us who provide us with small pieces of information which, put together, create the answers we look for. Be grateful for all of them!</p>
<hr />
<div>
<p>[1] Kato, J. (2005). Development of a process for continuous creation of lean value in product development organizations (Doctoral dissertation, Massachusetts Institute of Technology).</p>
</div>
<div>
<p>[2] Ward, A., Liker, J. K., Cristiano, J. J., &amp; Sobek, D. K. (1995). The second Toyota paradox: How delaying decisions can make better cars faster. Sloan Management Review, 36, 43-43.</p>
</div>

Why Product Managers Must Learn to say “I Don’t Know”

Stanisław Plebanek

Read more

Comments