I’m not going to answer all of these questions in this article, but I am going to provide you with a different lens. Instead of seeing these topics as two distinct areas of work, why don’t we see them as different means to achieving the same goal?

The goal?

To build the right thing for our customers!

Discovery vs. Delivery.

I spent so much time in the corporate Product world, where Discovery and delivery were seen as two distinct things.

The typical approach that I observed at organisations was that teams would:

1. Carry out some research. They would generate some insights and the discovery checkbox would be ticked.
2. This could now be passed over the fence and it was time to deliver.

The process typically looks like this:

The teams carry out some discovery, using techniques like:

• Conducting a survey
• Carrying out some user interviews
• Observing some click tests

Then they create a hypothesis, believe they know the right solution to the customer's problem, and they deliver this.

Sometimes, they don’t even measure the impact.

When they do, they often discover that it wasn’t the impact that they were expecting. So they go back to the discovery drawing board to see what they missed.

The problem with this approach is that it’s not taking a holistic view. The team isn’t using all of the tools they have to really test their assumptions. They’re not accessing all of the techniques that they could combine to generate the best approach, before believing that they have the solution.

Although it’s not the worst approach, I do believe that some discovery is better than none! It doesn’t allow teams to quickly accelerate and deliver as much value as possible.

I believe that teams need to take a more strategic approach to Discovery. The best way to do that, is to see ‘discovery’ and ‘delivery’ as vessels to achieve the same thing - grow understanding and validate assumptions.

Dual Track Agile

When I was really hot on getting my team to conduct more discovery and really understand what we should focus on and how, we tried dual-track agile.

This really helped us as a team to:

• Conduct more discovery
• Get more of the team involved in discovery
• Continuously validate our assumptions

Whilst this helped us to ramp up our discovery efforts, and get the team involved, it still gave us the view that we would use ‘discovery’ techniques:

• User interviews
• Prototype testing
• Click tests
• Etc

Until we decided what the right thing was to build.

We continued to deliver at the same time. It was like a supply-chain, with ‘validated’ work being handed to the delivery track whilst we went through the next piece of discovery.

We hadn’t really discovered the secret of delivery and discovery being different techniques to achieve the same goal.

Discovery and delivery as a means to achieve the same thing

So what if we scrapped that concept altogether, and purely saw discovery and delivery as different sides of the same coin.

If you’re working in an organisation that:

• Is outcome-led
• Is using OKRs
• Knows that you need to validate and test assumptions

Then discovery and delivery should truly work together.

Delivery is just as much about continuously discovering and validating your assumptions. Even with delivery we’re always figuring out what does and doesn’t work. What does and doesn’t serve our customers.

To really see discovery and delivery as one, it means that no matter what you’re working on - you always need to ask these questions:

• “What are we trying to find out?”
• “What assumption are we trying to prove or disprove?”
• “What is the best way for us to understand this”

Discovery techniques, or delivery techniques are all elements of a toolbox that you can use to validate assumptions.

You might choose to run a quick AB test on the website, or test a prototype - or it might be that you need to start with user interviews. One doesn’t need to come before the other. Any techniques can be used in conjunction with each other. Overall, you should continue to think about these in conjunction and not two separate areas of responsibility, or not something that is ‘ready to be handed over’.

Yes, you will have members of a team that specialise more in some techniques than others, but we should all be involved and interested as to how this happens to ensure we’re doing things the right way. This mindset will really help everyone involved to deliver the best outcomes.

Continuous Discovery

When I work with teams and they think through all of these steps:

• Setting an outcome
• Setting OKRs
• Understanding what they know
• Understanding their assumptions
• Validating their assumptions
• Delivering solutions that really have impact

They usually panic and state that they don’t have time for this!

It does sound quite lengthy. Although that is not my intention, nor do I believe that lengthy cycles are what any team should be working through.

Instead, you constantly need to assess the risk vs. reward trade-off. The smaller the size of the risk, the less validation is needed - launch and learn would be my approach here. If the risk is bigger, you want to understand how you can validate your assumptions in the most cost effective / quickest way, so you move through the cycle as quick as possible.

This is where I believe there is a beauty in assessing delivery as part of discovery. It’s not about getting something ‘ready’ before you deliver. It’s about shipping something if it makes sense, as that would be the quickest way that you’ve identified to learn. If you leverage delivery through this lens, then you’ll definitely increase your success. If you want a different take on Discovery vs. Delivery and how these things can work together - this is a great article.

Conclusion.

Discovery can play a major part in your process to validate what you should build, and how you should build something. In fact, the sooner you can test something with the masses, the quicker you will validate most of your assumptions.

Seeing discovery and delivery as one, and using these as a toolbox of techniques that you can use to increase your understanding and validate your assumptions will create the quickest route to success for your team.

It all starts with choosing the right mindset, and the right process to follow to achieve this.