Webinar: How Discovery Leads to Project Success

Transcript

Peter: Hello, welcome to Agathon’s webinar: How Discovery Leads to Project Success.

Today, we’re going to be talking a little bit about what Discovery brings to your project process and how it can lead to better success, better metrics. I’m specifically talking about bringing your team into alignment, facilitating creative thinking, and saving time and money. All the things that I think we’re all interested in doing.

I’m your host, Peter Green. I’m the Chief Growth Officer here at Agathon. Joining us in the discussion today is going to be Alan Ritari, Agathon’s CEO, and Kedron Rhodes, our Design Strategist.

Before we get too far into Discovery and what it means for your ministry, I wanted to talk a little bit about Agathon, give you a little bit of a background. Agathon was founded in 1999, and we have since specialized as a full service agency serving Christian ministries in strategy, design and development. We understand the particular needs of Christian ministries and hope to speak into some of those processes specific for those ministries to help advance your mission.

We’ll have a chance to go over some great information about Discovery and strategy as a whole and how it helps bring success to your project. And as Alan and Kedron are cruising through some things that we’ll be talking about today, if you have any questions, there’s a Q&A button down in your window, there. Feel free to click on that and submit your questions at any time. We’ll have a Q&A session near the end. We’ll read off your questions, and Alan and Kedron will be happy to answer those. So without further ado, I’ll hand it over to Alan and Kedron to talk about Discovery and project success.

Alan: Hi there. I’m Alan. Like Peter said, I’m the CEO. I’ve been doing this a long time, working with ministries. And over the years we have refined a process for how we launch a project successfully starting from day one. So I want to talk a little bit about what Discovery actually is and why it’s so important. Discovery is an intentional moment at the start of a project where you get alignment from the people that are going to be involved, the decision makers and the stakeholders. You get them together in the same room and then produce some creative output.

So part of that is problem framing. We need to make sure that the people that are the decision makers on this project all share the same assumptions about where we are and what needs to happen. So that means we need the people that are, in effect, commissioning the project or product, the ones who had this great idea and need something done—they need to be there. We need some project leads there as well. The people that are going to be responsible for doing the work and they need to represent different disciplines. We need user experience and design people. We need developers, and we need marketers, if you have all of those in a project; it depends on how big of a thing you’re trying to do. And ideally you also have the person or people that approve the budget, that green light a project or say it’s too expensive.

This last group, they tend to be not as involved in the discussions, but when they do speak up the questions and insights that they bring are often things that wouldn’t have occurred to other people. So then you get these people together and there are a bunch of exercises you go through to help define what it is we’re really trying to do and how does it help our users and serve our organization. Part of alignment is also being realistic about constraints. No one has unlimited budgets. We all have to deliver stuff within certain timelines. And then some ideas that are technically, we’re not quite there yet. So understanding where the edges are is actually super helpful in focusing our efforts on where we’re going to get the most bang for the buck. In addition to getting everyone on the same page, there’s also a creative generative aspect to this.

Kedron, and I’ll let you speak to that.

Kedron: So one of the core reasons why Discovery is important is because it’s going to generate some creative insights. It’s a purposeful time to facilitate creative thinking, and many of the activities are meant to unpack the problem from a user perspective, from the organization’s perspective, and find where the real new value is at. And in our experience, quite often, the creative thinking is often forgotten about when launching into a new project because most organizations are starting with a list of features that they are trying to accomplish and looking for easy solutions to do that. But once we introduce activities that frame that problem from a user perspective, it often leads to some very creative output. And then of course, all that comes with bringing in new perspectives. Namely, the customer perspective or your donor perspective or that end-user perspective—letting those voices shape the conversation and shape how the problem is being framed leads to drastically new insights and some really clear value for the project going forward, which then that leads us up to the next reason that Discovery is important.

Alan, take it away.

Alan: Risk management.

Discovery, a big part of it is risk management. We want to make sure that we are building the right thing for the right people, and it is expected during Discovery that new ideas come up that we didn’t know when we started the meetings, and they caused course adjustments. But we want to get those at the start of the project rather than a few months in when they are a lot more painful and expensive to make those same adjustments. So a lot of talk about the big ideas.

What does Discovery actually look like? And when does it happen?

Discovery, I mentioned, is getting the right people in a room together. These sessions really do work best in person. They can be done virtually, and we’ve done that. There is a certain chemistry, though, of being together and sharing that face time. But you lose a little bit of that when you do it online. It can be done.

