Adopting a Continuous Discovery Mindset Across the Organization

Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery.

I teach two courses at Northwestern University. I want to share a little bit more about the work that I am doing there as I think it’s relevant for people working at companies who are starting to adopt continuous discovery practices (in other words, many of you).

The first course focuses on teaching practitioners how to use design methods to solve business challenges related to learning and organizational change. Students learn the same design process I teach to the product teams that I coach. Our students are a mix of full-time graduate students and working professionals who pursue a graduate certificate while working.

The second is an executive education course designed to help leaders understand how their role changes as their organization moves toward continuous discovery. They learn how to manage by outcomes and how to co-create change. This course is a 3-day seminar and our students are working executives. I co-teach both courses with a fantastic co-instructor, Jeff Merrell.

I love teaching these courses because it’s a way for me to apply my coaching curriculum to a new context. Instead of using continuous discovery to design products and services, our students are using continuous discovery to address internal people challenges like employee engagement, team effectiveness, and diversity and inclusion. I’ve been blown away by how effective the same approach works in this new context.

It got me thinking about how when companies first started adopting Agile methodologies on their software engineering teams, they quickly ran into obstacles with the rest of the organization. It’s hard to be Agile when the rest of the business wants fixed delivery dates or wants to dictate requirements. The same is true when we shift to a more continuous mindset.

Just as it’s hard to be Agile when the rest of the business isn’t, the same is true when we shift to a more continuous mindset. We can’t truly work as cross-functional, continuous teams if the rest of the organization doesn’t also adopt this mindset. – Tweet This

We can’t truly work as cross-functional, continuous teams if the rest of the organization doesn’t also adopt this mindset. And so I love getting to experiment with how this mindset can apply to broader business challenges.

As part of the preparation for our executive education course, I wrote an overview of the design approach we’ll be using. It will look very familiar to you. I want you to see how the work that we do is not just about product, it’s about solving problems and making good decisions, and is applicable broadly across business.

The work we do with continuous discovery is not just about product. It’s about solving problems and making good decisions, and is applicable broadly across business. – Tweet This

Also, if you have leaders in your organization who want to learn more about how their role changes when they manage teams who adopt a continuous discovery mindset, refer them to our upcoming seminar.

Before we dive in, some notes on terms:

• ELOC stands for Executive Learning and Organizational Change
• DOEC stands for Designing for Organizational Effectiveness Certificate

The DOEC / ELOC Design Approach

Many business challenges can also be defined as design challenges.

It’s easy to think about design thinking in the context of designing products and services, but it applies equally well to broader business challenges.

Design challenges are challenges where elements of the problem space are still unknown, there are multiple criteria for evaluating solutions, and the solver has to make many judgment calls when designing a solution. In other words, many business challenges are design challenges.

When we set out to increase employee engagement, improve team efficiency, or expand knowledge sharing in our organizations, we are tackling design challenges. We don’t always know what is causing a drop in employee engagement or why teams aren’t as effective as they could be or what the barriers to knowledge sharing might be. We need to start by framing the problems that impact these challenges.

We may not realize it, but when we set out to increase employee engagement, improve team efficiency, or expand knowledge sharing in our organizations, we are tackling design challenges. – Tweet This

Similarly, there is no silver bullet that will fully address each of these challenges. Instead, we have to patch together a mish-mash of solutions that each address different parts of the problem space. We have to use our judgment to assess what those solutions might be, and how I assess one solution might be different from how you would assess that same solution.

Finally, we are rarely—if ever—done. While we may see improvements as we explore solutions, we can always get better. These are evergreen challenges that require a persistent effort. It’s easy to feel like we are playing whack-a-mole where once we address one target area, the next one pops up.

These open-ended business challenges can benefit from taking a design approach.

What We Mean by A Design Approach

A good design approach starts with the end in mind.

A good design approach starts with the end in mind. We start by defining the outcome we are trying to achieve. The easiest way to do this is to look at our challenge and ask, how will we know when we’ve solved it? The answer to that question is your conceptual start to defining a desired outcome. We’ll explore this more in the “Shifting from Outputs to Outcomes” section.

A good design approach starts with the end in mind. We start by defining the outcome we are trying to achieve. The easiest way to do this is to look at our challenge and ask, how will we know when we’ve solved it? – Tweet This

We then need to take time to define the problem space. Remember design challenges are ones where elements of the problem space are unknown. We may not know why morale is low or why employees are guarding their knowledge. Even worse, we may think we know why morale is low and end up solving the wrong problem. We need to spend time discovering what’s happening right now in the organization before we can solve for tomorrow.

