Our Guest
Pawel Huryn is a recognized Product coach, with 15 years of experience in the software world. Pawel helps organizations build great tech products as well as exceptional product teams.
Video Transcript:
Gosia: Hi, my name is Gosia from Whiteboards and this is the Agile on board Show. Today, my guest is Pavel Huryn, a recognized product coach with 15 years of experience in software. Pavel helps organizations build great tech products and amazing product teams. Hi, Pawel, thank you for joining us!
Pawel: Thank you for having me.
Gosia: Pawel, it seems like the current tech market is overcrowded. So many companies realized that digital adoption is the future and the marketplace has become so much more competitive.
We can only imagine how challenging the product manager role is in this environment, especially since we know that so many product efforts fail, and probably half of the product ideas are never going to work.
In this episode of the Agile on Board Show, we’re going to focus on common Product Manager mistakes, and what to avoid to make sure that your team is building something valuable that your customers will care about, and that will let you survive in the current market.
Pawel, from your experience, what are common Product Manager mistakes, and what to avoid?
Pawel: I would say, the product is hard, we’re going to make mistakes, and I probably cannot go through all of them.
The first one is the one that I personally experienced, it’s leading with control, not with context, so the opposite of what Netflix culture is about. Some time ago, I wrote an article that I wasted three years of my career.
Discovering the code that needs to be built and understanding customers’ needs, understanding business, was quite an easy path. However, my teams were not engaged, they were totally not interested in what we were doing. The quality of our product sucked. I think many people experience it.
What I tried and also what many other Product Managers do is trying to tighten control. I was creating procedures, like release procedures, and detailed specifications of what needed to be done. I was testing everything to make sure that there are no errors or mistakes. It was just after I stopped being a developer, so I even fixed some bugs myself.
Even though I worked 60 hours a week, it didn’t help much. We were unable to deliver something valuable and our customers were not happy.
Gosia: Just to clarify, if I understand correctly. Basically, you were trying to tighten the control, but the problem was the lack of engagement in the team. What was the main goal of increasing the control or having all these processes in place?
Pawel: By having more control, I tried to avoid errors, and mistakes, and to exactly specify what the team should do to solve the problem.
After I attended one of the Agile conferences, I started experimenting. I started giving them problems instead of specific tasks. Previously, I created user stories with all the details like algorithms, software architecture, and very specific tasks that they should implement. Then I started specifying the problem and providing the team with the context, why we are doing it, why it is valuable, what is our goal, and what is our strategy so that the team can understand it better and they can make their own decisions.
I also started inviting the team and making product discovery together. Previously, I talked with customers and the business alone. For a few years now, I’ve done it together with designers and engineers and I have repeatedly found that the best ideas often come from engineers.
When people understand the goal, they understand why they are doing what they are doing, and understand how it is valuable to others; it results in increased motivation. Also, the results are much better. The ideas are much better because people can innovate, people can propose solutions. It works pretty well.
Gosia: One of the common mistakes would be not communicating the value. Why we’re doing what we’re doing, and when the team understands the bigger picture, it’s easier to motivate them.
Pawel: It’s the style of leadership. There are several problems. One of them is that people are given tasks or even problems, but without enough context, and they don’t understand why it is important. The other issue is that they are not trusted, they are not empowered to figure out how to solve problems themselves and for people that are professionals, this is not very encouraging.
Gosia: I understand – I mean, I think everyone can relate to that.
Pawel: There are also some other mistakes. For example, a lot of people assume that they know what needs to be done to deliver value. Some people ask customers what they need, and then start implementing it without spending time to understand the problem and ideating how to solve this problem, or how to support the job the customer is trying to do.
It’s extremely important for the Product Manager to think about the risks and of course, we need to talk to the customers to understand their needs, understand problems, and desires, and empathize with them. But then, it’s our role to come up with the solutions. For example, by prototyping, creating killer prototypes, and visibility prototypes, addressing the risks of value, viability, feasibility, and usability. We need to test the high-risk assumptions before implementing anything.
Part of this issue, jumping straight to the implementation is also not spending enough time on understanding the problem. Sometimes, we have this approach that we just want to find the solution. And we start brainstorming, throwing some ideas, and thinking about how to best solve the problem, but we don’t really understand the real issue that we are trying to solve.
It is extremely important to focus on the job that the customer is trying to do – in the broader context. Align it with the product strategy, product vision, also some organizational goals, and only then start to implement ideas.
Gosia: I have a question here. Does it happen sometimes that when we listen to the customer feedback, and then we try to think of a solution, we actually don’t talk to the people that decide on the business strategy and this is not aligned? Let’s say we’re listening to the customers, but it’s not aligned with the goal of the organization. Does this happen sometimes? And is this a mistake as well?
Pawel: Yes, absolutely. As a Product Manager, there are two risks that Product Managers care about the most, and one of them is value risk. We need to make sure that what we create will be desirable and will be loved by the customers. But also, of course, it needs to work for different parts of the business like marketing, and sales.
For marketing, we need to make sure that they can market it or that it’s a good time, for example, to deliver the feature for sales. We need to make sure that we have the sales channels, and that we can sell this product or this feature because sometimes we might have a great idea, but our sales cannot support it.
It’s also extremely important to consider the financial perspective. I’ve been talking specifically about financial liquidity. Even if we can be profitable in the long term, in some companies, it is not possible to wait two or three years before we start getting a return on our investment. This is also important and as you said, the product must be aligned with the company’s strategy, the business strategy, and the company vision and we cannot treat the product as a separate organization.
Gosia: Yes, great. Thank you for clarifying this. Can you tell us one more example of common Product Managers’ mistakes?
Pawel: Maybe it’s not Product Manager specific, but it is common, it’s ‘blaming others.’ If everything goes well, it’s not a problem. However, when problems occur, people don’t like to blame themselves.
I would say that the blame game can be addictive. No matter how good we play it, it’s difficult to win. As a Product Manager, you should take the more challenging path. Only by taking responsibility, you can learn something and drive conclusions from the mistakes and eventually achieve exceptional results. This is the characteristic of a Product Manager’s job – if you fail, you fail as a Product Manager and if you succeed, you succeed as a team. It’s important to shine a light on others in your team as well.
Gosia: Thank you. Basically, we should avoid blaming others because this doesn’t help with collaboration and communication within the organization. As you said, it’s important not only for Product Managers but probably for everyone in the office.
Thank you so much Pawel for joining us and sharing these tips with everyone. Thanks, everyone for joining and listening to this episode of Agile on Board. Make sure to tune in to future episodes and see you next time. Bye!
