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.
Set the context
This first tip has a more strategic aspect. Product managers are required to:
- Understand, communicate and explain the context in which they are working.
- Help the team to understand what’s the role of the product in the company strategy and in the market.
- Know how customers use the product and what they expect from it.
- Understand how a certain feature is inserted in the product strategy.
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.
In 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.
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.
So, there you have the 2 leadership tips for product managers and for anyone who is leading a project:
- Set the context;
- Remove obstacles.
I have been using them throughout my professional life and they have been guiding my success as a product manager.
Product Management: how to increase the success chances of your software
In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.
The book is organized in 5 sections:
- Definitions and requirements
- Life cycle of a software product
- Relationship with other areas
- Product portfolio management
- Where to use software product management
This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.
We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!