When discovering what’s happening right now, it’s easy to focus on problems and miss the bright spots in the organization—the areas where the problems are already solved. To help you remember to look for both problems and bright spots, we reframe the “problem space” as the “opportunity space.” Think about opportunities as both problems and bright spots. We have an opportunity to solve the problems and replicate the successes. We’ll explore this more in the “Discovering Opportunities” section.

Finally, we need to discover the solutions that might address those opportunities. With a design approach, we encourage you to co-create with the people who will be impacted by your solutions, by iteratively prototyping until you find something that works. We’ll cover this more in the “Discovering Solutions” section.

While I described this process linearly, it’s not a linear process. Design is a messy, iterative process that often loops back on itself. When we learn that a particular solution doesn’t work, we also learn something new about the opportunity space. As we explore the opportunity space, we learn more about the outcome we are trying to drive. Each step feeds back into the previous step. We’ll explore how to track this messy process in the “Managing Your Progress” section.

Shifting from Outputs to Outcomes

We sometimes feel like we’re making progress because we have outputs. But it’s important not to mistake outputs for outcomes.

Suppose you are trying to increase knowledge sharing in your organization. You might be considering programs like rolling out an employee social network (ESN), starting a lunch-and-learn speaker series, and pairing novices with more senior experts through an apprenticeship program.

In many organizations, we assign teams, set goals, and kick off projects to roll out each of these programs and we feel like we’ve made progress. But have we?

It’s quite possible that all three programs will fail. Nobody uses the ESN, attendance to the lunch-and-learn series is enthusiastic at first but quickly wanes, and the apprenticeship relationships are superficial at best.

Each of these programs is an output. It’s something that we produce to achieve an outcome—in this case expanding knowledge sharing. But if we don’t measure the impact of these programs on that desired outcome, we are simply assuming that we’ve made progress.

In ELOC / DOEC, when we talk about taking a design approach to our business challenges, we start by encouraging you to shift from an output mindset to an outcome mindset. We still need to produce outputs to accomplish our outcome, but producing outputs alone is not enough. We aren’t done until we’ve accomplished our outcome.

This is one of those ideas that seems so simple that we often miss the insight. It’s easy to think we are focused on the outcome, after all, that’s why we set a goal in the first place. If we set a goal to increase knowledge sharing in the organization, does that mean we have an outcome focus?

Not necessarily. The value of shifting from an output focus to an outcome focus comes when it’s time to design and implement programs. If we are asking our teams to implement specific programs, we are communicating that it’s the outputs rather than the outcome that we care about.

Being outcome-focused means we ask our teams to deliver outcomes rather than outputs. We give them the autonomy to find the best path to those outcomes themselves. – Tweet This

Being outcome-focused means we ask our teams to deliver outcomes rather than outputs. We give them the autonomy to find the best path to those outcomes themselves. We may suggest outputs (i.e. programs or initiatives they might consider), but we give them the freedom to explore those suggestions alongside their own. Most importantly, we measure their success by whether or not they achieved the outcome, not whether or not they delivered the outputs.

This output vs. outcome distinction can be applied to many business challenges. Here are a few examples:

However, the distinction between outcomes and outputs is not always this clear. It’s easy to define an outcome that implies a specific output. For example, we might define our outcome as “Increase attendance to team charter trainings.” This is a quantifiable goal that we could imagine assigning to a team. We may give them complete flexibility on how they might reach that goal. They could host more trainings, raffle off prizes to those who attend, share success stories from those who did attend, etc.  Based on our definition so far, this is a good outcome.

There’s only one problem. What if the team charter trainings aren’t effective? Increasing attendance doesn’t get us anywhere. So we might want to widen our lens and set our outcome as “increase the use of team charters.” This would allow the team to explore other ways to get teams to adopt team charters other than attending the trainings.

But what’s the value of team charters? They help improve team effectiveness. But what are other ways of improving team effectiveness? You can see where this is going.

Think about the transition from outputs to outcomes as two ends on the same spectrum. When we talk about shifting from an output mindset to an outcome mindset, we want you to shift right on that spectrum. But how far right you shift will depend on the scope of your team. If we carry out our current example, shifting right on the spectrum might look like this:

• Host more trainings on team charters.
• Increase attendance to team charter trainings.
• Increase the use of team charters.
• Improve team effectiveness.
• Improve productivity.
• Reduce costs.

Your executive leadership team might be focused on reducing costs. Your COO might be particularly interested in improving productivity. Your Head of HR might be interested in improving team effectiveness. An HR Business Partner might be working with her teams to increase the use of team charters. And so on.

It’s important to take the team’s span of control into account when setting their outcome. If you set the outcome too far to the left, you’ll be dictating specific outputs. But if you set the outcome too far to the right, the team will consider outputs that are too far outside of their remit. Adjust the outcome to match the scope appropriate for the team.

Discovering Opportunities

Discovering opportunities means looking for pain points and bright spots.

