The short answer is, very little, especially in the tactical product development process.
As we look for the next highest-value improvement to make to our products, it is very tempting to compare our products’ offerings with those of our competitors. Lo and behold, there’s always something that our competitors are doing better than us.
“Their product is much faster than ours“, “They have more features than us“, “They’re using AI and we’re not“, “The product is cheaper than ours“.
We can go on and on and on.
It’s therefore, extremely easy for us product managers, to think that by fixing these “shortcomings”, our product will be more successful. It has to be the case, right? Our competitors have researched these features and have beat us in releasing the next best thing that our product should have.
Except that, actually, the latter is just our assumption of what’s going on on the other side of the fence.
Sure, it might be the correct assumption in some cases, but in some cases it may also be wrong. Like everyone else (us included), our competitors make their own mistakes. By relying on the assumption that our competitors are correct, we risk making the same mistakes ourselves, thus losing valuable time to work on and learning more about other changes in the product that our customers truly want.
Moreover, and more importantly, our competition’s target customers might not be exactly the same as ours. And so, in copying other products, there is a risk that we are making changes to our offering, that does not actually give additional value to our own customers.
As product managers we should not be using too much of our time trying to understand what our competitors are doing, but instead we should keep in mind that our focus needs to always remain on our customers and our target audience. By focusing on getting to know our customers inside out, and truly empathising with them, the next best thing that our product is missing, automatically becomes extremely evident. More importantly, this highly increases the chance of success of the new features that we ship.
UXPin recently held a webinar about how great products are not just about features, during which I have shared my view on the importance of understanding your customers in the process of building great products. You can listen to the recording of my presentation in the link below.
It’s Thursday afternoon. John, a Product Manager at an e-commerce platform, is preparing for tomorrow’s grooming session with the design & engineering team. One of the features that he wants the team to deliver is to allow users to compare different models of the products they’re looking for.
As the customer expert, John has spoken to his online buyers and he’s done the necessary research before he came to the conclusion that users want this feature. The evidence is there. Users want to compare products. The team’s going to deliver and the users are going to love them for it. Innovation is John’s middle name.
And so John starts writing the user story:
As an online e-commerce portal user,I want to have a Compare Features button in the product details view, to compare the specifications of the product with another product that I select,Such that I can choose the best product for my needs.
And so, on the following day, the designers and the engineers are discussing how to best implement a:
“Compare Features” button
In the product details view
To Compare the specifications of the product
Comparing the product with another product that the user wants to compare with
The problem with the example above, is that John has prescribed the near-exact implementation of the feature to the designers and engineers, without going through the thought process that designers and engineers would have gone through themselves. And since the thought processes of designers and engineers are very specialised and focused on their areas of expertise, it is highly likely that the product manager will have missed out on asking crucial questions that would have led to a much better and more innovative product to be built.
John has inadvertently turned the designer into a design secretary and the engineers into programmers. Innovation is no longer his middle name.
Instead, if John had focused on providing the crucial context about the customers and their objectives, the engineers and designers would not have been immediately biased towards the prescribed solution, but instead would have explored other possible solutions to the problem that John might not have thought of.
Let’s look at an example of how this user story could have been positioned a bit better:
As an online e-commerce portal user who is overwhelmed with the choice of products,I want to understand which products best fit my needs,Such that I can decide which one to purchase.
Already, this is a much broader story that reflects the users’ actual objectives, which will start triggering questions from the design & engineering team around the implementation possibilities to ship a product that makes it easier for portal users to decide on which product to purchase.
Instead of a “Compare Feature” button the team could end up discussing adding a “Similar Products” view, or alternatively highlighting the key differentiators of each product in the search results screen. You get the gist.
Focus on what you should be focusing on
I believe that as Product Managers, we should focus our efforts on understanding our users and customers inside out. When we are handing over the work to our designers and engineers, we need to make sure that we’re providing complete, accurate and up-to-date information on our users and their success measures, so that together we can explore innovative solutions that deliver the highest amount of value to our customers.
Engineers & Designers are hired to engineer and design solutions. As Product Managers we should leverage this to unite the team and together reach our ultimate objective – building products that people love.
We all know that biases exist and we are all very much aware of them. We are all extremely logical and rational product managers and we never let our biases affect our prioritisation efforts.
Or maybe not.
I really like how Ellen Chisa describes product managers as “continuously going back and forth between the 10,000-feet view and the 2-inch view” in the book Product Leadership. Product management requires conscious efforts to maintain innovative, efficient and successful discovery and delivery processes, to build and ship products that people love.
This is hard work. More than one might think at the outset. And because of all the things we have to think about, it is extremely easy for us product managers to miss out on certain biases that crop up on a daily basis.
We can be blind to the obvious and we can be blind to our blindness
If you’ve never seen this clip, I suggest that you take a minute to watch it and follow the instructions.
The video shown above is based on a book written by Christopher Chabris and Daniel Simons, called The Invisible Gorilla. In their experiment, Chabris and Simons noted that more than half of the viewers were convinced that there was no gorilla in the clip. This highlights how difficult it is notice things other than what you’re focusing your efforts on. As Daniel Kahnemann highlights in his book, Thinking Fast and Slow, we can be blind to the obvious, and we are also blind to our blindness.
The effects of biases
As product managers, we need to make sure that we are building products that our users love, and we can only do that by shipping products that our market finds valuable. The presence of personal biases is not desirable as these can skew our view of what the market desires, which leads to decision-making based on inaccurate information.
Here are a few examples of biases and how each of them may affect us in our role of Product Managers.
Confirmation Bias – Searching for and interpreting information in a way which confirms previous beliefs.
We all have our opinions on what we should be building/improving in our product, and sometimes it is extremely easy to validate our ideas by looking at data that will favour these ideas, and ignoring additional data points.
Availability Bias – Information that is readily available in our mind is given more weighting than other information.
When we’re looking at our options for what to build next, it is easy to give more importance to the options that we’ve been thinking about recently, even though there might be other areas that will give us greater benefit, but for which we don’t have enough information on.
Overconfidence Bias – Being overly confident in our or other people’s ability to make good decisions.
Experience always helps, however it’s easy to think that some decisions will work simply because the person taking the decision “has done this before”. When we follow this train of thought we are likely not giving enough thought to the differences between the current scenario and what’s happened in the past.
Sunk Cost Fallacy – Pouring more and more effort in a feature/endeavour as a result of previously invested resources.
The more effort we put into a given endeavour, the more we become emotionally tied to that effort. It’s easy to keep on putting more and more effort into a feature that we’ve taken a long time to build, because we “might as well get some return on all that investment”. In these cases we would probably be turning our backs to other opportunities which will benefit the product to a greater degree.
Ostrich Effect – Avoiding negative information.
We will always find some data which could suggest that our hypotheses are wrong. As product managers we should be investigating this data and not shrugging off, to make sure that we are really delivering on sound hypotheses that will ultimately improve the value of our product.
3 Steps to Overcome Bias
The first thing that we need to be aware of is that biases will always be present – it’s human nature. Everyone is susceptible to biases and nobody is able to completely overcome them. At the same time we also need to be aware that it is also impractical to constantly question our thoughts as this can easily lead to brain fatigue.
There are ways, however, how we can overcome cognitive biases. I suggest following these 3 steps to becoming better at overcoming bias:
Bias Awareness – Awareness is always the first step. By being aware of the different biases that exist, we are more inclined to self-challenge our thoughts, thus reducing the amount of bias in our hypotheses and decisions.
Bias Salons – The more you think about a particular scenario/hypothesis/idea, the more difficult it becomes to identify any biases that are present. It is therefore important to walk through your hypotheses with peers and key stakeholders, have some discussions around the data backing up the hypothesis, and to reflect on any biases that may be affecting the decisions.
Decision Transparency – We should always be transparent with our peers when we take decisions, by clearly communicating the rationale behind each decision that we take. Being open and transparent allows for constructive criticism which could highlight aspects that were not considered in the product discovery process.
Today, I would like to talk a bit about self-improvement, and how I’ve dealt with the various ups and downs of this process.
Most people have heard about Mozart and his prodigious musical abilities. Mozart spent the early years of his life putting most of his focus on learning music. Day in, day out, he practiced, and even though I can’t personally vouch for him, I am pretty sure that he’s made a lot of mistakes and put a lot of effort in learning from those mistakes. Yet, he is still referred to as a musical prodigy, rather than the kid who spent all of his time practicing music.
My point is, it’s easy for us to focus on the results or the ideal outcomes, and ignore all of the effort that’s required to achieve results.
We all read about what’s expected from product managers and product leaders in our industry. Know your customers inside out, constantly communicate your product vision, foster innovation in your design and engineering teams, and many many others… Yet sometimes we find ourselves saying….
Oops, I did it again.
Even though we know what we need to do to become successful product managers (or anything else really), and even though we’ve put conscious effort in improving, we still realise from time to time that we’ve fallen short of achieving what we want to achieve.
And I bet Mozart also had his fair share of frustrating iterations, which did not seem to result in any self-improvement, even though he took honest actions to improve his output.
This happens to all of us.
It’s fine to make mistakes (sometimes even more than once) – but at the same time it is extremely important that we are disciplined with ourselves enough to keep in mind that it is only fine if:
We’re humble enough to accept that we’ve made mistakes,
We’re honest with ourselves to understand why we’ve made the mistakes,
And, finally, we find the energy required to get back up on our feet and try again with more determination to succeed in the areas that we’ve failed.
Learn. Measure. Build. Just like Mozart and the other prodigies of the world.
Although a necessity for our own personal success, this frequent iteration of self-improvement cycles, can take its toll on our own well-being and can sometimes also make us feel like impostors.
The ever-so-reliable Wikipedia defines Impostor Syndrome as “a psychological pattern in which an individual doubts their accomplishments and has a persistent internalized fear of being exposed as a fraud”.
What’s important to realise here is that we all make mistakes, and it’s fine to not be getting things right the first time round. Being humble enough to accept mistakes and making active improvement efforts should be our aim. Success will come as a result of our actions. And finally, we should definitely not feel any shame whilst going through this process.
To close today’s thoughts – self-improvement is an iterative process, which takes time and can be quite frustrating. But it’s always good to keep in mind that everyone’s doing it and nobody’s expected to get things right from the first time round. As long as we remain humble in the process and honest with ourselves and those around us, we should only be a few iterations away from success.
As Product Managers we are always looking to build better products and better experiences for our users. Most thought leaders in the product space profess that the single best way to do this is by getting to know your customers inside out. Of course, there are varying degrees of knowing your customers. Your job as a product manager should be to understand your customers in as much detail as you can, so that you can make the best decisions for your product.
If you can’t get much deeper than “Our customers are Saas businesses that generate more than $50 million revenue every year”, then you probably need to dig a bit deeper.
What does a typical work-day look like for your users?
What do they achieve by using your product?
What other complementary tools do they use?
What are their own customers trying to achieve?
Why do all our customers have pet Mongooses at their offices?
You get it…
When you think about it, we are a handful of product managers, trying to build great products that will be used by hundreds, thousands or millions of people. Each person will have a different view of our product and how to use it. Ours will also differ.
Whilst we all have great ideas of what our product roadmap should look like, we are not the end users of the product that we are building. Our opinions of the product, how it should be used and of the value that it delivers, are rather useless if they do not align with the opinion of the market – our customers and users.
By understanding our market’s needs at a more intimate level, we can empathise more with our users, which in turn allows us to ship better products that our users love.
I like to summarise the above with a couple of sentences:
Your opinion does not matter. The market is the only valid opinion.
I have found these blunt words to be extremely helpful in my role as a product manager. They serve as a constant reminder of what we need to keep on top of mind when discovering opportunities and taking decisions on what to build next. I have found them so helpful in fact, that I’ve set this as a permanent background of my to-do list – a trello board that I look at on a daily basis.
So how do we build for the market?
We build for the market by building products that solve problems and blockers that prevent our users from getting things done. To do this, we should be speaking to our customers to understand what is it exactly that they want to solve, and, more specifically how they measure success.
By understanding the problem at hand and the success metrics, we can provide the necessary context for our team to design and engineer solutions that solve these problems for our users. If we focus on providing accurate context and clear outcomes, it becomes easier to build more innovative products which have a much higher chance of being adopted by our users.
A lot of people think that a Product Manager’s role is to be creative and come up with features for engineers to build. I disagree with this. As Product Managers we should not be primarily thinking about features or defining the solutions for our engineers – we should be focusing on providing detailed context around our users and their expectations. Engineering and designing features should be left to engineers and designers. It’s their role after all.
To close off, always keep the market, your users and customers, at the top of your mind. They are the ones who will use your product and they will determine the success of your product. Their opinions matter greatly. Yours – definitely not as much.
My name is Luke. I’m a Product Manager, I’m short and I have curly hair. You guessed it, that’s where the name of this blog came from.
I have never given blogging much thought before these days, however, I’ve really come to appreciate how helpful sharing learnings and listening to others’ experiences can be in growing one’s professional career. This will be the main objective of my blog. I would like to share my experiences and learnings in my role as a product manager, which I hope will be helpful to some of you folks who are going through similar experiences.
It will not be the most perfectly penned blog. I will not guarantee flawless opinions. But I will definitely do my best to keep this blog updated with interesting new things that I learn in the great world of product.
On the flip side, I also love hearing about other people’s learnings. So please do feel free to leave comments with your opinions on my posts, or get in touch. I’ll be happy to discuss product management in more detail with anyone who reaches out.
Where I come from
I was born and bred in tiny Malta. I studied IT at the University of Malta and later, Economics & Finance on a remote programme with the London School of Economics. My first role was in software development. I then moved on to do data migrations, large-scale enterprise system implementations, project management and I’ve now recently moved into the world of product management.
I’m currently a Product Manager at an awesome company called Hotjar.