Disagree but Dissect
Making successfully products isn’t an easy job. Everyone in the team has their own opinion. Designers, marketing team, developers, content team everyone wants what is best for the customer. Everyone thinks they know what is best for their customers.There is so much subjectivity involved that my fellow product manager has a term for it “Analysis Paralysis”. Everyone has an opinion and hence the product doesn’t move.
If it moves you try to keep everyone happy and create something which is not necessarily good for the customer. If the people who make & market the product aren’t happy, how will the product work properly? I have seen this happening so many times. During Analysis Paralysis, usually the person with biggest title vetoes his point of view and other are forced to make a product which they think won’t work. Stakeholders just do what is being told and do nothing else.
Here, the missing juice is “Context”. Anyone can do it and all they need to do is to stand up and try to understand what everyone’s point of view is, where is it coming from, where did they get insights to have those view, did they see any data, did any of their friends do it, did they read it somewhere, do they think it’s reasonable or logical. Best way to do this is to write everything on Miro or whiteboard and talk about each person’s underlining understanding and knowledge. Make everyone feel heard. It will take time but it increase transparency and trust in team. When everything is on whiteboard, this is where the magic happens. Everyone can draw parallels and understand at what places everyone agrees and fundamentally differs.
I know this is too much theory so let’s jump to an example. In this example, I failed to provide context to my team to build a feature but later I did learned how I could have done it.
I created a product which provided information to new users to learn how to invest. I wanted to created an in app content tool which was personalised enough to ask user their salary and then suggest how much to save and invest. It felt logical to me to build. But this would require more tech effort so the team decide to make a generic tool which craters to everyone without personalisation.
I could have easily tested the hypothesis that personalisation work with the target audience by writing blog content for different salary ranges and compared it’s efficacy against a blog with generic blog.
This would have given context on how users interact with personalised content and my team would have trusted me to invest more tech bandwidth.
Having objective data around user behavior and our ability to equate them next to the fundamental difference, stakeholder tends to change their views. Given enough time to talk and make their case.
In the end some people will still not agree and this is where we write down the difference in the strategy document and promise to revisit it after the product is live. This way everyone learn something new. What was decided, what happened, what should we do next.