The moment to do it is before any actual generative work happens. So you have the idea, the concept, what you want to do, but you haven’t yet begun work. That’s the moment when you do Discovery to really focus where the work is going to go. In some cases Discovery is part of the decision to proceed with the project or not. We have to find the constraints and the edges so that the people who are responsible for being responsible with the organization’s money and vision can say, “Yes, this is a good idea. We’re fully behind it,” or “Now is not the right time.” In other cases, Discovery in effect functions as the kickoff to the project. That’s kind of fun because then it really builds that momentum and gets everyone excited so that you just hit the ground running.

So get the people in the room together and then go through some specific exercises. Each one has a purpose that’s designed to tease out some sort of insights or wisdom about what needs to happen. They’re very strategic. They build on each other so that by the end, they create a bigger picture of the whole project.

And then there are—we call them artifacts. At the end, there are documents that we create as part of this that provide a historical record that serves then as a reference for the project that people go back and are like, “Oh, yes, I remember we talked about that.”

Now we are not attempting to teach you how to do Discovery on your own today. That’s more than we can do in the time we have here. We are, though, going to talk through the process so that you understand why it is so important and how it can reduce the risk of going down the wrong path and making mistakes. And at the end of the day, we all want a project to be successful. And this tool is the single most important thing we’ve found to project success. So Kedron, if you could talk some about what Discovery actually does.

Kedron: Yeah. So let’s jump in.

As Alan mentioned, each of these activities are going to build on one another, and each one is going to help us shape and get better clarity on what the actual outcome ought to be for kicking off a project. And as Alan was describing the various moments in which Discovery is important I’ll just toss this out to you right now that the sequence that we’re going to look at here in the next few minutes is built on the assumption that you have maybe an existing app or a website, or you’ve got an existing experience and you’re looking to add a new experience or new set of features to it or to solve a new set of problems. So I want to just call that out as a moment where Discovery could be really valuable for you and your team is if you’ve already got something. Discovery isn’t always about just starting something from the ground up.

So if we were going to do something from the ground up, some of these activities might be rearranged in their order, or we might add some or subtract some because each problem that we are trying to tackle with Discovery, we tailor a solution specifically to that based on your organization’s context.

So with that, let’s go ahead and jump in and actually look at some of the activities and the process as we move from start to finish in the Discovery.

So first up, regardless of whether we’re starting something from scratch or jumping into an existing project, we always kick off a Discovery by setting the table. And what I mean by that is we want to create clear expectations for everyone in the room. And quite often this includes a list of things, expectations of things to do and things to avoid that are all geared around, inviting everyone to bring their most creative selves.

So one of the purposes of Discovery is looking for creative insights. We want to make sure that the kickoff to Discovery is inviting everyone to bring their best creative insights. And in order to do that, we make sure everyone knows what the ground rules are. There are ground rules that are focused on collaboration and sharing candidly and being expressive and looking for creative ideas. So we’ve found that setting the tone early on is critical for shaping the next two days worth of work.

Discovery is typically two days in time as we frame the problem and understand some users in the first day. And the second day is really about honing in on what exactly that user journey is supposed to be.

Alan, you want to jump in here?

Alan: I did, actually. On the creative energy part, some of the people in these sessions, they feel like they aren’t creative. And so we’re trying to give them permission to still speak up. Because they’re there for a reason, and we want them to share their perspective and contribute to the project’s success. So this setting the table is trying to make it a place where even if they would not describe themselves as creative, they can feel free to express themselves.

Kedron: Yes, absolutely. Yup. And many of the activities will walk each of the participants through and help them step into those creative activities, not just throwing them in. We’ll guide them through and help build that creative confidence as we move from one activity to the next.

So once we have the expectations clear, and everyone’s kind of warmed up and ready to really bring their creative thinking, we then focus on defining the problem as best as we can. And most Discoveries have a sense of what problems are the right ones to solve. But in our experience, each individual that arrives at a Discovery kickoff meeting probably has a little bit different perspective on the problem, or possibly a problem that is closely related to it, or maybe a dependency that also needs solved.

So we focus this time on really trying to unpack everyone’s assumptions, get them out. We provide an activity that allows people to express on sticky notes, kind of like what you see behind me, and get their ideas out and in front of each other so that everyone else can see what those assumptions are. And then we begin to craft a problem statement out of all of those assumptions. And we’ll go through an activity that prioritizes those assumptions. There’s a handful of activities actually that help us do that. Some of them include a dot voting exercise, or some of them include mapping the problem statements, maybe on a two-by-two that looks something like effort and impact. So we kind of get a sense of what problems fit where, and then we focus that down into a How Might We statement. And you may be familiar with How Might We statements, but there a way to craft a problem statement that really focuses on what the user value is and the outcomes that we expect.

