How to be more convincing as a Product Manager
As product managers, we are constantly interacting with many stakeholders who express their needs: sales, customer success, operations, marketing and even the CEO. With such external pressure, it can be sometimes challenging to move forward on product decisions. The perfect balance is to be able to say no, while still proving your point and showing you’re not making one-sided, arbitrary decisions. Here are some tips I’ve learned on how to find this balance:
#1 Show your feature covers the main use case
Sometimes there can be a disagreement between the product manager and a business stakeholder on the launch of a new feature: each has its own definition of the minimum viable product, because the stakeholder wants to add many product features to maximize the success of the launch of this feature.
In this case, try to show that your version covers the main use case and that it will already bring a lot of value to many users in 2 weeks from now. But what is the best option? To bring value in 2 weeks to 80% of the users, or to bring value in 1.5 month to 95% of the users?
Sometimes the disagreement can be over a potential “announcement effect”: the business stakeholder wants to push a big package of features to users with a big marketing & PR push, in order to amaze them. In this case, you can suggest to keep pushing your feature in small iterations, but hidden for the majority of your users, with a small pool of beta users, who can even be employees of your company.
For more insights, you can watch this video by Rémi Guyot and Tristan Charvillat.
Rémi Guyot et Tristan Charvillat (Designers chez PayPal, Intuit, BlaBlaCar) expérimentent depuis une dizaine d'années…www.infoq.com
#2 Crash test some assumptions with user tests
Sometimes the disagreement can be over UI, UX or content details that are considered not to be clear, or potentially very confusing for users. In this case, the discussion can get pointless quite fast, because in design everyone has their opinion but nothing is based. Try to get out of the building:
- Do some guerrilla testing to invalidate/validate your assumptions as fast as possible. Carolyn Chmielewski gives some good advice in this article
- If you don’t have time to go out in the wild, you can also do remote testing thanks to tools like Maze that will give you analytics on your prototype. However, it’s more efficient for UX/UI tests than pure content understanding.
#3 Show that the UI/UX of your feature is a regular pattern of your product
Disagreements can sometimes be around very small design details: “this screen should have a bigger title”, “this should be on the main page, not in the modal”, “the profile picture should be highlighted differently”, etc… Those seem like small details but can actually ruin the productivity of your exchanges with your stakeholders. When you have systemic patterns in your product, this will cut such UI/UX debate and level up the discussion around more strategic product topics.
Today, many startups chose to build a design system not only to have boost the productivity of their product & tech teams, but also to have more productive product review between PMs and their stakeholders. There are many good resources about how to build a design system, including:
- Les dessous du Kit UI de KissKissBankBank by Solène Maître (in French)
- Stop designed interfaces, start designing experiences by DUVAL Nicolas
#4 Prove that you’re using a common pattern well known by your users
Sometimes, your UX is not the result of a long thought process but just a smart copy/paste. This website formulates some laws of UX, including “Jakob’s Law”:
Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.
As a result, if you’re trying to implement a feature that integrates some patterns that already exist in very popular products millions of people already use, you should probably not reinvent the wheel, but inspire yourself from familiar design patterns. Examples.
- My feature shows a list of documents, with several possible actions on each document. Let’s see how Dropbox, Google Drive, Evernote, etc. are doing this.
- My feature shows a map with a list of places. Let’s see how Google Maps, Foursquare, Citymapper, etc. are doing this.
This is not stealing but helping your users navigate through the dark waters of your product. It will also cut many design debates you could have with your stakeholders.
#5 Make simplicity not only the religion of your product team but of your whole company
There is often a unhealthy tension between the product team, that thinks that the best user experience is around providing sleek & dead simple interfaces & user flows; and business stakeholders who have KPIs to reach, and who thus suggest very agressive product ideas, that are effective in the short term but clearly not sustainable for the product in the long term.
I’ve seen this tension become way healthier when business stakeholders understand that reaching their KPIs is compatible with the long term vision of the product. They just need to embrace simplicity.
In some cases, simplicity is already in the DNA of the company. I’m thinking about Captain Train (acquired by Trainline) or Alan, the innovative health insurance company. Those companies built themsleves in opposition to a complex industry. But if you’re not in such a company, you can change things by evangelizing the benefits of simplicity: try to measure the productivity it brings to your teams, the speed you can gain on your product development, the delight it brings to your users… And at some point, it won’t be only a whim of your product team.
All in all, those advice are to be taken with a grain of salt: in some cases, the business context is such that you need to make some concessions on your product principles. A new competitor can emerge, a new law can pass, a marketing opportunity will emerge overnight; and you need to stay smart to take those signals into account and not be a stubborn PM who always say no to any business request.