Jokes about product management that are not jokes
5 minutes of reflection, humour and possibly a desire to change things for better.
Product world is exciting and chaotic, we know it.
Raise you hand, if you have caught yourself in a meeting where 10 stakeholders (so-called “expensive meetings”) are having a discussion on the next right move or the next right decision to make. And you realised that all the chatter in the virtual room (because these days we do zoom calls only) is losing its sense. Either too many cooks or too little time, in any case it feels there is not enough air to breathe and you question your role in the company and the product development.
That happened to me not once.
It is annoying and scarring because we all try to be user-centric and product-driven, but businesses run long only because they are capable of making money.
In that pursuit of financial gains companies forget the “why”, the reason they have come that far and what lead them there. It becomes more about squeezing out resources than delivering a user value.
Sure, it is unavoidable for a company that wants to grow and scale. But those companies forget that the price they might pay for it is too high.
Users sense ignorance and superficial attitude very easily. And they turn away from products that are mistreating them or robbing them for no value provided.
In all of that I want to challenge you (and myself) to still fight for the truth and the best experience we can create for those that come to our platforms. Let’s take a look at situations where jokes we make about product development are not jokes at all.
“Let’s do like they did” — competition obsession
It really seems to me that in some companies chasing competition turns into an obsession. It is similar to how we use Instagram these days — developing depression and anxiety by looking into seemingly “perfect” accounts and drowning in self-criticism and pain for not being able to live “that” life.
Though no one wants to admit the ugly truth — when we compare to someone or something, we compare to the picture, an image that is available for us to see. We see as much as we are allowed to.
That is the problem. We start to dwell on what other companies have and start to simply copy them.
It can begin small with using similar colours or UI elements, but can end with copying feature or strategic decisions which can have a drastic effect on the whole company success.
There is no universal path to success. Each company takes a unique way and it is highly dangerous to assume that someone else’s success can be reached by taking exactly the same steps.
It is equally harmful to deny the importance of healthy competition, where one company can learn from another, where one’s discovery can inspires and motivate other players to go for innovation and take more risks, and etc. But that is all in right amounts and norms.
When we become obsessed with others’, this is when we make the mistake. Don’t spend the time on watching others. In fact, like race horses having blinkers on their eyes (to not be distracted by noise and not seeing other participants around them) run towards their goal and run as confidently and vigorously as they can. Copy paste that attitude.
“I will put it in the backlog” — never seen again
Backlog… a place where tickets get lost and forgotten. If you are a product manager, you know how it goes. People come to you with great ideas and you truly think they are great, but they don’t fit the current strategy, they don’t contribute to the OKRs, there is simply no capacity and many more.
What do you do?
You say “I will put it in the backlog and make sure, when the time is right, we will get to work on it.”
The time very rarely comes. Prioritisation of the backlog is a very tedious and hard work. Where one has to consider company priorities, future objective, top down projects, external requests, customer wishes, and many more.
There are plenty of prioritisation methods, but it it worth to mention that although it help greatly to put things into something that one can vulnerably call “order”, the top of the list is still going to be given to the most urgent and justifiable from business point of view topics.
We don’t need to be naive here. We know that in order to push for a topic or idea it has to have a positive (and desirably very noticeable) impact on the main company metrics. Because of that many of UI improvement tasks, small bug fixes, little adjustments will probably not be worked on. Unless you have a working student or a new hire that needs to start with something.
So don’t judge too hard a product manager that seemed to like your idea but never managed to work on it, there are way more pieces in that puzzle that is hard to see from the outside.
“We will learn when it’s live” — far from user-centric
Life is circumstantial and we know that predicting it is a waste of time. And it can happen that all of a sudden there is a big project with high level of urgency that comes down from the top management with a deadline attached to it. I am sure, it is familiar.
In a perfect world, this doesn’t happen. And if the leadership wants to contribute with an idea, then that idea, like any other, has to go through stages of development — research, testing, iterating on the test results again and again, only then releasing. If the user value is not validated, then it is not a big deal that idea is coming from the CEO, it shall not be developed.
That pretty much happens never.
In reality, we end up taking upon the initiative, moving all the ongoing projects to later and trying to squeeze all the work into the defined deadline.
It does many times feel like pushing an elephant into a narrow door, like on the picture.
The dark side of such approach is most of these initiatives are revenue driven (and that have fear of staying behind the competition rooted in there). What it does is quite sad to observe.
- It jeopardises the current workflow — tasks and projects have to be frozen and stay pending until there are free hands to pick them up again. And you can only imagine how hard it is for a developer to drop the task and come back to it in a month.
- It stresses the engineering team — developers are very user-centric in their nature, they don’t really tolerate the pursuit of money and chasing competition, they dislike the shortcuts and disruption of their work. That creates tension between them and a product manager who has to coordinate between the team and the management. Nothing good comes out of it.
- The same falls true for the designer (if there is a need for one) — since those top-down initiatives are not really putting the user first, designing with that in mind neither excites, nor motivates the designers to do their job.
- And last but not the least, it hurts the testing process. Because there is a deadline, there is no time to test and iterate to come to a better solution. Painful to admit, but in those initiatives there may not even be a well defined user problem. And that goes very much against the true purpose of product development which is about solving user problems.
When we don’t test, we risk to delivery something that not only no one needs, but can also backlash with negative feedback from the users.
All in all, we shall be open for discussion and provide all the necessary information to the stakeholders with a lot of power but little knowledge of daily business, risks and struggles that such initiatives can bring.
To sum all this up, I would like to refer to the point that Melissa Perri is making in her book “Escaping the Build Trap: How Effective Product Management Creates Real Value” — as long as we operate in the environment where we are not output-driven, but rather recognised, appraised and appreciated for the outcomes achieved, we can be sure that we are working towards delivering true value to the users.
In such companies, product development is not about delivering endless number of worthless features that no one needs, it is about continuously searching and identifying user problems and focusing on solving them. Then releasing without testing is not a problem, tickets are not lost in the backlogs because they are created with a purpose, and looking after competition becomes a secondary activity because everyones’ interest is focused on their company’s success.