So we find that mechanism of crafting a problem statement in that way helps bring clarity to the problem that we’re trying to solve. And because we’ve approached this problem definition activity collaboratively, this is a great opportunity that really begins to cement alignment across the team. So everyone’s had the opportunity to participate in framing that problem and also weigh in on what they think those priorities ought to be. And then everyone gets to see what the outcome of that activity is. And that becomes kind of the guiding question that we’re trying to solve throughout the rest of the activities that we’re going through during Discovery.

So that leads us up to the next activity. So once we have a firm understanding of what that problem is and the outcomes that we’re looking for, we’ve moved over into persona development. Nowadays, the teams that we work with have personas there ready to go. They’ve done the research, or they possibly have worked with us prior to starting a project to do some initial Discovery or understanding of who their customers are or who their donors are, who their primary users are. And we use that persona artifact then to inform our own empathy. It helps us build empathy. It helps remind the team of who we’re solving for. So if the team doesn’t have a persona—sometimes the projects are so tight and we need to get working—we will always create a persona, even if it is informed by the intuition and experience of the team members involved in a Discovery activity. We find that having an outside objective artifact that we can reference that we can build and design towards really helps smooth out the communication as the project gets underway. So we’ll know, “Hey, we’re not designing this solution for ourselves; we’re designing for this individual, this persona that we’ve created.”

When we’re creating a persona, why we do that is to build empathy for who we’re solving the problem for. So we’ve got a problem statement, getting to build an empathy for users. And this is best, of course, with actually doing research, getting out of the office, talking to actual individuals that you are solving for, whether it’s donors or volunteers, congregants, that sort of thing. And then we take insights from that research, put it together and create a full-fledged persona. And it really, really helps us build empathy in ways that typical marketing data or demographic data can’t do. It’s really hard to empathize with a data point that is highlighting averages or highlighting things like income or technology use and that sort of thing.

So we’re really trying to get into understanding the motivations behind why that person is engaging in the solution that you’re trying to build for them. So we’ve got a couple of examples of some different fidelities of persona, and these will probably look familiar to you if you’ve got personas already on hand. And really you can see here that there’s some aspects to them that make them human. We get a sense of who they are. We get a sense of what they’re after, what their motivations might be. We get a sense of what their goals are and the things that are holding them back and the things that are blocking them from achieving the things that they need to do. And the jobs that they’re trying to accomplish with your product or service.

Alan: I just want to mention these are real personas from a project that we did. The hand drawn one was drawn by Kedron while we were in this room doing Discovery. And then this project had a couple personas. The more polished one also came from a hand drawing, but after the Discovery, we turned it into a document that then could be more easily passed around the office and shared with people. So these are not hypothetical; we did these.

Kedron: Yeah, absolutely. These are real project artifacts. Again, because we’re trying to anchor our problem-solving in not our own {missing audio}. So this is the artifact.

Then we move into some mapping exercises. And this particular exercise, it’s placement in our conversation today is, again, reflective of a project that already exists. So we walk through the user from start to finish to get an understanding of those elements that are frustrating to the user, elements that are bringing satisfaction to the user. And we’re really looking for those key opportunities, those key moments that introduce this new value that we’re trying to unlock via this problem statement that we talked about at the very beginning. So, as you can see, these activities are building on one another moving from setting those expectations for collaboration, then moving into defining the problem, and then understanding the user through a rich and full persona.

And then beginning to map out that user journey as they engage with your product or service and dialing into those key moments that are important to really focus on so that we know exactly where to spend our energy in solving the problem. So if we have a clear understanding of those critical moments, it gives us visibility into the right moments in that experience to really spend our energy. Even though we might be solving for the whole experience there, we’re beginning to prioritize or see where those critical moments are. And if we’re kicking off a new project on top of an existing project—maybe it’s a new set of features—we map in what those new outcomes are meant to be for that user. So we highlight what new jobs the user is trying to do and fit them into the existing experience. Even though we don’t have a clear sense of the real solution yet, we’re trying to get a sense of where the right moment is in the journey in order to provide that solution.

And next up, we’ll see just another real project artifact of how a user journey map gets expressed. And this, the top one is a high fidelity version. It’s kind of a refined version of something that’s similar to the photograph beneath it. And what you can see here is those moments across the entire user experience, and then you’ll notice the highs and lows, those frustrating points and those satisfying points for the user. And then you’ll notice some highlights within that journey that we’re going to spend more time and attention on to really make sure that those experiences are dialed in because those are the critical ones. They’re often the make or break moments within that journey that can set a project up for success.

