I would like to offer you an analogy:
A product manager is best compared to Oscar Diggs, or - for those of us less familiar with the literary works of L. Frank Baum - the Wizard of Oz.
They, like the sorcerer that rules over the land of Oz, possess the powerful ability to bestow upon their followers whatever they seek most.
Instead of brains, heart, or ruby slippers, the product manager delivers detail-oriented decision making, speed to market, and – sometimes in the case of CRUD apps – ruby codebases.
The real similarity between the two, however, comes from the illusion* of being “great and powerful.”
* Do not misconstrue the word “illusion” to mean that they are not capable of competent power and leadership, though.
While the wizard delivered on his promises of betterment for the intrepid gang of anthropomorphized characters and a girl from Kansas, he first attempted to do so with bluster and parlor tricks that proved to be no more than show.
His true power was demonstrated after the smoke and mirrors disappeared and he was revealed to be no more than an old man with a penchant for deception. After the curtain dropped and Dorothy and her friends saw his true form, he realized that as long as he could deliver on his promises, they thought no less of him and were happy in their decision to pursue him in the face of danger.
The product manager may also make this same mistake when captaining a team of developers, designers, and marketers: assuming that as the lead coordinator of a massive undertaking, a product manager should be infallible and steadfast in every decision and proclamation they make.
This could not be further from the truth: as demonstrating the ability to analyze all angles of a bigger picture, and possibly pivot as a result, is one of the greatest assets a product manager can have.
That is not to say that a good product manager shouldn’t do as much research as possible before making decisions. Pivoting can be costly and demoralizing if done for the wrong reasons. But a good product manager must understand when to realize that the course their product is on may not be the correct one.
The greatest leaders know when to show humility.
While the analogy above should be taken with the world’s largest grain of salt, there is something to take away from it. Don’t lead under the illusion of infallibility. Garner respect from the results of your actions, not the means by which they are undertaken.
In order to aid you in the pursuit of well-thought-out decisions and user-minded development, we have put together a helpful guide on how to drop a metaphorical house on the biggest challenges that you face in your duties as a product manager. Let’s take a peek behind the curtain, and look at the four biggest challenges that we feel product managers will encounter.
1. Users who hate change
It goes without saying that human beings are prone to side with whatever makes them feel the most comfortable. Not all of us are averse to change or trying new things, but when the warm blanket of familiarity is available, we generally side with what we know.
Let’s say we’re going out for dinner and I give you a choice between two Chinese restaurants (in this hypothetical, you and I are quite close friends.). One is a brand new restaurant that you’ve never heard of, and the other is the one you’ve been going to for years. It’s not out of the realm of possibility that you’ll decide to go with the new restaurant, but you’re probably much more likely to want to dine at the restaurant you know you like already. They do have killer Mu-Shu pork after all.
The same can be said for integrations in your application.
Don’t assume that your eventual users will blindly go with an integration they don’t already know and love (or at least like).
If you strong-arm your users into using Dropbox to access cloud storage within your product when many of them are deeply invested in using Box or Google Drive, you’ll lose a lot of users at the initial stages of adoption because they will probably be more likely to seek out a competitor that has provided integration to their favorite cloud storage provider.
Do not let your own preferences dictate the integrations that you will build into your application. Make sure you do as much market research as possible before beginning the process of having your developers start on integrations and, if possible, use something like a unified API to provide your users with as many possible options as are available.
Never underestimate a user’s aversion to being forced into signing up for a new service.
2. Insufficient research
Hopefully, you’ve done your research.
As you put together your product roadmap, base your decisions on market research as much as possible. This seems obvious, but as many product managers will tell you, they often feel forced into features from stakeholders or incorporating technologies based on their current popularity in the industry.
In other words, if it doesn’t call for Blockchain, don’t use Blockchain (or whatever else is ‘hot’ right now in the industry).
Market validation should be one of your first priorities when beginning work on your product roadmap. Building a product that no one actually needs is essentially signing your own application’s death certificate before the work has even started. Take your time in the initial stages of planning to gather as much data as possible and make sure your decisions are weighted with this data in mind. Innovation will always be rewarded when determining the next big thing in software applications, but never lose sight of the value being presented along with that innovation.
To back this up as a major issue facing product managers, Mind The Product’s 2016 survey of product managers asked the question “What’s your #1 single biggest product management challenge right now?”
The answers they received illustrated that 62% of PMs reported the greatest challenge they faced was prioritizing the roadmap without market research.
The answers they received illustrated that 62% of PMs reported the greatest challenge they faced was prioritizing the roadmap without market research.
Chart Source: Mind The Product™
In other words, do your homework. The market should dictate your priorities, not your internal stakeholders.
3. Being too “hands off”
After you’ve done your homework and laid out an inspiring product roadmap, the next step is to bring that vision to life. Many of the best product managers trip up on this step, as it requires so much constant communication between teams and a precise division of labor.
This is where the role of the product manager often calls for a high level of micro-management.
However, let’s get it out of the way right now: You are not a helicopter parent and your developers are not your children. You do not need to dot every i and cross every t on the long and arduous road to market.
It also doesn’t mean that you should pair-program with their developers, or even listen in on every stand up that occurs during the course of development. What you should make sure of is that you are plugged into the day-to-day work being done to bring the product’s vision to market.
You have to know who is working on what and when they will be done and ready to pass it off to the next step in the development cycle.
It is far too easy to run into major roadblocks when you rely on each and every person working on your application to know exactly what they should be doing at all times.
Your developers are rockstars. They are amazing at what they do. Don’t force them into a situation where they have to focus their attention too far outside of the scope of the job at hand. Worrying about the big picture is your job. Let them build their features and move on to the next without having the added pressure of knowing what the progress of every other developer or team is.
It is not enough to lay out a well-thought-out product roadmap and then wash your hands of the responsibility of seeing it through. All the research and attentive decisions will be for naught if your teams can’t take a calculated and disciplined approach to build the application.
Make it easier on yourself and them by being the one to calculate and plan for that approach.
4. Not knowing when to pivot
Like I initially covered in the introduction to this guide, one of the hardest challenges you will face as a product manager is knowing when and if a pivot is a good choice. There is no ‘right’ or ‘wrong’ time to make a change in your development course, as each codebase will have its own unique needs and reasons that it may or may not be a correct choice.
But: holding steadfast to a choice made in the roadmap at the detriment of your product will sink your ship faster than you can say, “Iceberg!”
Ideally, you won’t run into this issue. In a perfect world, every choice that you decided to make in the planning stages of your application will come to fruition and will do so in a reasonable timeframe.
But what should you do if they don’t?
All too often, we’ve heard of the product manager encouraging their developers to persist through the problems, bugs, and general issues that a doomed feature may present in its construction; fighting the inevitable to drag on development for months to years after the market release date has come and passed.
It is not an admission of wrong-doing to know when it’s time to throw in the towel. We all know successful stories of pivoting, whether we remember them or not.
Netflix used to mail DVDs as a service. Twitter first launched as a platform for podcasters to connect with their listeners. Starbucks only sold coffee beans and coffee-related products when they first launched. I’m pretty sure we all know how those pivots went for these companies. (Hint: Very well.)
Great product managers really shine by deciding when a feature should be scrapped or integration should be replaced with another. The end goal of any application’s development should not be perfection–it should be deployment. There will always be new issues that arise after release that will dictate new strategies to account for them, so getting too married to any decision you’ve made in the planning stages can only hinder your progress if you don’t know the right time to re-evaluate them.
Time to market is paramount when building software. Your users will never know about the blood, sweat, and tears that went into a specific feature, just like they won’t know if your product releases without it. An application that releases with 75% of the initially planned features is always better than a product with 100% that never does.
Your initial ideas are just that. Ideas. They are not set in stone.
Don’t ever let the longing for perfection be the thing that keeps your users from a usable and helpful application. Because, at the end of the day, no one but you and your team will know that those ideas ever existed.
These 4 challenges are by no means a laundry list of the issues and problems you will face as a product manager in the course of bringing about the fruits of your labor.
Working to build a consistent and personalized product experience is also key to delivering a worthwhile and usable product. Engaging and retaining your users in a smart and calculated way will dictate the success of your app after you are ready to release it. Figuring out the best way to monetize your application will inevitably require some of your hardest work.
But these are all fluid problems. They can change as time goes on. You can come back to them over and over and apply any new information or data you’ve ascertained since the last time you visited them, giving you more insight into making calculated decisions to tackle them.
The 4 challenges we’ve covered in this guide should be issues you give forethought to when going into the initial stages of planning out your product roadmap. If you give yourself enough time to plan while also cutting yourself enough slack when you might need it, you’ll be as helpful and productive a product manager as anyone that came before you.
Just remember to drop the curtain and minimize the theatrics.
Your future users will thank you.