Efficient product management is energy that makes a company successful. A lot of cool people surrounding me in previous companies showed that. Helping to build the team, a lot of directions for the product, newcomers, communication with clients, mistakes analyzing, research, user experience and tons of other activities – this is not the full list related to product management.
We always want to have the best engineering team and excellent UI/UX professionals for making a great product. But this is not enough, and this strategy will not work without the “driver” who understands the business. Couple years ago I saw the illustration on the blog of Martin Eriksson about the place of the product manager. The image above illustrates his idea about product manager as a person who stands at the intersection of three circles: Technology, UI/UX and Business needs.
A manager who does not wish to get into all of the circles or wishes to get out of one of them slows down the development process and makes the team anxious. After all, those two factors make your product weaker and less quality.
In the previous article, there was a mention of giving freedom to your great Product Manager. Founder/CEO should always try to pass their business vision to this person carefully. All critical decisions should be made entirely on the “driver’s side” with giving “controlled freedom” to UI/UX and Engineers.
PM cannot build the product without knowledge about the components it consists of. The spaceship’s captain must know how it works. But it does not mean that a PM should over interfere with the development process. A proper balance between hands-off and hands-on managing approaches will bring more respect from Engineering Team and will make the product development process more effective.
It should be fully transparent for everyone why the team works in this direction and what is going to be achieved. Without proper interactions between the product manager and other team members, it is impossible. All features should be obviously connected with the goals and the mission of the company.
Communicating with different teams a lot provides an ability to understand the problems of product management better. The biggest of them is when the mission and business goals of a company are not the aim of all the people involved.
Another problem is the misunderstanding of the role of the product manager: in many companies project managers or business analysts are still called “product managers”. It causes much confusion.
Additionally, one of the biggest issues that a product-managing related person is facing a shortage of data necessary to make the right decision and choose the best direction for the product. In software development, it means dealing with the issue of prioritization of the features on the roadmap. Usually, different kinds of analytics and communication with clients help in solving the problem. We will return to the data issue in a couple of paragraphs.
Another problem for the product is inflexibility of its management. Situation changes, Managers should react to this. Many companies still lose clients and pay too much for development to support systems from the 90-s and 00-s. They keep working in the same direction because it worked well a decade ago. For instance, some companies kept building applications for Symbian and didn’t believe that this OS would be discontinued. Big corporations go down during a long time and there is some time to change the situation, but if we talk about start-ups – this is where the Product Managers should be as flexible as even possible.
But if we speak about the other side of the coin, Product Manager’s flexibility may raise a conflict with a team, such as when a client does not accept the implemented features. So the features priority and their specifications should be changed to fix this. The company’s direction could be modified as well, and explaining the problem to engineers will help the Product Manager to avoid frustration and other potential issues in the future. Nobody will be disappointed if the reasons for the changes in the product are explained in detail. It should be clear that the team’s efforts have not been wasted and the team members are not responsible for an incorrect step. Engineers mostly want to understand WHY they have to do something or even do it over. Also, a common childish mistake is blaming the team. Blaming the team instead of talking about their own mistakes is a way for the Product Managers to become mistrusted: people will see the real cause of the trouble and will not follow this person the next time.
So, let us get back to real life: how to select the lane that is convenient for users? People’s behavior and their experience with a product will highlight the proper runway. But it is hard to see it if the Product Manager is blind due to their decisions being based only on their own opinion. “Data-driven” is a commonly used term in articles like this one. PM must be data-driven. Nobody cares about what type of analytics is used during A/B testing: Google Analytics, Mixpanel or custom events basing on some Amazons AWS solution. Collected data as a proof is the real answer to the team’s or executives “WHY?” question.
Engineering team wants to build the product; commonly they do not want to manage. People who are responsible for the final product look want to see the result of their inspiration as a working software; they do not care how the “magic” happens. CEOs want their ideas to be implemented and may “dream about something”. Founders and investors want to see their money used with the maximum effectiveness and get the highest profit possible. A person who connects all the parts of the company, who creates roadmaps and reduces the amount of business details, solves conflicts and has a feeling of how all of this should work for the end-user is the Product Manager of a successful team.