So once we have those clear moments within the journey—and there might be two or three, there might be four or five of those moments—that’s when we move into ideation.

So you’ll notice that we are several steps into Discovery before we jump into ideation. And we’ve found that in order for brainstorming to be effective, it is critical to have the right ingredients, the right fuel for the fire. And we believe that the right fuel for a productive brainstorming session is a firm understanding of the problem. Look back at defining the problem. That’s the first activity we did. And then of course having a firm understanding of the user and their experience. Once we have a grasp or visibility on those elements, that is the required fuel for a brainstorming or ideation session.

So with those in hand, now we can have a productive time together generating all sorts of ideas that really reflect those key moments and the kind of the creative outcomes that might come from the team collaborating together. And we use a couple of activities to move the team collectively through this. So one of the dangers in working with a designer—whether it’s in-house or consultancy, whether it’s a product designer or user experience designer—is giving them the problem and then handing it over to them and saying, “Just go design a solution for us so that we can then turn around and build it well.” Quite often, that gap between who owns the problem and who’s providing a solution for it is too big. So this moment in our Discovery session is to bring all hands on deck.

So everyone has an opportunity to provide insight into how that problem might be solved. And when everyone has opportunity to provide insight, that’s when really great ideas can come together. So someone from finance might have a very unique perspective on solving that problem compared to someone that is maybe over in design or user experience, because everyone sees the problem from a unique perspective. So we’ve all collectively framed the problem. You’ve got a firm understanding of what outcomes we’re trying to get after. And we’ve got a deep understanding of who the users are and where those key moments are. And now we’re collaboratively all trying to solve for that.

And the activity that we lean on most in this particular moment in Discovery is a collaborative sketching activity. And you might be thinking to yourself, I’m not a very good artist, or I don’t draw very well, but that’s not the point.

So you notice that last bullet there is that we’re really looking for the quantity of ideas, not the quality of ideas. So it’s not the quality of your drawing skills, or it’s not the quality of how well you’ve formulated a particular solution. The goal is to generate as many ideas as we can because through that volume of ideas and then merging them and watching them collide together often comes from the real gems, those real insights that we would have never got to otherwise. So without that volume, some of those insights just kind of get left behind without us even being able to discover them.

So this collaborative sketching, yeah—jump in, Alan!

Alan: I’d like just to talk about this collaborative sketching, because it’s a moment where people really get their hands in it. And so I’ll give an example of how it might look. Let’s say we realize people are struggling to sign up for an upcoming Sunday school series—this is an eight-week series and we want to get people involved, and they just don’t know how to sign up. So we give everyone in the room printer paper and a Sharpie and 10 minutes to just fill out as many different ways you can think of to make it easy for people. And we want to see variety. We want to get all the different ideas out there. So then we can start discussing them and talking about them and narrowing in on the ones that like, “Okay, this seems like this might actually do what we need. Even the most in-their-shell people, this brings them out.

Kedron: Yeah, absolutely. It’s a participatory collaborative time, and it uses high energy. And we’ll run through this activity a couple of times for each of those kind of key moments. So we’ve had ample opportunity to really get in and express those various ideas that might solve for those key moments so that we have some solid work in order to kind of measure against.

And that actually brings us up to this next activity within the Discovery. And that’s really to begin to focus our efforts or focus our energy on solutions that really start to feel like this might be worth pursuing. So we gather all the concepts together. And in many of these sessions where there’s, you know, a half a dozen to a dozen people that are participating, we run through three to five key moments within that user experience.

And we might be looking at 50 to 100 different concepts that we need to evaluate. So, because we’re looking for the quantity over quality, sure, there’s going to be some concepts that don’t make the cut. That’s fine. There’s never enough time or enough money to do everything that everyone wants to do. That’s just the reality that we’re well aware of. So we gather all those concepts together and begin to affinity map them. So place the like concepts with like concepts. So if there is an essence of an idea that’s expressed across multiple sketches, we get to just group them together so that we can see where maybe the volume of activity or people’s energy is being focused or where individuals are more interested in exploring. So getting a sense of where the volume is within all of these different concepts is helpful to know where people are focusing their energy, because that’s often a cue or a signal that it may be the right approach to solving a problem.

