Recently, my team and I spent some time visiting Ninja Van’s warehouse and hubs in Makati, Manila. We managed to spend a meaningful proportion of our time visiting our operational centers, observing some of the processes critical to our last mile service. Damien, one of our young product managers came up to me at the end of an intense day in the field and exclaimed:
“We need to spend more time on the ground, there is just so much to learn and so much to observe and so much to understand”.
It seems so obvious to any product manager that understanding the problem to be solved in person, in situ, with actual end users is a must-do. Yet it also astounds me that for many of us, this is not a natural, instinctual first-choice. I pondered why and upon reflection identified human/work patterns that contribute to this mindset and are prevalent in most of us whether we realize it or not.
The Engineering Suck
Solutioning for problems is an addictive activity. Product managers are schooled to build lean, deploy MVPs or MUPs, but that only means the build is never complete and you can very easily get sucked into the black hole of development iterations. You get comfortable behind your desk, you get chummy with your engineering buddies and you decide you never want to leave your office. Many of us get ‘sucked’ into this state of mind that we find shortcuts and lean on ‘second hand information’ or ‘conference calls’ to try to get the insights we know we need but hope we can get without investing in really getting it. We avoid actual user research with indirect user research not because its what the product needs but because we get complacent and its ‘good enough’.
2. The Truth Sometimes Hurts
Product managers pride in solving problems. Occasionally, we end up under-scoping a solution or mess up and get it all wrong, ending up with solutions that don’t have the intended impact or effect we originally desired. We would have already spent a good amount of engineering resources and our own time and effort to eventually get nowhere. Its easy to discount the problem, blame it on improper application of our solution or evolving requirements. Our egos get in the way and we blind ourselves to the issues at hand, choosing to avoid the problems instead of meeting them head on. This may sound extreme, but I believe many of us act this way in a subconscious fashion. User research is the fastest way to unravel and expose limitations and flaws in our products and in many cases we avoid them rather than embrace them as an opportunity and a step to get us close to the real solution required.
3. The TODO List Trap
I often share with the product managers in my team that I believe the GSD (Get Shit Done) mentality is an important criteria that I look for in product managers. I believe that building shipping cadence (i.e. actually executing and deploying product) in a consistent rhythmic fashion is a critical sign that a product manager is effective in his role. On the product managers side of the coin, this frequency of releases provides for a sense of satisfaction which over time translates to effectiveness and personal impact. Product managers feel good about themselves and in many cases the key result mutates from the KPI originally targeted to simply the number of builds he deploys. This ‘currency’ of velocity of shipping becomes the focus of the product manager instead of focusing on whether the builds actually solves the problems. This mental pattern is something I also refer to as the TODO list trap.
As product managers, It is important to remind ourselves that our responsibilities lie beyond the release notes.
Its important that we constantly remind ourselves that our job doesn’t end when we’ve executed and deployed a build. This statement seems like something super obvious, yet we should recognize that the human psyche sometimes leads us to form bad habits.
“It is the follow through that makes the great difference between ultimate success and failure because it is so easy to stop” — Charles Kettering