In what many Product Managers might consider an average week, I made three classic product decisions that would make Marty Cagan smile.
After spending more than 10 years in the Product Manager role, I can't actually recall an average week. Perhaps we are attracted to the role for that reason - because it is unpredictable. If it's not changing requirements at one end, then it might be new technology "insights" at the other. The cast of characters we will work with week to week is variable too as new customer prospects enter the picture and compete for attention with existing customers that have their own unending wish lists.
To be successful, Product Managers must be able to navigate these challenges week to week. Good mental frameworks are essential to making sound decisions and to maintaining credibility over time. When you are feeling overwhelmed, however, you may find it helpful to confront the tough product decisions with this deceptively simple approach.
What drove these decisions
Most Product Managers have run across Marty Cagan’s book Inspired - How to Create Products Customers Love. I consider it a must read for anyone in the general vicinity of Product Management.
Among the many gems in this book, Cagan identifies three fundamentals ways to validate your product decisions: determine what's valuable for your customers, what is usable by your users (not always the same personas as the actual buyer), and what is feasible given the resources you have at your disposal.
These are not mutually exclusive. Whether you're early in your product discovery or tackling a thorny issue for customer 10,001, you need to land on a resolution that best balances these three forces in order to move forward.
Over time, with practice, this starts to become instinctual and woven into your daily PM routine. You may even be surprised, as I was, in reflecting back on an "average" week that there is a very valid reason for why many of your product decisions had turned out so well.
The Three Product Decisions: Determine what was most valuable for our customers, what was most usable by our end users, and what was most feasible according to our Engineering team.
In this particular week, I made and can highlight three, separate decisions for our product and ultimately, for the future success of our company. What makes these particular decisions stand out from the dozens I made is that each was particularly punctuated by one of Cagan's three principles.
Plan of attack
Decision 1 - What’s MOST Valuable
The team had been exploring how we could redesign an existing product feature and was driving that discussion using input we had gathered from rounds of customer testing. As we unwound the different pieces of the story, we revealed the true underlying complexity and ultimately determined that it was too big to tackle all at once.
I decided to break up the larger story into 3 smaller, discrete pieces and sequence the resulting work to deliver incremental improvements over time - a common problem solving approach. But this decision made it much easier for the team to single out which piece would ultimately provide the most value to our customers and, all other dependencies aside, which we would schedule first.
Decision 2 - What’s MOST Usable
In a separate thread, the team was reviewing feedback we received after showing a proposed new design to some of our end users. We had been planning to introduce a completely new design to address some known usability problems with a particularly popular feature.
Few things are more influential for a Product Manager than hearing end users describe how they use, or would use your product to do their job. It was precisely this feedback, straight from our users' mouths, that prompted me to scale back the new design. It turns out that we had been overthinking the problem and could actually deliver a more usable solution with fewer changes (i.e. less work on our end).
Decision 3 - What’s MOST Feasible
Software Engineers like to explore new technology. I know this from having spent the first 10 years of my career as an enterprise software developer. In this current company, I had been having conversations with the Engineering team about how we would tackle a large, scale-related challenge deep in the bowels of the platform (not customer facing). The team had fully researched and had achieved some early success with an alternative technology that seemed applicable for this particular problem.
So, in this very same week, we had come to a point where I needed to make the call on whether to schedule the scale-related work for an upcoming release. And while the Engineering team was convinced the technology would ultimately solve our challenge, we were not jointly confident in our collective ability to proceed safely. Because of this uncertainty around technical feasibility, I swapped out the work from the release, postponing it for a later date after more research and experimentation could be done.
As I mentioned at the start, these types of decisions are commonplace in a Product Manager's average week: problem decomposition to help reveal customer value, user testing to help reveal usability concerns, and ongoing engineering R&D to help reveal feasibility limitations. Still, it never hurts to return to some of the core product principles to remind us all why we are here. And thank you Marty Cagan for all your contributions, and for inspiring me.