But then the next step is we actually do a.voting exercise. And this activity is critical for allowing a diverse team to express where their interests are in a way that is non-threatening to their peers. This activity is facilitated in a way that allows the executive director to vote in the same manner as the marketing intern. And we try to reduce those social complexities within this.voting exercise so that the best ideas win, not necessarily the ideas that are always backed by the biggest title in the room. So this voting exercise helps kind of level that playing field, again, to really focus on where the value is for the user and for the organization. And you want to see something like—

Alan: In like 15 seconds, how does dot voting actually work?

Kedron: Yeah. So dot voting—I guess when I say it, maybe it does sound a bit like a buzzword, but imagine if you will—actually, let’s go to the next slide. Imagine if you will, there are gobs of ideas, all plastered up on the wall, and you’re trying to determine which ideas are the right ones to pursue, or which ones are the most interesting or the most innovative, which ones solve for those key moments in the most unique or compelling way. So everyone that’s involved in this collaborative sketching exercise gets a limited number of dots, little stickers. They get a limited number of votes, and it’s their job to cast those votes on the ideas that are most interesting to them or the ones that they feel are most compelling that solve for those moments, the best. And all the dots are the same color, and everyone gets the same amount with the exception that we’ll often give the product owner, whoever that might be, an extra vote.

So there is that tiebreaker ability so that whoever is actually responsible for delivering this thing, whoever’s got the most skin in the game, has a little bit extra weight in the voting exercise. So everyone casts their votes. Usually by the time, even if there are 50 to 100 ideas expressed up on the wall, usually you begin to see a pattern of which ideas—because we’ve already clustered the ideas into like ideas. So they’re somewhat organized, so people can see. In this particular case, you can see lots of maps, all grouped onto the left side of the screen. Well, there’s a map component, obviously, that could be important to the solution. So you’re getting to see the dots kind of gravitate towards the winning ideas.

And then what we do from there is we take all of those ideas. Now you’re going to have lots of ideas that got voted on that you’re still not going to do, but these are the ideas that collectively we’ve said, “Here’s where we should spend our creative energy.” Once we actually go through the work of testing ideas and getting out of Discovery and actually exploring solutions, these are the ones that we should focus our exploration on.

So that’s the beauty of having all of those ideas voted on—again, collaboratively, we all did this as a team. So there’s some alignment around which ideas are the most compelling. And then one of the dangers that we try to avoid with this activity is a clear commitment to a particular solution because we haven’t quite done the work of teasing out all of the criteria for what it would take to build out the solution, both from a user perspective and from a technology perspective.

So leaving it somewhat unstructured at this point is on purpose. We have a sense of which ideas are important, but we don’t know for sure out of all these ideas, which one is going to be the winner for a particular key moment in the experience. And we tease that out later on in the project cycle.

But after we go through this focus activity, then we begin to map out or build out the experience. So if you remember earlier, when we talked about the journey map, if this was an existing project, we have a sense of the user experience from front to finish. Well, now we have a sense of the types of solutions that could fit into that experience that really satisfy those key moments. So we break the experience down into manageable chunks. And what we’re trying to do in this phase of work is really start to focus on what would it take in order to define this just enough where we could begin to have a reasonable way to prioritize different features, prioritize different bodies of work.

And that of course informs how you plan a project on a timeline and how you plan a project from a budget perspective, all those things. So hopefully it’s easy to see at this point, we’re converging from the very beginning, where things are maybe the most abstract, and by the time we get down to mapping the experience, things are becoming fairly concrete. And even though we don’t have all of the details worked out of the particular features that got voted on, we kind of know where those moments fit within the user experience. And we begin to kind of be able to put some edges, some boundaries on what it would take to do some of that work. And what we’re trying to do out of all of this, of course, is prioritize, build out a roadmap so that we can see when does this actually get introduced to your user?

So these are the building blocks in order for us to get there. And once all that activity is done, we kind of get to step into some very project management-specific activities. So we work with the team collaboratively to build out a RACI matrix. So we identify who’s responsible for the work. Quite often, if we’re involved, we have a big piece of that if we’re building it, and then who’s accountable for the work, who has the skin in the game within the organization, who gets consulted on projects. So there might be an IT team that needs consulted. It might be a marketing team. It might be a third-party is often the case. And of course, who needs to get informed, who needs those updates? We found that doing this work at the cap of a project, make sure everyone has clear expectations of marching orders, like who plays and when, so that’s an effective way for us to, as a team, move in step together.

Then the outputs. We’ll just talk a little bit about outputs and what do you get at the end of a Discovery session. What does the organization actually have? Well, you’ve got a fully mapped out set of stories, or we call them in our world epics, stories, and backlog. And you can think of an epic as a large collection of features. Stories might be a smaller collection of features. And then the backlog is the collection of stories or features that didn’t make the cut but are still worth doing, or at least still worth considering on the road.

