Your Super Power: Not Knowing Everything
How Much Should I Understand?
A friend, who’s recently become a product manager, asked me that recently. She’d inherited a technical product where the engineers already had a view of the direction and deliverables required. Even though it had been broken into phases, each phase was large in scope and involved a number of unconscious assumptions. During planning workshops the engineers were mentioning a lot of tools, methods, processes and concepts that were unfamiliar to her. Lizzie found herself reading a lot of detailed, technical material and wondering how much she really needed to understand. As a product manager, what should her role on the team be? How could she best add value?
It’s easy to feel like a fraud in these situations. To feel like you don’t deserve to be there and that you’ll be rumbled at any moment. This is a well-known phenomenon called imposter syndrome, and even the first man on the moon, Neil Armstrong, experienced it!
The truth is that as a product manager you’re not supposed to know everything. You’re the conductor; you’re not expected to be able to play every instrument. Your job is to have a feel for how the piece should sound as a whole, and to help the musicians interpret the music. And then, to live and breathe every note with them. I would argue that, no matter how experienced a product manager becomes, the sign of a good one is a healthy sense of imposter syndrome.
I Have Questions and I’m not Afraid to use Them
The power of not knowing everything is that it enables you to ask questions and challenge assumptions. It helps you as product manager to avoid the traps of jumping to conclusions and rushing to a solution. It gives you the strength to fully explore the problem. Dave Wascha recommends starting the habit of asking questions early:
“Relish being the new person, take advantage of it, and ask questions to the point of being annoying”
Building up a detailed knowledge of your product is obviously encouraged but so is having an inquisitive mindset. With experience, you’ll learn when is best to ask questions and when is best to let the team delve into the details, but keeping the product goal in mind helps with this.
The key for Lizzie in the planning sessions was to keep everybody focused on the objective and to be clear on the scope. Rather than asking about the technical details, ask questions to guide the engineers, like “why do we need that?”, “would we deliver value without this?”, “what does that enable us to achieve?”, “if we had half the time, what could we get away with not building?”, and so on.
Asking questions about the value of the components (rather than their function) allows you to build a picture of how they will help you move towards your product’s vision. You’ll also get a sense for where the largest chunk of value is. At this point, if you feel like you need to change direction slightly or reduce the scope of the first deliverable, you can run a “five whys” exercise with the team. This not only helps you break it down but brings the whole team along with you, so that everyone understands the rationale (this is especially important if the project is already in progress). The aim is to take each component and ask why you need it. Then, for each of the answers given, ask “why” again, until you’ve reached the root motives. Now work out what the minimum, independent deliverables are. Do they need to be done in a specific order or can they be worked on in parallel? Which pieces add value incrementally (and which need to be delivered together)?
Once Lizzie’s team had broken everything down into discrete blocks of value and decided which they would tackle first, her tech lead wondered whether “this would be impressive enough for our CTO”. Everyone loves a big, dramatic reveal but a big-bang delivery is risky. Anything could prevent you from completing it, and even if you do complete it there’s no guarantee it will be successful. The question to ask is “will we deliver any value (or learn anything valuable) if we release this, smaller, piece”? As long as you focus on that, it’s always better to be constantly shipping, putting your product in front of people, learning from them, and adapting as you go. Don’t forget this is just step 1 of many, and if priorities change in the future, everybody can still feel good about releasing something useful.
It might be helpful to think of this in terms of Maslow’s Hierarchy of [Product] Needs. Focus on the most fundamental deliverables, the ones that are crucial to achieving your product vision. Once you have this foundational layer of value in place you can start building the next layer of value in the pyramid. Each layer adding more and more sophistication, as you move from a basic solution of the core problem into optimisation and cutting-edge functionality that results in people having a deep, personal connection with your product.
And it all begins by asking a few simple questions.
Want to improve your A/B tests?
Check out my new site: ExperimentationHub.com for free tools and advice to help you run better experiments and become more confident in your results.
This story is published in The Startup, Medium’s publication followed by over +256,410 people.
Subscribe to get the top stories here.
