No Is Not a 4 Letter Word
Well, maybe when you need to scream it, it is
Imagine this scenario. You are a product manager in charge of a companies flagship mobile application. You have worked tirelessly to introduce features based on metrics, data, and analysis that have increased your user growth, engagement, revenue and active use exponentially. You understand the users, their behaviors and the triggers in the application to elicit the reactions you want to move the numbers to meet your goals. Your team is solid, stable and have rallied around you and your strategy, working long hours and weekends to deliver. You are managing the shit out of your product.
Suddenly, you are called into a massive cross-functional team meeting that you only recently found out about. There is a new company strategy being discussed that would have massive implications on your work and the team if executed as discussed in the meeting. You can see it — a waterfall approach without any input from you or your team has been in play for some time. What do you do?
Scary right? It has happened to the best product managers at the best companies all over the globe. There isn’t a simple solution but there is one that I find works for some — dial it up or down accordingly based on your intra-company politics. “Although I see the value in the strategy and company direction, we would need to make these decisions through testing and make sure the data proves our new mission before we implement at any large scale”. You could also just say “No”. This is the prime example of an organization that doesn’t respect the product model, how it works and the benefits of its use.
The reason why this is important and why you need to stand your ground on these matters is because the product model doesn’t work if everyone isn’t on board. Here is how the same situation would have happened in an organization that respected the model.
You and your core team would be invited to high-level strategy discussions early on to help guide potential changes and give important input to help guide an overall strategy shift (or stop it entirely). You would then work with that team on small scale tests, prototypes, user research and market insights to see if changes that are being proposed would work. This would allow you to see that parts of the strategy that could be beneficial to your users based on actual feedback and not conference room assumptions. Final decisions on the products feature set based on the strategy shift are yours.
Not as scary.
