When it's okay to bypass discovery
At its core, product discovery is the process of understanding and framing problems and exploring and evaluating solutions to the problems you’ve uncovered.
It is an essential and often underinvested part of the product development process. The absence or lack of discovery can lead to products that don’t meet user needs, aren’t feasible to build or run, or that users struggle to use.
At worst, product discovery can be implemented as an upfront, elongated process, conjured up in a designer’s head with no input from real users or other disciplines and limited exploration, iteration, or divergent thinking.
At best, it’s a continuous, cross-functional activity, running in parallel to product delivery, using real data, user insights, and rapid feedback loops to validate and derisk ideas before they’re built.
But while the vast majority of my career has been spent trying to convince companies to invest more in discovery, I’ve also seen the inverse of this problem becoming more prevalent: Too much discovery. The outcome of this is usually frustrated stakeholders, slow innovation, and comparable levels of waste.
No matter how good your discovery process is, how thorough your research, how realistic your prototype is, or how many rounds of usability testing you run, you will only know if the thing you’ve designed is any good, once you’ve built it and put it in the hands of users.
That’s why it’s important to keep discovery as lean as possible. Doing just enough to give your team a suitable degree of confidence and acknowledging when you’re gold-plating or chasing diminishing returns.
But how do you know what is enough, and are there certain situations when you don’t need to do discovery at all? Unless you work in some kind of alternative universe where you have unlimited resources and no competitors, the answer is of course, yes.
Examples
These are just some examples of when it can be okay to bypass discovery, or certainly apply a less rigorous process. This is not to say these hard-and-fast rules apply in every instance, but when you’re resource-constrained and need to prioritise where you spend your discovery efforts, these scenarios demonstrate where discovery provides the least amount of value, or its value is trumped by another competing priority.
🔍 Micro changes
Micro changes refer to small tweaks or adjustments to an existing feature or design. These changes are usually minor and don't require extensive research or testing. Examples include fixing a spelling mistake, adjusting visual padding, or adding some micro copy. But be careful, while often changes of this size may seem insignificant, they can have a big impact on the overall user experience.
🚀 Time-to-market is critical
When time-to-market is critical, there may not be enough time to conduct a thorough discovery process. For example, perhaps you're in a land grab with your competitors or you have the potential to gain a first-mover advantage. In these cases, it's often more important to move quickly and get the product to market as soon as possible.
📚 Established patterns
Sometimes, there are well-established design patterns (UX or technical) that have been proven to work effectively. In these cases, there’s little value in conducting extensive, additional discovery on top of these patterns or exploring alternatives. By leveraging existing patterns or best practices, you can save time and resources and still deliver a quality product. Additionally, looking to competitors or industry leaders for inspiration can also help you identify successful patterns to leverage in your product design.
💭 Low-value features
The term "low-value" in this context refers to features that are necessary but do not necessarily add significant value to the end user or the business. Authentication is a great example of this because it's essential for security reasons, but it doesn't directly enhance the user experience or generate revenue for the business. In cases like this, it's important to strike a balance between building a functional and secure authentication system and not spending an excessive amount of time on it.
🤷♂️ Solution constraints
There are occasions where certain solutions come with their own inherent constraints. Perhaps your company has signed up with a payment provider who delivers their solution through an iframe. You don’t have any control over this, nor will you ever. So why waste time exploring different payment flows? Accept the constraints you can’t control and move on.
👥 Limited users
You might be developing a feature for a very small number of users. Perhaps it's an internal tool, only used by one or two people, or more, but very infrequently. One exception, which I will always fight strongly for, is in making products accessible. Regardless of how few people with accessibility needs use your product, in my view, it is unethical not to cater for them. Ensuring your products are designed to be accessible for those with some of the most challenging barriers has an added bonus – it usually makes your product more usable for everyone.
📊 Existing research
I’ve often seen designers and researchers fail to seek or ignore perfectly good, secondary data and research in favour of generating their own. Yes, there are occasions when secondary insights are no longer relevant or have gone stale, but more often than not, when there are existing insights, they can serve a purpose.
But often it’s not as cut-and-dried as ‘to discover or not to discover’. Discovery is all about reducing risk, and there are four inherent risks in product development: Value, viability, feasibility, and usability – broadly to be tackled in that order. There is little value in investing time and resources in figuring out if you can actually build something if you don’t have any confidence that it solves an actual problem for users. Similarly, if you don’t know your solution is feasible to build, you’ll be potentially wasting time creating detailed prototypes before you’ve figured that out. Understanding where the main risk lies in your potential solution will help understand where it’s most valuable to direct your discovery efforts.
Summary
Ultimately, my advice would be to exercise pragmatism and pick your battles, when it comes to determining what and how much to discover. Striking the balance between doing the right thing and eroding the trust of key stakeholders is tricky. If you’re always being told that discovery is a waste of time, start by understanding the preconceptions, motivations, or constraints of the stakeholders. Sometimes it pays to pay lip service. Sometimes you need to let things fail to get the licence to do it properly. Sometimes trust takes time. Sometimes it takes coaching. Sometimes the best thing to do is to ship it and learn. Sometimes you need to show, not tell, what a good discovery process looks like, and prove its value. Sometimes you need to acknowledge your constraints. Sometimes you do need more people. But also accept that there are circumstances where it is counter-productive to invest in discovery.
