I often see product teams filled with people with the same old complaining about not having enough time for Discovery phases.

"I wish I had more time to make for Discovery."

– Any product person, any company.

I have some strong opinions about this topic. I'll try to explain my thinking in a broader sense possible to apply to anyone who works in product teams.

Discovery vs. Research

First of all, I see a lot of confusion with the terms Discovery and Research, so it's helpful to clarify my understanding of each one before going further.

I'd like to think of Discovery as the continuous process of understanding the next relevant opportunity to tackle as a company and the risks involved in doing so.

On the other hand, Research uses tools and methods to better understand qualitative and quantitative information to draw better conclusions around any specific theme.

So, you'll often use research methods on your discovery practice to create appealing arguments to support your prioritization.

Not enough time

If you work on a product team, the chances are that you already heard something around the lines of "we don't have enough time for Discovery."

The vicious cycle

Working as a product person (PM or Product Designer) and not enforcing a healthy balance between Discovery and Delivery on your schedule will lead to the famous vicious cycle of "not having enough time."

When you don't have time for Discovery, you're neglecting a big part of your role. Your job is to make sure your team is chasing the right opportunities, and everyone is aware of its risks.

Consistency comes before depth

Another source of this vicious cycle is that many teams try to go from no Discovery habit to "I need a whole month to deep dive on this topic."

It's way harder to get buy-in from your company or team to commit large chunks of their time if you don't have a healthy habit on your team.

Start by blocking off a couple hours on your calendar each week.Remember that your days and weeks are the atoms of your work.A poor weekly routine will lead to a poor month and quarter.

It's easier to get more time and space to dig deeper into something when you have good arguments around the opportunity upside or the risks involved. Start out by creating a weekly routine and treat this time as a sacred moment – don't trade it off for less valuable discussions.

Practical Discovery, not perfect Discovery

When doing your discovery practice, an important thing to keep in mind is to optimize for good decisions, not the best decisions.

Most of the time, you won't need the best answers upfront for the opportunities that your team is pursuing. You have to make sure that your team is making good decisions consistently.

Optimizing for the best decisions takes a lot of time and effort, so you need to know when the problem in hand really needs this kind of investment. It also may lead to a culture of being afraid to commit mistakes, which is a terrible thing for product teams.

Chances are that most of your daily decisions can be revisited in later cycles. So be extra cautious of where and when it worth investing more time to increase your confidence in something.

The secret is optimizing for "good enough" decisions and having short increment cycles to gain momentum towards the goal your team is pursuing.

You don't need to discover everything upfront.

Here things get a little bit more heated.

I see many teams feeling guilty by not having a perfect playbook for Discovery, and not always having a discovery checkpoint in each cycle. Treating Discovery as a fixed and non-negotiable step.

As I said before, Discovery is an ongoing process of understanding whats the next thing that will increase your product's success and the risks along the way.

There are different levels of granularity in the discovery process. It could be to know how the next quarter will look like or understand specifics about a product feature coming on the next sprint.

When you and your team are working on the same problem space for long enough and have a good understanding of the company and user's goals, you'll have to trust your judgment to know when you should invest more time in Discovery and when it's time to "learn in production mode."

Learning in production

I strongly agree with Jason Fried's vision about validation and user testing. You have to be extra careful not to fill your product cycle with too many pre-validations to have the confidence to ship.

It's better to optimize for shorter cycles of iteration, with just enough confidence, and really validate and learn in production.

The best way to ensure that your solution solves a real problem is by shipping working software and getting it in your user's hands.

You may want to validate your initiative upfront, but you'll only reach concrete answers when it reaches your customers. When they are in their natural context of usage, their own devices, within the constraints of their habits.

Of course, usability tests and other validation methods are often necessary to avoid big mistakes and narrow down the solution. But remember to keep in mind that you'll only be sure of your initiative's success when it's live.

One of the best traits of high-performing product teams is how fast they iterate a solution based on findings of past cycles, not how rigid their process is.