Unlocking Innovation: The Case for Starting with Discovery Over PRDs

Have you ever thought, “This is a simple problem; I already have the solution.”?

Often, leaders start with PRDs (product requirements documents) because they’ve already internalized a problem, why they should solve it, why they should solve it now, and what a viable solution is. However, by jumping to one solution, you are cutting out a lot of the creative process opportunity to do better, and opportunity to educate your team.

Simply give four Lego blocks to four different people and watch how they each uniquely build something completely different with them. As the phrase goes, “There are many ways to skin a cat.” Or, if you prefer a less murderous rendition, “There are many ways to solve a problem.”

Sometimes, you can be so close to what you are working on and feel as though you know it so well that you have missed out on a much more opportunistic solution. Has anyone said to you “Why didn’t you do it this way” and you replied “Oh I didn’t think of that at the time.” Starting with a PRD seems quick and fast; you can beat your competitors to the market. But what’s better than beating them to the market? Beating them in a way that is much harder to replicate, that is much smarter, and that builds your brand and loyalty because you did it better. Also, starting at Discovery isn’t necessarily slower.

In addition to missing out on the potential for a better solution, you may not realize how much information you are keeping to yourself. For instance, I once had a boss who asked me if time for discovery was really needed if all he wanted was to pipe water into a room. I responded with a series of questions to help him understand the full scope of the project:

• What is the water going to be used for?

• Do you need hot or cold water?

• Will you need a drain?

• At what height do you need the water to come in?

• Will you need a shut-off valve?

• Will you need to change the temperature of the water?

• What is your budget?

• What materials will we be working with?

• Do we need to file any permits?

• What is the timeline for those permits?

He was reacting to a common misconception that starting with Discovery and asking “Is this really the problem?” takes a lot of time and slows progress.

You might think, “Oh no, do we really have to start with Discovery? Do we really have to do a month’s worth of research. What a waste of time!”

It doesn’t have to be a month, and it doesn’t even always have to be a full week. Just gather yourself, your subject matter experts, your designer, your engineer lead, and your product manager in the same room together. Have a powwow, a whiteboard session. Spend two hours talking about the problem:

• What do you know without assuming?

• What don’t you know or are assuming?

Then, focusing on these unknowns and assumptions ask yourselves:

• Which one of these are risky if we’re wrong? If we just move forward without actually knowing the true answer, how much will we mess this up?

After you have done that, let your product team do their magic. These two hours of close collaboration will provide them with a wealth of information and tasks, allowing them to spend, at most, two, three, or four days filling in the gaps. The only thing that will slow them down at this point is access to your end users. Make that access a wide-open door for your product team, and they will get you the answers you need.

Now, they might come back to you with a few different scenarios.

Not a problem: “You know, this only impacts a small percent of our customers, and not even the ones that we are going to retain.”

Imagine, wasting time solving something with very little impact. This is a great outcome. You want your team to disprove you. Something that you find super painful may not be the biggest problem for your customers.

Yes, and: Another outcome might be that your team says, “Yep, this is the problem. Yes, we should absolutely solve it. But there are a couple of other associated problems or opportunities that we could solve at the same time.”

This scenario is where the magic happens. You now are armed with even more information to improve your product that you may have not known before or you knew it, and failed to relay this to your team.

Or as you expect, “You’re right, let’s solve this”

Even if you were 100% right, and your team found nothing new, letting your team take this time to internalize the problem means you can now utilize them during the solutioning phase. The full team, just like with those Lego blocks, can provide you with an array of different solutions. Now, instead of the one that popped in your head right away, they’re providing you with different perspectives. Every single person is going to have a different solution and when you make that final choice, you and your team will feel like they really thought about it. They’ll feel more pride and confidence in their work.

One of the best things about starting here, even if you come to the same solution you had originally, is that if you start to include other members of your product development team, such as your engineers and QA, now everyone is going to have empathy for the problem. They will have the opportunity to really absorb what you are doing and why you are doing it.

Unfortunately, Discovery isn’t a silver bullet. Just because you started at the beginning doesn’t mean that the team will hit a homerun every time, but another by-product of starting with discovery first, is that the team will be more aware of the risks of the chosen solution. They will know what measurements to put into place to test hypotheses. So when they fail, as they will, they do it fast, and have the information needed to pivot. This way of working not only increases your chances at success, but encourages failure, because you’ll know when you got it wrong and you can correct it. Less fear of failure, more innovation; the more likely team members will try something totally new. Now you’re no longer like your competitors, you’re better.

Hopefully it’s now clear that although beginning with a PRD may appear to be quicker and allow you to beat others to the punch, it may actually slow you down later in your product development process. You are more likely to utilize the incorrect solution or even solve an issue that is not worth solving. You may have difficulty obtaining buy-in and motivation from your team. On the other hand, once you begin with Discovery, your team will feel a duty to not only find a solution, they’ll be much more motivated to get it out the door. The final solution will be much more likely to succeed, and even if it doesn’t, you’ll still have a motivated, informed, and fearless team.

Don’t start with a PRD; you are really selling yourself short.