With an outcome in mind, our goal is to get a clear picture of what’s happening in the organization today. We want to discover the opportunities—needs, pain points, desires, wants—that if we addressed them would drive our desired outcome. Remember, opportunities include both problems that we find, but also bright spots that we can replicate.

We discover opportunities by interviewing the people affected by our challenge. If we continue with our knowledge sharing example, we might interview employees about times when they needed knowledge and didn’t know where to get it (the problem mindset) and times when they shared knowledge they had or a coworker shared knowledge with them (the bright spot mindset).

As we collect these stories, for the problem stories, we want to listen for needs and pain points that emerge from the stories. For the bright spot stories, we want to listen for desires or wants that were met that we might replicate. In both types of stories, we want to listen for moments in time where we can either intervene or replicate success.

As we collect stories of problem areas and bright spots, we want to listen for specific moments in time where we can either intervene or replicate success. – Tweet This

It’s easy to get overwhelmed by the sheer size of an organizational challenge. By collecting stories, we can identify specific moments in time where we might intervene. This allows us to start small and build momentum over time. Instead of framing the problem as “employees don’t share their expertise with others,” a challenge that is too big and vague to solve effectively, we might identify a series of moments in time where this problem occurs:

• A new sales rep needs help overcoming a tough objective, but the senior reps are too busy with their own clients to help.
• A senior sales rep doesn’t know what products and services are in the pipeline because the roadmap is always out of date.
• The finance team is struggling to put together an accurate forecast because the sales reps are reluctant to commit to their forecasts.

Each of these moments in time is much easier to solve for than the general problem that employees don’t share their knowledge with each other. By interviewing and observing what’s happening in the organization today, we can turn a big, messy problem into a series of smaller, solvable problems.

By interviewing and observing what’s happening in the organization today, we can turn a big, messy problem into a series of smaller, solvable problems. – Tweet This

Discovering Solutions

One of the keys to discovering solutions is setting up compare and contrast decisions.

Armed with a clear picture of what’s happening in the organization today, we can now turn to solutions. There are two key principles we focus on when exploring the solution space. The first is to set up compare and contrast decisions and the second is to test and iterate on solutions. We’ll look at each in turn.

The human brain is remarkably good at closing the loop—when we hear about a problem, we jump to a quick solution. The problem is these first solutions are rarely the best solutions.

Additionally, when we work with one solution at a time, we set ourselves up to fall prey to confirmation bias—we see the evidence that supports our solution and we miss the evidence that doesn’t support it. To avoid this fate, we want to consider multiple solutions for the same opportunity, setting up compare and contrast decisions.

In most organizations, if the product team isn’t sharing the roadmap with the sales team, the quick and easy solution is to schedule a recurring meeting where the product team updates the sales team. However, these meetings are time expensive. Is this really the best solution? To answer that question, we want to consider multiple solutions and compare and contrast them against each other.

We can use rapid prototyping to quickly test and iterate on our solutions, giving us the data we need to effectively compare and contrast our consideration set. It’s easy to confuse prototyping with pilot programs, but a key difference is with prototyping we focus on simulating (not implementing) the experience we aim to create with our solution. Because we aren’t focused on implementation, we don’t have to simulate the whole experience, but can instead focus on the parts that represent the most risk. This not only enables us to move quickly, it also helps us collect more reliable feedback on our solutions, because the people they are intended for get to experience them, not just hear about them. They get to co-create with us.

As we iteratively test the riskiest parts of our solutions with the folks who will be impacted by our solutions, we collect data about which solutions will work and which won’t. More often than not, we start with several mediocre ideas. It’s hard to have a great idea right from the start. But through iterative testing, we learn how to turn mediocre ideas into great ideas. And as an added bonus, because we’ve been testing with our constituents along the way, they are excited to embrace our solutions.

Managing Your Progress

It all sounds so neat and tidy. In reality, it doesn’t quite happen that way. I mentioned earlier that design is a messy, iterative process that often loops back on itself. There will be plenty of starts and stops. Plenty of ideas simply won’t work. Each prototype is a deductive test of how well you understand the opportunity space. When you learn that a solution isn’t quite right, you also learn something new about what your constituents need.

If you continue to map out the opportunity space, as you prototype your solutions, you’ll constantly be revising your best path to your desired outcome. You might start by focusing on one key moment in time only to find a more compelling opportunity elsewhere in the organization.

The key to a successful design approach is to embrace this uncertainty and enjoy the twists and turns along the way. As long as you are regularly co-creating with your constituents—listening for opportunities in their stories and testing your solutions with them—you’ll be well on your way to driving your desired outcome.

A final note for Product Talk readers: If you have leaders in your organization who want to learn more about how their role changes when they manage teams who adopt a continuous discovery mindset, refer them to our upcoming seminar.