5 Things I learned about good product managers from Marty Cagan
A product team is only as good as the product manager, and the product leader is responsible for the product managers. The VP or head of Product is the most important non-C-level position in a product company. — Marty Cagan
Marty Cagan has a strong belief and passion for doing tech products products right. After all, he wrote a book called “Inspired: How to Create Tech Products Customers Love” and founded Silicon Valley Product Group, an organisation that provides tools and workshops to share how great products are built.
Speaking at ProductTank Singapore, a forum for product people to mingle and exchange ideas, Marty shared ten common problems in product management practices and shared his views on what a good product manager in a good team should be like. I could tell that audience was inspired by the talk as it’s rare to see good, engaging questions, which started even more in-depth discussions, going on for almost 50 minutes.
As a product designer in Carousell, I work closely with product managers and pride myself as a product person, rather than just a designer.
Here is my main takeaways from this talk by Marty.
Core competencies of product managers
- Deep knowledge of your user and customer. Use qualitative and quantitative ways to understand your customer. They are equally important because they answer two different questions: Why and What.
- Deep knowledge of the data customers generate. Get a good picture of the state of your product. Data analysts can help clear up confusion but it’s ultimately on the product manager to have a holistic understanding of where your product is.
- Deep knowledge of your business. Understand how your product is marketed, sold, and serviced. Know the legal constraints, privacy issues, and ethical concerns.
- Deep knowledge of your industry. Besides all the domain knowledge and how your competitor is doing, a product manager should understand market trends, and what’s newly available in your tool set. Then you can explore solving problems with new technology and new tools.
As the product manager, your team, your designer, and your engineers are all looking to you to bring this knowledge to the table. Otherwise, whenever you need to make a decision, you will find yourself escalating the decision-making to product leadership or your CEO. Or worse, you find yourself calling a meeting with all the stakeholders to problem solve collaboratively — and your product ends up becoming designed by committee.
Outcome is more important than output.
Product Managers have two very different tasks: Discovery and Delivery. Most of a product manager’s time should be spent on discovery.
- As a product manager, we need to discover a solution that is valuable, usable, feasible, and viable.
- As a product manager, we need to deliver a solution that is reliable, scalable, performant, and maintainable.
Product teams shouldn’t tackle these two problems at the same time. We should be very conscious about which task we are working on now. Are we trying to find a solution to the problem or are we trying to deliver that solution?
A minimum viable product (MVP) that takes 4 months to build is too slow for discover the solution and is probably too fast for delivery a solution.
To do discovery well, try out many different solutions and approaches to solve a problem. Prototype them and test everything to see which one solve the problem. If you only gather or define “requirements” but not trying different approaches to solve the problem, you are merely collecting ideas and deliver something that might work, but most of the time, will not work.
A product managers’ job is to actually solve problem that we are asked to solve. If you find yourself shipping features rather than solving problems, you should probably spend more time in discovering solutions and only deliver those that helps to solve the problem. Sometimes it could mean to remove something from your product.
The outcome is more important than output.
Engineers are great at discovering ideas and solutions
Engineers often have great ideas and a lot to contribute during the discovery phase, because they work with the latest technology every day. If you only ask your engineers to code, you miss out on a whole other dimension they can offer. That said, keep in mind that not all the engineers are interested in contributing toward discovering solutions.
When you hear an engineer say “Why was I not involved in this earlier?” you’ll know this engineer probably has some good ideas and thoughts to contribute. You can unleash their potential to discover a solution by bringing them to see the users in pain, using your product. Good engineers take this personally and want to fix the problem.
Most of the time, it is the product managers and designers who spend most of their time to discover solutions, while engineers focus on delivery. However, consider letting the engineers take half an hour each day to immerse themselves in problems and potential solutions. They will probably have great ideas, solutions and different approaches from what you have in mind.
Spend most of your time prototyping, not prioritising.
When a company wants to deliver value to users, sometimes we fail to realise that it’s not about how many features we ship to our users. Consider alternative solutions or approaches to solve the problem. The impact and value comes when you actually solve a problem.
Spend little time on prioritisation. The only time we should invest on prioritisation is when we set the objectives and key results for the next period, and decide which problem to solve first. The time we spend on prioritisation and doing a roadmap can be better used to prototype,discover solutions, and build features that will actually move the needle.
You can easily prototype 20 different concepts in a week. Test with users to see if this solves the problem and show it to your leadership to see if this is something they can support. It could mean user prototype (low fidelity or high fidelity to test ideas with users), live data prototype, feasibility prototype (where engineers do a proof of concept to see if the solution is feasible), or a hybrid of all the above.
Have 3 sessions with your customers every week. If you are planning something big, such as a redesign of the whole product or solving a complicated problem, upping it to 5–10 sessions per week will help you to talk to more customers before investing more in delivering it.
Be a product manager. Not project manager, not product owner, and not a QA.
There is nothing that can train an aspiring product manager besides actually doing the work and getting coached by your product leaders. Without good mentors and coaches, many product managers fall in the trap thinking they are a product owner and only do what product owner in a scrum team will do. Many spend most of their working time doing project management works and dealing with administration work.
It just doesn’t feel right when you hear someone talking about your product while you are not there. So you take it upon yourself to answer all the questions on Slack, email, or in person. Sometimes it seems like you don’t have a choice because somebody has to do it.
To break out of this mindset, Marty suggests product managers rely on project manager or delivery manager if they work with one and don’t be afraid to let it go.
Thought about in another way, if you, as the product manager, don’t do product management well, you fail the whole team, the customers and the company.
This comes down to individual time management. As a general rule, you spend 4 hours of your working time, preferably the time that you can concentrate and really think. Besides that 4 hours, you can go into meeting to coordinate, you can spend some time (around 10% of your time) doing administration works, or you can write product requirements documents.
I am grateful that I had this opportunity to learn from Marty and appreciate ProductTank Singapore and the sponsors TenX and Grab that made this possible. It was a full room of people passionate about products and it felt very powerful that there are so many people in Singapore want to learn about how to be good product managers and generally do great products.