So you’ve got a roadmap and then you’ve got a clear visibility into what do we take to get a release number one out. So if you’ve built a website or an app, you know that release one is always just one of many. And what we’re trying to do with the Discovery session is get clear visibility on what it would take to release this body of work that we just spent two days collaborating on.

And then of course, estimates, and these are high-level estimates. There’s still some work to be done to tease out. And we still have a list of those collaborative sketches, those winning ideas that have some ranges in complexity naturally because we haven’t defined them yet. So things are going to be fairly high level, but they’re there in a significant enough definition to them where we can begin to build some estimates around them.

Which then would lead to the very next phase outside of Discovery, which would be building out wire frames. Quite often, this wireframing piece is part of Discovery. Even if the next phase of work doesn’t include building a thing. Quite often, there’s a phase of work kind of at the tail end of Discovery that is putting some edges around those ideas. So that at the very least, the team can look at this body of work and see the narrative, see the user experience in enough fidelity, not all of the fidelity, but at least in enough fidelity to know, does this satisfy the problem that we’re trying to solve for.

And quite often, those, those wireframes will inform user testing and the whole process of validating an idea before you build, but at least you’ve, you’ve, we’ve framed these wire frames in a way that is built on collaboration built on team alignment, built on a firm, understanding of where the value is for the organization and for the end-user and approach from a creative and hopefully an innovative way. So those are kind of the mechanics of Discovery, like how we would walk a team through. Now, like I said, each Discovery is tailored specifically to the context of the problem and the organization that’s trying to solve that particular problem. So this isn’t a cookie cutter, but this gives you a general sense of the modes that we’re trying to move through in order to get clarity on what it is that we can look for in a release one and what it is that we can look for, even as we move out of Discovery into a testing phase or idea validation phase with those end users, those personas, before we jump straight into development, all of which is to help us again, mitigate risk generate new and creative ideas and bring alignment, bring alignment with the team, both the, the team that is setting those expectations of those outcomes, the team that is doing the work of building and the teams that are supporting it in various manners.

So we found that moving in this way brings clarity and alignment. And this is part of the playbook at Agathon. This is how we have done this enough where we know that this mitigates so much risk down the road and it’s worth doing in nearly every start of a new venture.

So with that, what happens after Discovery? Alan, I’ll kick that over to you.

Alan: Yeah. So two days in a room—one or two days—and then you come out with these outputs that Kedron already talked about. But now what? Because of the work that we just did, we’re now in a position to talk about how much does this really cost? Because we know the contours and, connected with that, how long is it going to take? And that’s going to be important for planning and in some cases deciding whether to go forward or not. And then it sets the path forward for the project’s next step.

Kedron mentioned testing ideas, idea validation. That’s sometimes needed, where we think an idea is good, but we need to actually do like a real basic prototype to confirm that and see how users interact with it. Sometimes idea validation isn’t needed because other people have done that. We can look to other examples out there and learn from them and move more quickly into development.

I will say never, ever have we ended a Discovery session and someone said, well, that was a waste of my time. It has always been the opposite where there’s just excitement and enthusiasm and alignment. These things are fun. It’s one of my favorite parts of my job. But more important is that confidence it brings, that we are actually spending our limited time and efforts on the right things that actually help your users, and they’re gonna serve them well and not waste a lot on the way to get there.

Kedron: I was going to just add to that that, quite often, Discovery is jumping in specifically to help solve a technical issue or a build out, maybe it’s a new mobile app or a new feature or a brand new website. This body of work is effective for all sorts of strategy because it focuses so much on the overlap between what the user is expecting or meeting those unmet needs and what the organization can do.

Just to give you an example of the kind of outcomes that we get out of these kinds of activities: We were working with an organization not too long ago where they brought us in to help them reposition their website. They wanted us to help them kind of get clarity on their users and get clarity on their message for connecting with those users. And the end result of the Discovery session {missing audio}.

Sure, that work is good gets done, but the real output was this organization realized that their mission was not aligned with their actual user needs. And they went back to their executive team and they developed a mission statement that was informed by that overlap between, “Hey, who is it we’re really trying to serve? And what is it that we’re really good at? And what is it that we can really do well for them?” And of course that in itself is about the most significant amount of work that anyone can do when it comes to positioning, is getting clarity on what your mission is for your organization.

So yeah, we spend a lot of time talking about how this affects features and all, but this can be used in many different ways. And the outcome is sometimes unexpected. And this team didn’t go in thinking they’re going to look for a new mission statement, but it was clear to them that they had to do something about it.

