Being a product manager encompasses many things; vision, organization, analysis, and communication, to name a few. But in my experience there is one universal trait that permeates almost everything a product manager does – curiosity. In the context of product management, I see curiosity as a desire to fully understand a problem from all angles, to want to gather information from a diverse range of sources, and additionally to understand how outcomes would have an impact on success.
I’ve noticed the product community has been talking about this curiosity mindset, or learning mindset, or testing mindset with greater frequency in the past few years. Lauren Gilchrist’s talk on “How to be a Scientist”and Erika Mule’s work from “Just Enough Research,” have both helped embed the concept of learning as a core skill of product teams. This understanding about a problem inquiry and curiosity needs to be seen as a key component of the product manager role.
I’ve been thinking a lot about how to approach learning as I write the Mind the Product training curriculum. Each phase of the product development lifecycle requires a slightly different type of learning mindset. Being a scientist is necessary when you’re in heavy prototyping mode, but when you’re approaching greenfield products, you need to be more expansive. Likewise when one is driving towards a release, you have to become hyper-intent on risk, and testing is not as useful.
The more I thought about it, there seemed to be three emergent mindsets that help product managers think about being curious.
These three seem best used at certain times during development, but like most things there are no clean lines between them, more of a fluid shift. Some take top priority at certain points and then move over more strongly into another circle. We are well served by Venn diagrams here at MTP, so let’s use one.
So what characterizes these mindsets? Generally the main difference between them is the scope of view that a product manager takes. They are all geared to reacting and adjusting to new information, but there are different sizes of vision occurring.
It shouldn’t surprise many people that the Explorer mindset comes into play most strongly in the discovery phrase of the product lifecycle. I thought of explorers of the old school, who were blazing a trail for equal parts science and glory. They were well-equipped, they carefully thought about the skills they would need on their exploration. They had a rough idea of what they wanted to accomplish. Their mission was to set the frame of the map and perhaps make some valuable discoveries that made people pay attention. Explorers set their eyes on the horizon, but are also constantly watching for signs of risk and danger.
When you’re not quite sure what you want to build but you have a hunch that there is a pretty big problem to be solved, you’ve stepped into this mindset. You are using your past experience and your intuition to start pointing you in a direction, and you’re meticulously gathering and cataloging data from all sources. Explorers map the terrain, take detailed samples of the environment, and try to get to know the locals. Product managers are framing your business case, analyzing macro-data and talking to potential customers.
Most importantly, this is the time to really reach big and figure out the potential of the idea. You don’t find treasure if you don’t search for it.
As the problem has becomes more and more defined, the scientist mindset makes its appearance. Once you’ve identified and properly assessed a problem as an explorer, you can begin to think about possible solutions. This is where product managers begin making bets with themselves, creating hypotheses as to what success looks like, and seeing how concepts perform against that. Solutions, concepts and features are tried and discarded at this point if they are found to not work. The scope begins to narrow and focus.
Product managers start working intensely with various fidelity prototypes, or find ways to visualize ideas for testing with the least up-front investment. Risk comes more into play as the team pays attention to the details of the experience, like usability, tone and process.
It’s also important to debrief and take stock of the findings, in order to make appropriate changes and adjustments as you move into subsequent tests.
Eventually, the answers become clearer and the experience firms up. You want to get something out the door as quickly as possible, this is not the time for being expansive, this is the focused mindset that is needed in order to push out a release. Yet despite this focus you don’t stop paying attention to incoming information and keeping an eye for unexpected obstacles.
even when you’re headed to uncertain destination, drivers still have to make constant adjustments and pay attention to the route that you’ve set forth. If a major roadblock came up, you would reroute, calculate the amount of time lost and report out on a new ETA.
The Driver mindset is about maximizing efficiency and minimizing risk on your way to the destination. Each time you do it, you improve your understanding about the process and can cycle through it faster and better.
As I stated above, these mindsets are not completely disparate. Often you have to find yourself in two learning mindsets, especially if you are doing dual track development. In my experience, a clear characteristic of a senior product manager is someone who understands which mindset is needed for a particular problem. This is not an understanding that can be achieved overnight, but it can be useful to understand these subtle shifts as you move through your career as a product manager.
Do let me know what you think. Do these mindsets apply to your work?