Be a pragmatic Product Manager

Talking to my past me

Product management is a complex role that requires a blend of skills, knowledge, and experience. Several frameworks, such as Ravhi Mehta's evaluation tool and the Product Manifesto, have been developed to help Product Managers evaluate their skills.

In this blog post, I will reflect on my own experiences and share what I have learned about what I call a “Pragmatic Product Manager”, to explore the importance of realism in product management and offer insights that may help other Product Managers improve.

A. You work for an Organization

1. Be an Owner - Take the time to understand the priorities and goals of the organization's leadership. If you don’t like something, try to change it. Don’t complain or wait for someone else to do it. However, it's essential not to take on too many responsibilities and burn yourself out; if you can move things with others it is great.

2. Timing matters - If you find yourself frustrated with the lack of progress or change within the organization, try to be patient and wait for the right timing and opportunities. If you feel like you're making too many compromises and not making any headway, it might be time to consider moving on.

3. Don’t ask for a job description - Expect to do the work of other departments from time to time, like business, marketing, and customer support/excellence. You are the glue, and you need to be sure that customer value doesn’t break through a long customer experience flow. If the other departments are open and polite, you are lucky, they have done it before. But don’t do their job on a daily basis; Build a proper interface and leave. If they are protective, they play politics, you should discuss it with them and try to explain that you want the best for the customers. If you find walls and bad behaviors, it may be up to the Directors/VPs/CEO to change things in your organization.

4. Get out of your comfort zone - No one is perfect. As PdM, you give value by being diverse. Possibly, from time to time you may have to leave the PdM role and do something else. Don’t stick to an industry or a series of well-known companies. You miss the fun of mixing business models and ideas, learning unmet markets and problems you couldn’t imagine. Or you may stay behind in the latest developments.

Read more here.

B. Silicon Valley Fallacy

1. Be a product ambassador - it's essential to recognize that not every organization can operate like those in Silicon Valley. Don't wait for your organization to follow an SV playbook; they may not have the resources or know-how to do so. Many companies that have achieved a market fit and use Product Led Growth tout the benefits of being product-driven. However, if your organization doesn't have these characteristics, it can be challenging to convince the business-driven leadership to give more power to the product teams. Help them understand what Product thinking is and why it is valuable. Be your own ambassador; it is part of your job.

2. Connect with other product people - if you find yourself struggling to influence change within your organization, you should know that you're not alone. Talk to others in similar situations, share your struggles, and seek out insights from those who have successfully transformed their organizations. Remember that change takes time, effort, and a willingness to take risks from management.

3. Don’t be arrogant - If your product succeeds and there is a market fit, maybe you were lucky. If you ride a high-growing market, you will enjoy the glory of the success of the early builders. If you have a large budget to try things, you work for a prosperous and lucky organization. If you haven’t eaten sh*t trying to do things ground up on your own, or with limited resources and much politics, be proud of what you have done but don’t be arrogant. This is not a race with one winner. Try to learn from other PdMs from their experiences.

Read more here.

C. Learn frameworks, then strip them down

1. Build your toolkit - Learn about frameworks. It’s someone’s mnemonic or standardized rules. Before implementing a new framework in your organization or sharing it with your boss, try it out internally first. Understand how and when to use it effectively. If a framework proves to be effective, you can share the results but don't demand widespread adoption. Remember that other Product Managers or teams may not have the same context or experience and may struggle to implement the framework. Ultimately, you should use the tools and parts of the framework that work for you and build your own Product Management Toolkit.

2. Deliver value together with your teams - Don’t forget, you are there to deliver value. Discovery is important and prioritization is necessary, but delivery is all that matters; It's your skin in the game. Learn how to prioritize things that create value. Speed matters, especially in the early stages. Keep your process lightweight and focus on fast delivery. If your prioritization needs granular data to be effective, it feels more like you want to cover your *ss in case of failure. This is why your teams should be Agile, to minimize the risk of failure, not to follow their ceremonies. Ship, measure, understand, think, and repeat, in iteration.

Read more here.

D. Avoid team traps

1. Be a team player - As a Product Manager, you're only as strong as your team. Be transparent, honest, and fair with them. Instead of lying, let them know when you need time to back up your decisions with evidence. You're not superhuman, and you need a strong team to succeed. Motivate your team by making them feel that their contributions are impactful.

2. Be transparent - Don't cut your team off from clients or insights. Transparency is key to maintaining their trust and motivation. Remember that you don't have to be the smartest person in the room. Your team needs clarity, confidence, thoughtful decisions, and passion. Give credit where credit is due.

3. Don’t be a people pleaser - You shouldn’t be a glorified secretary for Tech or Business. You are not there to protect or pumper engineers, you are not a messenger of business either. Avoid bullsh*ting. Avoid making excuses or changing your opinion frequently to justify mistakes. Be upfront and honest with your team. Avoid rationalization. If you disagree with upper-level management, express your views, but don't let it consume your team's focus on the current reality.

4. Learn to Lead - Try to find time to think about the future. Probably no one does, and you will soon be obsolete.

E. Data is good. Interviews are better.

1. Understand the data - Most Product Managers claim they are data-driven; It’s like Teenage Sex, everyone has done it. Your metrics make sense to you, the organization, and the product development phase. Keep a log/journal of your releases. Try to see if something affected the product. Be aware if an external or marketing event affected your numbers. As Amazon does, separate input from output metrics and clarify what you expect. Many PdMs say they track revenue metrics, how many of them affect them and how do they know it?

2. Decide with context - Teams based only on data are as bad as teams that are based on HiPPO. Your users are not represented by numbers, even if they fit into clusters. Try to create some magic, impress your customers, and create the unexpected. You can optimize it later with data. Be smart, and talk with your customers, engineers, and operations. Collect opinions and try to find the underlying problems. When talking about problems and your product, you may have an epiphany.

F. Communicate effectively

1. Write, write, write - Writing things down increases clarity. The material you write may reach more people more easily than your word. By exposing yourself to a document, you gain more ownership; you are credible and accountable for what you ask for.

2. Get Visual in Iterations - People react to visual information faster and better. Why don’t you try to visualize your ideas? Everyone has an opinion until they get something tangible and say that this is what they were thinking. In the process, if your idea sucks, you will drop it before you present it. Iterate from documents to visualizations and back to documents. You will find out how much clarity you get through this process.

3. Don’t share drafts - People with strong opinions or bad intentions may use them against you, thus clarifying when something is a draft may be useful; but typically you should better hide it from public sight. When communicating your final work, however, try to narrow it down to the essentials and link it with any additional content for elaboration.

4. Meetings are a threat - You should consider meetings as a potential time waste, most of the time. Have this in mind and try to optimize this time for everyone. It’s preferable to go with your team or colleagues for coffee/drinks instead of attending pointless meetings. You may have to add and remove regular meetings until you find the frequency that makes sense. Make it clear and don’t be afraid to make changes that matter. Attending meetings and answering emails is not a job, it’s your tools. Use the LNO framework to avoid it.

PS: Thanks for the feedback from

Konstantinos Giamalis

on this topic. Sharing common experiences helped me shape this article.

PS2: As experiences and details matter, I am thinking of writing one post for each topic. Feel free to leave your comment on the topics you may be interested in reading about first.