Your product team has been tasked with a particular project; perhaps the business identified an important business metric that it wants improved, perhaps it thinks that solving a particular user problem will help move the organisation forward. Either way, your team now needs to decide how to kick off and deliver this new project. Instructions are probably vague, knowledge about the problem space is too, so how do you get started, and more importantly how do you make sure you end up being successful?

It is great when product teams are given the autonomy to decide how they approach projects but this freedom brings with it responsibility to make the best use of available time for the benefit of both their users and the organisation they form part of. Product Managers can influence the likelihood of success of their team by embodying the two complementary mindsets of Curiosity and Courage, and ensuring the team adopts them as their own.

I wonder why Curiosity is important?

That is a great question! You have no reason to take my word for it! Perhaps you have been getting along just fine without questioning everything, but what if you could do even better, what if the lenses through which you view the world could do with some adjustment?

Simple; You are probably not your product’s target market! You probably work with others that have greatly similar world views (in spite of the hard work your organisation is hopefully doing to increase its diversity). Finally, you most certainly are not omniscient, so even if you have worked hard to mitigate the above, there is always something you don’t know.

Curiosity is often synonymous with better understanding your target users. Product Managers at Prezi are lucky to be paired with excellent User Experience Researchers in each product team to help build empathy and answer questions. If you don’t have access to experts, don’t despair! Information on doing better product discovery is everywhere, and introducing even basic practices can bring amazing results.

Don’t limit your curiosity to user empathy. Encourage your engineers to be curious about how they approach problems and encourage your designers to think about new patterns for solving a problem. Many teams can claim to be doing a fairly good job of being curious in these situations. I find it easiest to fall short in what comes next. You have researched your user, tried out novel ideas to solve what you discover in design and in technology, you push out your amazing solution to the world, then you turn your back and walk away.

Curiosity becomes most important once you actually release something. The solution you released was probably suboptimal if not outright wrong. Unfortunately it is common to see teams attempt to solve this by being even more rigorous upfront. More than 15 years after the Agile Manifesto was signed, we still front load months of research, then spend months delivering and never have the time to revisit what we have built.

It sounds a lot like the tools of curiosity can so easily lead to dysfunction. I have experienced this, spent way too long on research and never returned to what was delivered. It might look like curiosity, but it is actually procrastination. Introspecting on why this happens, it feels like procrastination through discovery is a symptom of our fear of the unknown.

I think Courage can help!

Courage is interestingly a mindset we strongly associate with traditional leadership but one which doesn’t get too much attention when discussing product team leadership.

A curious product team will have gathered lots of context about the world, rules governing the stimuli you have observed and reactions you think they cause. You form different hypotheses about what to do, but which one do you pick? Getting started can be really hard, often paralysing.

When I started to learn about product discovery, I assumed that somebody, somewhere had the secret for choosing the right idea to work on, that the next book would contain a formula for always making the right choice on what to build. When we put the company’s money, our colleagues’ time, and perhaps our own reputation on the line, it is easy to feel the need for that kind of security. A process or magic spreadsheet we can point to and blame. I think that convincing ourselves that there is any way to know what is right, and putting all our chips on the sure win, is the most irresponsible thing a Product Manager can do.

We are frequently seen as the representatives of “the business” to our teams so let’s take a lesson from the business world: A serious investor would never think about putting all their money on a single idea. They budget to ensure they have enough smaller amounts of money to split across multiple investments. Probabilistically, a single bet means we are either right or wrong (given our misplaced self-confidence, we are certain it will be the former), but multiple bets means we will most likely be wrong a couple of times. Our egos combined with the way we set up organisations mean that we focus more on the likelihood of being caught wrong than the increased likelihood of being right at least once. However, if we budgeted correctly, winning even once means that we can now place our next bets informed by what we now know (of course applying the same tactic to this new refined space). It takes courage to plan to be wrong.

We also have a tendency to strive for perfection. This insatiable need can drive us to constantly improve, but can also hold us back from moving forward and getting value from the time and energy we have invested so far. We have an obligation to our users and our organisation to make things better. A solution you can provide today, that improves people’s current way of doing things, is better than a perfect solution that may never materialise. Your duty to release is more important than a perfect portfolio. It takes courage to accept imperfection.

The lessons an imperfect solution provide us can be so much deeper than researching hypothetical use cases. Who really uses your product, how are they using it, where does it fall short? There is ample information to help you satiate your curiosity after releasing, but you need to take the first step into the dark (or at least badly illuminated) to access it.

Of course, courage comes with its dysfunctions too. It is great to push forward, but if you are always blindly charging forward, never taking time to look around and assess how you are doing, it is no longer courage that you are exhibiting. You are at best, being over confident, or at worst, in a state of panic. What can help you avoid going overboard? You got it, a healthy dose of curiosity.

So how does this all come together? Disciplines aligned with discovery and delivery “modes” of product development have done a lot to provide tools to deepen our capabilities in each of these areas. As a product manager, your job is not to treat these as modes. In fact make sure your team is never in just one at the same time. Instead embody these mindsets, move your team forward with courage and keep them curious!