Assuming you are wrong (and rethink)
The power of challenging your own assumptions to deliver great products
One of the biggest traps in product development, is to deceive yourself by believing in things that are not true. It may sound obvious, but with time, you get more experienced, you acquire more knowledge about the domain you are in, and you start to develop a sort of product sense. All these body of knowledge, helps product leaders to form an opinion, and (sometimes) works as a shortcut for decision-making.
Although the above is true, and I’ve seen it play at Nexthink and other companies, it is still quite difficult to be right all the time, and sometimes your ego does cloud your judgement, especially with the years accrued in the field and if you have had the pleasure to succeed in your field.
I was listening the other day the podcast episode where, Annie Duke interviewed Dr. Daniel Kahneman, and the made a very good observation about beliefs that shocked me:
“We tend to think that people feel that they have beliefs because they have reasons for their beliefs. Well, that psychologically is not the case. People have beliefs and then they invent reasons . . . and the reasons tend to be all consistent with the beliefs.” – Dr. Daniel Kahneman
It seems we always attempt to find the reason that justifies our beliefs, and not the other way around. It happened to me A LOT. “This is the best way to go and scale our self-serve capabilities (the reason), because it is the nicest solution our customers will appreciate the most (the belief)” I recall myself saying this to the tech-lead I used to work with. It turned our that it was not the case. “By incorporating this new technology we will allow our customers to reduce the interruptions, therefore we must invest implementing this solution (the reason)”; and keep going on and on.
There were at least 3 times where we were able to bit the temptation of jumping into the reason, and putting our beliefs to test.
Case 1: Research proved us wrong
Nexthink Amplify is the clear example of something that without the ability to rethink and challenging our beliefs, wouldn’t have seen the light.
I still recall the presentation that I did to our CPO at the time, introducing the idea and why we believe that this is one of the best investments we could do. The first reaction was, “Why do we need this if we already have X?” At the time, X was very promising and one of the core pieces of our value proposition.
We debated back-and-forth, and at some point he said, “prove me wrong”. He was very skeptical about investing time on this, and I get it. But the fact that he was willing to give us time and space to explore this, made me think that he was nos sure enough to discard the idea.
This is for me one of the biggest traits of great executives. Because of his position, knowledge, experience, and success-track record, the CPO could have put ahead his own ego, but he didn’t.
After having the first conversation, we embarked on a quick research that took us to different customer offices to understand and experience the day-to-day interactions of the people we wanted to serve. This is a high-level end-to-end we were able to capture one insight that was critical to move forward with the project:
Case 2: Look for rabbit holes
On the same project, as we were moving forward, we were very optimistic. We started to share prototypes with customers, and implemented a version that didn’t connect to the backend, but was able to showcase the functionality, and received very good feedback about it.
But you know that not everything that glitter is gold. There were a lot of rabbit holes in the technical implementation, and in other part of the product development such as, is this viable? Can we monetise this somehow? What is the best channel to distribute this? How can we be sure that people can use it?
We must have an answer for the previous questions before we start investing a lot of money. This is where spiking is crucial to ensure that if something shows up in the implementation phase, the blast radius is contained in a certain boundary that you can recover.
In Shape Up, Ryan Singer describes the above as follows:
We want to remove the unknowns and tricky problems from the project so that our probability is as thin-tailed as possible. That means a project with independent, well-understood parts that assemble together in known ways.
It took us almost 4 weeks to demonstrate feasibility and make sure we can deliver what we want to, with the proper level of security, scalability, and performance.
Today, based on my predictions, this product could be doing hundreds of thousands of dollars, if not close to a million in annual revenue.
Case 3: Inform yourself before jumping into conclusions
As a PdM, in most of the cases you will have to deal with missing information, and act as a true detective to truly understand the missing pieces of the puzzle by asking questions, probing people, listening contrarian opinions, and and come to a decisions that is beneficial for the customer and the company.
When I joined Nexthink, I was responsible for a product called Enhance. This was covering an essential security use case that was focused on detect potential malware on your binaries, as simple as that.
Initially, this was something that was not used widely across the entire customer-base, and with a bill that surged to 350K for the excessive usage we were doing on our 3rd party vendors’ API. Also, with the migration to the multi-tenant platform, we decided not to offer it to new customers.
I abruptly suggested to shut this feature down as one of the options. But little I knew about the implications this move could have.
Let’s run a quick case, to see how would you think about it. Imagine that I tell you start with the following information:
Feature that doesn’t provide a competitive advantage
The TCO is around 60k per year (after a considerable reduction we have made)
It’s not sold to new customers (it’s maintained for the customer that already bought it in the past)
Only 10% of our customer-base uses this feature (around 150 customers aprox)
The big questions is, what would you do? Would you kill this feature? Would you maintain it? If so, for whom? What would happen with the customers who have this feature and all of the sudden they decide to migrate into the multi-tenant platform? What if a new customer wants it?
If you only base you decision on the previous bullet-points, you may be missing the something. Jot down the questions you may want to get answered to. These are the (important) ones I’ve asked myself:
Is this feature value proposition aligned with our strategy?
What about the customer usage for this feature? What type of customers?
How big is this opportunity for the business (renewal and potential)?
How big is the struggling moment that this feature addresses for our customers?
With the above, we have been able to propose three different options:
Implement the new feature in the multi-tenant platform to all customers
Implement the feature as an add-on for only a sub-set of customers
Keep maintaining the feature in the on-premise solution, when possible
Remove the feature altogether
This case thought you how much you need to dig into different stakeholders and information before you jump into premature conclusion. It turned out the amount of renewal was 1.5M endpoints but a potential of 70M endpoints.
Challenging your beliefs when building something for someone else should be PdM’s bread and butter. That’s why you must be curious when faced with any of the previous situations. A mental model that helps a lot is the following one:
Facts are the information you have at your disposal for make a decision. Identify and answer the most relevant questions. Make explicit what your intuition tells you and why you think that way (may be you have already seen something similar), and run discovery to reduce the things you don’t know you don’t know.
We will be digging into the nitty-gritty of some of the techniques we used at Nexthink to prioritise and focus on what matter most.