Alan: Yeah. And that’s a fantastic story of again, pointing to new insights coming out of Discovery by design.

And so I think we’ll stop there because I want to be conscious of the time. And I know we have a few questions in the Q&A, so Peter, if you could read one or two of those off, we’ll go through those.

Peter: Sure. So the first question says, “How do I convince the decision makers on my team that Discovery is important?” We’ve talked a little bit about the mechanics of Discovery. And a lot of the value of Discovery is kind of self-evident, I think, but there’s always someone else that needs a little convincing. Often that’s going to be the board of your ministry, board members of your ministry that might be members of the financial team that are responsible for the purse strings.

Alan, as the CEO of Agathon, a lot of the times you speak directly to a lot of those people on their level, on that same sort of plain. Talk a little bit how you translate some of this fantastic knowledge into a pitch, if you will, for the decision makers so that you can actually get everybody on board beyond just the process itself.

Alan: Yeah, I love that question. Thank you.

I’ll start by saying what not to do: Don’t get down into the weeds about, “Hey, we want to do this, this, and these different exercises.” That’s not where they are. They’re concerned about vision and money. And so explain why Discovery addresses both of those. It ensures that the work we’re about to do advances the vision and mission, and that we’re not wasting time. And it ensures that we’re being good stewards with the budget and again, not going down rabbit trails. And Discovery is a safe way to explore ideas. And you can always offer, you know, ”If at the end of Discovery, we look at this and you don’t like it, that is a natural place to stop.” Now in all of our Discovery sessions that we’ve done with people, only once has that happened. And it was because they were reliant on an outside donor, and that donor had life circumstances come up. In every other case, this clarity of direction is so compelling that the projects have moved forward.

So that confidence that you’re doing the right thing, and you’re doing it responsibly, if you can help them understand and believe that, then it’s an easier choice for them.

Kedron: Yeah. I would just add one thing to that. Cause all that is just so spot on. And the thing that’s sometimes easy to forget is if we’re talking about Discovery as a discreet thing, is that this work has to get done regardless. We’re just saying let’s do enough of it upfront that we can avoid the pitfalls of trying to spread it out over months at a time. So it’s a compelling argument from that perspective as well, I think.

Alan: Yeah, exactly. It has to be done either way.

Thanks. Those are all great points. I think that highlights the fact that Discovery is an investment rather than a straight expense. And if you’re talking to someone from finance, that kind of language of investing in the project and investing in the mission can really help communicate the value of it. That’s great.

So another question that came up is pretty straightforward, but I think it has a lot of twists and turns potentially hidden in there. It says, “I already have a request for proposal or an RFP. Why do I need Discovery?” And at the heart of that question is, you know, a lot of the times you’ve done enough thinking about the problem and you have a decent idea, you think, as to what the solution is going to entail, what it’s going to look like enough so that you can produce this document, this RFP, and you can start shopping that around. It’s a different approach. It’s one that starts from our perspective and looking out toward a solution that might satisfy that versus Discovery where it’s much more coming into the organization and generating those ideas.

But talk a little bit about the pros and cons, potentially, of the RFP approach and how it differs from Discovery in practical sorts of ways.

Alan: I think Kedron and I would give nearly identical answers on this one. Kedron, you want to take it?

Kedron: Yeah, I’m happy to jump in. So in our experience RPS are often, like Peter said, they’re created out of either a mandate or an inkling of like maybe there’s a technical solution that’s coming in, and we need to find a way to map it to our current processes. And we need some help to do that. So the RFP goes out.

In our experience, almost every single time, the solution that is manifested in the RFP is that organization-focused solution. And it’s usually that organization looking squarely at a technology choice. Whereas Discovery is an intentional moment to say, all right, our organization has needs and capabilities, but we need to look at that from a user perspective. How do we marry those together? And that I think is a key difference in many, many, many RFPs and Discovery sessions, because quite often that Discovery session isn’t done prior to an RFP and maybe an RFP might be effective as part of an organization’s formal processes.

And if so, I would do a Discovery before that and use that roadmap as a way to flesh out an RFP. So that at least the thing that you’re fleshing out, that you’re proposing to build is informed by actual users’ needs and wants and the technology capabilities that the organization has to satisfy those.

