Product managers have the hard task of leading the product’s evolution without being anyone’s “boss”. In other words, they must convince everyone who works with their product that the path they defined for the product is the most adequate.
In several texts about product management we find the definition that product managers are the product’s CEO. I’m not very fond of this definition because CEOs have at their disposal the direct leadership of everyone in the company and can, in spite that it is not the most adequate way, use hierarchy to achieve their goals.
On the other hand, product managers work within a matrix relation, i.e., they are not hierarchically in a position of being the manager of anyone involved in the product creation. By the way, this matrix relation is an excellent leadership exercise to showing an extremely important quality for a product manager: leading without being anyone’s manager.
Even though they work in completely horizontal relationships, with no hierarchy, they must hold some leadership in order to convince people to develop the product in the direction they visualized.
So, here are two leadership tips that product managers, or any leader, should remember in order to lead efficiently.
This first tip has a more strategic aspect. Product managers are required to:
This tip may be simple and obvious, but is not uncommon to find people who work not knowing exactly why they are doing their job. Helping people to see the impact of their work makes them understand why it is necessary.
Try to bring software engineers in your next client meeting. Better yet, take them to a usability test so they can see their users using the software they created. This will help them to understand why the software they’ve developed exists, what problem it solves and to whom it solves this problem.
Setting the context helps to engage people who are involved with the product. They will understand the product’s relevance both (1) to the company who owns the product and (2) to the product’s users. This engagement is important not only to the product’s core team (engineers, product managers and UX designers) but also to everyone involved with the product, such as marketing, sales, legal, finance and customer support.
As I mentioned in an article yet to be translated to English about creating a product vision, knowing and communicating the context where the product is inserted helps the product manager build, together with the product team, the vision and strategy of her product.
At Locaweb we have some old systems that, as any legacy, are hard to handle: little test coverage, old programming languages, code built with practices from more than 10 years ago. It is a struggle every time we need to touch the legacy code.
We’ve been working for quite some time in order to minimize the amount of legacy code and to build new code that replaces “the legacy”. However, the business cannot stop, and, sometimes, the only way out is to work on “the legacy”. Every time that there’s a demand to make a change to “the legacy” the engineering team asks to wait for the new code that will replace it, since building the demand on “the legacy” will cost too much time and in the new code will be a matter of a few days, if not a few hours.
At the beginning of 2015 a demand that required changes to “the legacy” appeared. It was necessary to change the limits and prices of our web hosting plans to follow up with changes in the market, which has become more competitive with new entrants with more attractive offers. Initially, there was some resistance from the developers to work on the legacy code, but when we explained the motivation behind the changes, they went for it and got their hands dirty in the old code.
As soon as the changes were implemented, we constantly updated everybody who worked in this project about the positive results. The comprehension of why something is needed and should be done is fundamental both for motivating who is working on it and for the quality of what is going to be delivered.
I want to propose a thought experiment. Let’s use empathy, the main characteristic of a digital product manager, to put ourselves in the position of a software developer who has received the following story from his team’s product manager:
When it reaches 39, an alarm should go off.
Although it appears to have enough information, when you start implementing it, you will see that information is missing. What are 39? Does the alarm go off when it gets to 39 coming from 38 or coming from 40? Or both ways?
Let us now see the same story with the proper context:
We are developing a system that monitors body temperature and this system should sound an alarm when the temperature rises over 39ºC.
With the context, it becomes much easier to understand what the number 39 is and why you were asked to sound the alarm. And it is easier to code the right software.
So, in your next planning session with the team, take the proper time to explain the context of the stories. This will increase the chances of success of your software!
This tip has a more tactical aspect. Removing obstacles is fundamental so team members can work on the product. We must feel we are moving forward, that we are doing something, building something. The article What Really Motivates Workers from Harvard Business Review has some interesting data on satisfaction at work. They put together a study in order to find out what happens in an excellent day of work. The answer was in a word: progress.
The advice by the end of the article sums up well the second tip:
You can proactively create both the perception and the reality of progress. If you are a high-ranking manager, take great care to clarify overall goals, ensure that people’s efforts are properly supported, and refrain from exerting time pressure so intense that minor glitches are perceived as crises rather than learning opportunities. Cultivate a culture of helpfulness. While you’re at it, you can facilitate progress in a more direct way: Roll up your sleeves and pitch in. Of course, all these efforts will not only keep people working with gusto but also get the job done faster.
What obstacles?
So, here are some examples of obstacles that a product manager can remove:
So, there you have the 2 leadership tips for product managers and for anyone who is leading a project:
I have been using them throughout my professional life and they have been guiding my success as a product manager.
Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products: