Discovery – Excuses
In this article I’d like to continue with the series on common problems with product discovery.
So far I’ve talked about the difference between learnings and insights, the differences that result from focusing on the problem versus the solution, the essential role of judgement, and balancing discovery and delivery activities.
Those that know me personally know that I spend a lot of my time helping to persuade company leaders to start trusting and empowering their product teams.
However, in more than a few companies, the issue is not so much with the company’s leaders, it’s with the product teams themselves. In these cases, I often hear excuses for why they think they can’t do their product discovery work.
In this article, I’d like to share the most common excuses I hear, and how I respond:
“There’s No Demand”
I see this confusion so often, and I’ve written about this before:
It’s worth noting that if you have a crappy solution, it can look to you like the demand isn’t there. You know you can’t sell it, and it’s tempting to blame this on demand, but this is rarely a sign that the problem isn’t real; it’s much more often a sign that your solution is not perceived by the customers as better than the alternatives, and certainly not better enough to persuade the customer to switch.
Now sometimes it’s true that there’s just not demand, but much more often than not, it is easier on our ego to believe the demand isn’t there, at least until a competitor comes along with a dramatically better solution, which makes clear the issue was never demand.
“Our Customers Hate Change”
If only I had a nickel for every time I’ve heard this one. Especially from teams doing products for Enterprise companies.
Customers hate bad products. And they don’t appreciate gratuitous change. But customers happily change all the time – if you give them something that truly makes their lives better.
As with “there’s no demand,” it’s a convenient excuse to blame your customers for not wanting to change, until a competitor comes along with something dramatically better, and then all of the sudden your customer is no longer yours.
Slack. Stripe. Shopify. Tesla. Zoom. Netflix. iPhone. Workiva…
“We’re In A Regulated Industry”
For those that can’t blame their customers, it’s convenient to blame their industry. Many industries are regulated – financial, healthcare, telcos, transportation, power, environmental – are all obvious examples.
But most industries have more regulation than you might think. Consider the various employment regulations that Uber and Lyft have to accommodate. Or the various zoning regulations that Airbnb has to accommodate. Or the age and privacy related regulations that most gaming companies need to accommodate.
And every company, to one degree or another, is constrained by legal regulations.
The point is that every company has to come up with solutions that comply with the relevant constraints. I’ve said many times that coming up with a solution that users and customers love is only half the battle – we also need to make sure the solution works for our business (viability).
Yes, some industries have more constraints than others, which makes the problems tougher to solve, but those same constraints increase the barriers to entry for your would-be competitors.
In any case, we have very good discovery techniques for dealing with regulated industries.
I’ve loved watching the new breed of strong product companies disrupting financial services and healthcare especially.
“We Have A New Type of Product”
It’s remarkable to me how many startup founders and product managers think that they can’t test out their product ideas because it’s a new type of product.
Usually what’s going on is that they are misunderstanding the first principle of product, which is that our customers can’t tell us what to build. But I point out to them we’re not asking them to tell us what to build. We’re testing to see if they will buy the product if we do build it.
Whether it’s truly a new type of product (rarely) or just a different approach to the solution (almost always), eventually you are going to have to put it in front of real users and customers. You’re not doing yourself any favors by giving yourself reasons to push that day off.
“We’re Not Allowed To Talk to Customers”
This excuse is usually only found with organizations that depend on a direct sales force, where the head of sales has very strong convictions about account control, and usually also has some scars from rogue product managers and engineers having messed things up for them in the past.
In any case, it’s important to respect the role of sales in a direct sales go-to-market model, but that doesn’t mean we don’t need to talk to customers. That’s non-negotiable. What is negotiable is how we do this.
Usually what’s required is the head of product and the head of sales have a conversation about the concerns and how they’ll be addressed. That’s the purpose of charm school for product people.
If despite all attempts you’re still prevented from talking to customers, then you probably want to reconsider your company’s chances at sustained success.
“It’s Not Possible To Test This Idea”
This one is so common but it’s really just lack of education. It is remarkable how many people – especially startup founders – tell me their product idea is not possible to test. “The only way we can test this out is to build it.”
I’m always hesitant to say that they’re absolutely wrong, because there may be product ideas that truly require building it out. But I do tell them that I still have not run into that situation myself.
In every case so far, there have been multiple ways to try out their ideas.
After so many years meeting people that believe their idea is not possible to test, it’s certainly no surprise to me that most startups run out of money long before they achieve product/market fit.
“We Don’t Have Time”
This is the most common, yet most frustrating excuse. Frustrating because it’s such a weak excuse.
If a product idea is not risky – the founder/product manager, the designer and the tech lead believe that this is straightforward when it comes to value, usability, feasibility and viability – then we would just proceed to build it.
However, if there is significant risk, then the real question is do you have the time not to test it?
Realize that it will very likely require several iterations to get this idea working to the point where it achieves the necessary outcome. If the way you test an idea is to use your engineers to build, QA test, and deploy it, then each iteration will likely take weeks or even months.
The underlying principle of product discovery is that if we can’t test out an idea in at least an order of magnitude less time and effort than actually building it, then you’re doing something very wrong.
This is why I argue that product discovery skills need to be a core competency of any strong product organization, just as with product delivery skills.
If your team has been thinking product discovery is not something you can do because of one or more of the excuses above, I hope this article encourages you to reconsider your position.