Product Management’s Three Thinking Hats
Three concerns to bear in mind, three roles to play
Dr. Edward de Bono introduced the Six Thinking Hats concept to help business managers learn how to introduce more creativity and innovation to their work by using different modes of thinking. I’ve seen similar tools for other problem domains, for example reviewing a piece you’ve written using different mindsets, once for spelling, another time for grammar, yet again for clarity and perhaps finally for whether it makes the impact you wanted.
Early in my product management career, I came across a similar concept for product managers to use. It was a little simpler as it covered three main concerns or three roles the product manager could play when considering product changes. Marty Cagan first introduced it in his book Inspired: How To Create Products Customers Love
The point is that when considering any product feature you need to understand whether it is:
- Valuable — is this something worth building because it advances your product strategy and delivers value (often through sales)?
- Usable — will your users find it easy to use, does it make their lives easier or harder, will they even understand how it can help them?
- Feasible — can your organization/team feasibly build this within the timeframe and budget that keeps it valuable?
There is an obvious need for the product manager to be able to cover all three concerns, kind of like this:
But one of the first things you learn as a product manager is that these are roles that need to be played, and on a cross-functional team you can bring others in to lend their expertise to those roles. You put on the hat for the role you are playing in a given meeting or situation (you don’t literally put on a hat … although you could).
In cross-functional teams
In a cross-functional team meeting, you would typically see the product manager playing the Valuable role, while a UX or BA expert might play the Usable role and one or more developers would play the Feasible role. I would always explain this to my teams, and the roles are not hard and fast — there can be good reasons why anyone might play the other two roles.
One reason why you want to expose your developers to user experience research and testing (see The anatomy of a UX revolution inside an organization) is that it helps them play the Usable role when they are in the midst of delivering a story. It’s also why I think product managers should strive to understand the technical architecture and concerns of their product, so they can play the Feasible role when there isn’t a developer around.
Beyond the product team
One of the things I struggled with when dealing with executive product discussions was that they typically stepped into the Valuable or Usable roles in any discussion about a product feature or strategy. It felt like they doubted my ability to select product changes that were strategically sound. But it wasn’t that they didn’t value my input to that concern so much as they understood those concerns better than the Feasible.
To prepare for those discussions I had to make sure I had enough of the Valuable/Usable “why” thinking detailed for those meetings so I could bring the executives back to our market discovery or user research findings, rather than allowing their most recent customer interaction to guide the conversation (for more about handling the HiPPO, Highest Paid Person’s Opinion, see articles like this one).
This meant that with executives I typically found myself playing the Feasible role. This was also because there usually wasn’t a developer representative in a lot of those meetings. So I made sure I knew what our technical concerns were before any executive meeting.
I did have to watch out that I wasn’t doing too good a job mirroring technical concerns to the executives. My CEO at one point joked I was the “No” man in every meeting because I would point out technical capacity limits. Some of that I got around by having my development manager on the same page before the meeting, so they could confidently represent the team’s capacity when the CEO wanted not “A or B”, but rather “A and B, and what about C too?” That turned out to be important because they often turned up without a clear idea of capacity, and saying “I’ll go see if we can do that” is often remembered by executives as “yes, of course, we can do that”.
It’s just a mental model
This stuff isn’t rocket science, it’s a mental model of product management. Discussing the three hats doesn’t mean that every meeting needs to consider all three aspects. It’s OK to discuss removing technical debt and spending the entire time looking at feasibility (although it sells better to executives if you can find a way you can improve the value and/or usability at the same time).
Building a repertoire of mental models is important in product management because they help hone your expertise, make you more efficient at decision making and make it easier to share ideas with your cross-functional team. They are living things that should grow and evolve as your understanding of product management grows and evolves.
For another interesting take on these three concerns, João Craveiro did a great piece on this two years ago called Marty meets Martin: connecting the two triads of Product Management. His approach to it is a little different but marries it nicely with Martin Eriksson’s UX/Tech/Business Venn diagram.
