We often talk about discovery, including its different variants (continuous, project-based, etc.), and importance in product development. I’ve written a few pieces on it myself.
But, is it really always needed? We’ve accidentally built a cult of discovery where doing any product work without proper research and validation is a sin. It’s not necessarily healthy.
In fact, there are plenty of situations where discovery doesn’t make sense. And in these cases, needless discovery can actually be harmful to your speed and efficacy.
This article provides you with the tools you need to determine if discovery makes sense and when it makes sense to skip ahead and ship your product.
Let’s start with a quick recap of what product discovery is.
In short, it’s a process of understanding what to build. You do that by conducting user research to understand customer needs, validating ideas with surveys and mockups, and developing confidence from desk research and other research methods:
In other words, it’s everything you do before developing a feature to ensure it’s really something you should build, and that you build it the right way.
Discovery gained a lot of popularity because it simply makes sense. As Einstein allegedly said, “If I had an hour to solve a problem, I would spend 55 minutes defining the problem and five minutes finding the solution.”
It’s much cheaper and time-efficient to pivot early on than to build something and learn it’s not what your users need.
To that end, I strongly encourage you to invest in discovery whenever you are:
If you’re building a brand new product, you know almost nothing about your market, users, competitors, alternatives, and so on.
Just building it and seeing what happens is the fastest way to become one of those 90 percent of startups that fail.
Without a deep understanding of users and market dynamics, how would you even know if the idea you have has any merit?
Whenever you’re expanding to new segments of users, do a reality check with discovery. Odds are, you’re going to be extremely biased based on your current learnings and wins.
The problem is, what works for your current users might not necessarily work for the new segment you want to target.
If you’re expanding your product with a type of feature that’s not so common (or maybe innovating something brand new), you need to understand how to shape its final direction, what standards it must meet, and how users will even perceive such an innovation.
Doing this early on is a lot cheaper.
As we just discussed, discovery is an extremely valuable tool in product development that helps de-risking your ideas and initiatives.
But don’t make the mistake of doing discovery every single time. As bold a statement as it is, sometimes it’s just a waste of time and resources.
Here are some examples:
I’ve seen teams do a week-long discovery process with user research to understand if they should build a feature X or a feature Y.
The ridiculous part? Both features were estimated for roughly one day of work each.
What’s the point of spending a week on research if you could just launch it and see what happens?
Although the example above is more of an edge case, there are teams that refuse to do any new feature development without discovery — even when the development is actually pretty straightforward.
Yes, you won’t know if building it was a good choice. But you’ll validate it faster and more precisely by just launching it and seeing the impact on engagement, rather than by setting up yet another user interview a week from now.
Some changes make the most impact if they’re done sooner rather than later.
Take the 2023 AI fever. AI was so hot in the first half of the year that whenever a product launched an AI feature, it was in the spotlight.
It made much more sense to launch a half-baked AI-feature in April to then improve it and launch a polished version in August, than to go through the whole discovery and launch the polished feature in June, missing the traffic boost that came from simply “having AI.”
Another thing is seasonalities. If you are building an edtech product and it’s July already, sorry, you’re already behind. It’s better to trust your gut and whatever knowledge you have right now to be as prepared for the September back-to-school period as possible.
Discovery makes sense if you are unsure what to build or have a lot of assumptions you need to validate.
But if you already have a decent body of knowledge about a particular topic, what good does further discovery do?
For example, AI chatbots for customer support are a new reality right now. Most major companies use it, and customers are increasingly used to it. There’s no need to spend weeks on research to determine whether it makes sense — countless companies have already proved it does.
There are periods when you can deliver new stuff faster than run a discovery. It’s a problem if that’s what happens all the time, but even most streamlined teams have periods like that.
Instead of having your dev team work on low-value things just because new topics aren’t well-researched and defined yet, make them work on a couple of smaller bets in the meantime and validate on production. It’s usually a better use of their time.
Well, unless you are buried under tons of tech debt, then that’s a different story.
This one might be controversial. In theory, the bigger the decision, the more discovery you should do beforehand.
That’s true most of the time. But sometimes you need to bet.
For example, the AI overviews impacted particular product categories, such as Q&A, content platforms, and other SEO-driven products, dramatically. Some companies saw a 70 percent SEO traffic drop within less than a year.
This scale of disruptions forces us to make big choices about what the new path we should take, and we need to make these decisions fast.
Should an edtech Q&A platform pivot into an AI learning assistant? Tutoring platform? Homework centre? These all make sense, and the more discovery you do, the more you’ll realize there’s demand for all of these. The question is:
Some decisions require strategic analysis and choice of which risks to take, not another user interview.
Product discovery is an inseparable part of the product development lifecycle, and I still believe it’s where we should spend most of our time and energy.
But we must avoid the mistake of doing deep discovery every single time just because it’s “the proper way to build the product.”
With all the benefits it brings, discovery requires time and resources, and sometimes it’s not worth spending these.
Focus on discovery whenever you’re building something brand new or targeting new user groups.
However, it’s cheaper to skip it if you:
Also, as user-centric as we want to be, some strategic changes rely more on the business context and capabilities than on what users need the most. Listening to users is essential, but it’s often not enough to build a scalable and profitable business model.
Whether you like it or not, there’s some gambling and betting when it comes to building successful companies.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Mike Fantigrassi shares his experience helping transition NASM to a product-led growth model and the challenges that came with it.
Rob Helton talks about the potential for technology to impact the bottom line across the healthcare industry.
Learn how to use AI for faster, smarter customer discovery—without losing the human insight that makes product work effective.
Matthew Pizzi shares how he helped strategize and build Contentstack’s Academy, a learning management and training and certification program.
Learn more →