Another thing that I think is worth calling out the difference between an RFP and jumping into a project like this is that there’s that creative moment that often gets cut out of RFPs, where RFPs are almost like a function of finance. Whereas a Discovery is a function of ideation and creativity. And those aren’t at odds. They’re just different ways of looking at a problem. So approaching the problem through a Discovery-first lens has baked into it the opportunity to be creative, to be innovative, to stand apart, to stand out, to provide something new and unique that makes your offering compelling enough to attract people, to actually engage with it. Versus like thinking through a list of features and a list of requirements in this abstract kind of document form, just can’t quite satisfy. So I think Discovery generally has a more creative oomph to it, and the output is more compelling for the users to actually have to use this thing.

And then the last thing that’s worth highlighting is if we are shaping the solution from a user perspective, quite often, we don’t know what that solution is, and you have to go through some ideation, you have to go through the activity of exploring some solutions, seeing where they fit within the overall context of that user experience to know, really, which are the right ones to solve for. So, again, coming in from that lens, it can feel even arbitrary to like, alright, this here’s the technology. Now it begins to evoke this sense of the organization is pursuing a technology solution instead of a user solution.

So I guess that would be my two cents. What would you add to that, Alan?

Alan: Not much of anything. I mean, RFPs are often focused on how this thing must be done and Discovery is what is it we’re trying to do. The point you made about Discovery coming in before an RFP, that’s a really great way to do it if you’re still trying to figure out the thing. And too often RFPs, they tell you how to do your job, which is imperfect at best.

Peter: I love that. That point really stood out to me as well, Alan, because historically I’ve been rather skeptical of the use of RFPs, but reframing it as one potential tool coming out of Discovery to capture, from the research perspective, what it is you’re trying to build. I can see a renovated use for the RFP as a tool coming out of Discovery. So I do like that, that idea that they’re not strictly at odds.

We’ve got time for just one more question, and I’ll open it up to both of you again. The question is, “Is Discovery a one and done activity, or is it something that we’ll need to do each time we launch a new project or maybe even a later, you know, over and over within the same project for different feature sets?”

What do you guys think? Is Discovery kind of something that you do and then forget about, or is it something that you make sort of a part of your workflow?

Alan: I think it’s somewhere in the middle because it does pull people out of the routine for a day or two. We want to be mindful that people have other things to do as well. And so we don’t want to play that card too often. But it is important to do periodically. Obviously at the start of a project, a new project, but Kedron mentioned it also applies to work that’s been underway for a while, and maybe there’s a new round of features coming up.

Or, a project we worked on—I guess it’s been about two years ago now. It was based on facilitating face-to-face interactions, and then a pandemic happened. And we had to do a new round of Discovery to figure out, “How do we pivot so that all these things that we were going to do in person can be done online?” So that was a natural point where, okay, we need to regroup and figure this out again.

In our experience, the most frequent repeat is about annually. Again, it’s a big exercise. It’s not something you do every month. You set the vision and then you do the work and then you keep an eye on, you know, have things changed? Do we need to regroup? Kedron, what would you add to that?

Kedron: The cadence that is maybe easy to pick up with many of our clients is the cadence of their organization. So that often reflects the moments we jump in with Discovery. So when annual planning kicks off, a lot of conversations about right, “Should we do Discovery for these new objectives that the organization is going to pursue over the next year?” So that’s often the trigger for project work is when does it fit within the organization’s typical approach to delivering new value to their users.

And the most frequent is if the team is working on quarterly goals, sometimes we’ll come in for a day and do a limited Discovery session for the next quarter. So we don’t go through all of the deep dive into all of the activities because it’s pretty regular. We all have the user’s top of mind and all that sort of thing. So if the interval is shorter, we accommodate the Discovery to the build of work in front of us. So I’d say those are the kind of the two triggers, the typical organizational cadence. And some organizations only pursue projects, you know, big capital projects, every couple of years, and quite often that’s when we’ll jump in.

Peter: Great. Well, guys, that’s awesome. This has been fantastic content. We’re coming up to the end of our time together. I want to thank everybody for attending, whether you attended live or you’re watching this recording. As a reminder, the video will be available along with the slides once we can get that processed and sent out. Thanks again to Alan and Kedron for preparing and providing this fantastic content on Discovery and framing it within a greater chance for success on your project work at your ministry.

If you have any other questions, feel free to contact us at any time. As we like to say, at Agathon conversations are always free. We would love to talk. You can see my email addresses there, [email protected], or you can call us anytime, (888) 543-9766. I’m at extension 81, but anyone here would love to talk to you. So please do get in touch if you have any other questions about this or any other content pertaining to your ministry. We’d love to chat.

Thanks again, and hope you guys have a wonderful rest of your day.

Kedron: Thank you all.