Chapter 4. Phase I: Question
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.
Know What We Need to Ask and Answer
Isn’t it tempting to do what we’ve already done because it’s the road we know? It is for me. The next section we’re taking on is the “how” of creating better business outcomes.
Above the inside door of my office, there’s an Italian clock, and above that, there’s a little sign printed on regular laser printer paper. It reads “All Roads Lead to Rome.” My team gave it to me after an arduous time helping an e-commerce company hit their $24M product launch goal. The phrase had become the mantra for the last few weeks. “All Roads Lead to Rome” was what we kept repeating to our client (and to ourselves) to focus everyone on the process rather than fixating on getting to a specific answer, so we could create a strategy together that would actually work.
You lovers of history may recognize the phrase. I learned it during a college course in Western Civilization. The Roman Empire, you might remember, drove the greatest economic expansion in history—connecting remote places and people together through commerce. One way it did this was by building a vast network of roads connecting widespread communities so that Roman legions could deploy and harness resources wherever needed. The city of Rome was effectively the center and genesis of their universe, so the Empire built its roads from that place, outward. If you were somewhere wandering lost in the land, you could be guaranteed a way back “home.” By following any dirt road, you would eventually connect to a wider road, until it reached a paved road, and all paved roads would eventually lead to the center of Rome.
This analogy comes in handy when a team loses its way and is wandering through the vast confusion of strategy creation, lost between the goal and all the data, various perspectives, and too many options. “All Roads Lead to Rome” is a phrase that can remind you to follow and trust that the resilience of the process will deliver you to your destination—that is, to the winning, workable strategy.
At another level, the phrase reminds you that most of the time people already have the wisdom and the knowledge required to get where they need to go; the trouble is that the key ideas may be scattered far and wide throughout the organization in the minds of various doers and functional leaders or in the larger ecosystem.
Of course, the approach the Romans took worked for the Roman Empire. Other empires have relied on different ways to connect remote places and people. Similarly, creating strategy relies on a process, but not just any process. The notion that “All Roads Lead to Rome” depends on having a process for creating strategy in a collaborative way: a process that’s flexible yet robust, and has been tested enough so that you can place your faith in it to give you business results.
The key for building great strategy is to figure out the way to connect seemingly disparate parts together so that something results from it and you “get there.” So how do we do this? And how do we do this collaboratively so that what is decided gets made into a reality?
Let’s get down to business and explore the meat-and-potatoes steps of creating strategies using the QuEST process framework. What follows are the details behind each phase: Question, Envision, Select, and Take. The QuEST process framework will guide you through a structured, directed way of developing better business outcomes.
You will learn the actions, steps, and responsibilities to execute each phase. I’ll also highlight some issues, which I call temptations, that you will want to watch out for as you move through the strategy creation process.
How It All Works
First, let’s take a minute to clarify the meaning of the phrase “process framework.” A process framework is a structure that allows for a set of actions (processes) that are related to one another and should be done in a preferred order.
I call it a framework, and not a methodology, because the structure is generic and is flexible enough to be applied to different applications in different contexts, meaning different industries, businesses, kinds of companies, and business units.
The process framework is flexible because, even though the phases take place in a given order, at the end of one phase (and the beginning of another) there is a “gate” you have to pass through. Before you get to a gate, the process framework recognizes that a learning loop happens inside each phase. And it’s not so rigid to suggest that you always follow an inflexible series of process steps, because the act of strategy creation involves people learning and formulating ideas. Creative processes are not linear, and nor are they purely analytic. Much like life itself, there’s a flow to it. Strategy creation is unfortunately much messier than an “A to B to C” kind of model. Instead, the New How provides a framework of sequenced phases so you know what particular things you want to accomplish, and in what order, to optimize business outcomes. And, as you exit a particular phase, it’s important to make sure certain things have been completed. That’s the role of each gate.
The QuEST process framework allows you to create strategies in a way that is structured but fluid, messy but controlled, fast but deliberate. It addresses many common concerns you might have along the way. You might shy away from creating strategy with other people because you fear that involving others will slow you down. However, the QuEST process framework allows you to keep things moving by involving people for specific reasons so that you can make decisions that roll forward and continue building on each other.
Remember the idea of satisficing from Chapter 3? It applies right here. Keeping things moving will force you to define when enough is enough, when it’s time to move on, and when you can stop one thing and start another. It’s the opposite of trying to get things 100% right and achieve the “perfect” solution. The QuEST process framework allows for satisficing, which is essential to the larger success because it lets you keep going and continue making progress.
This process framework also allows you to have a certain cadence of conversations that leads to timely decisions, so people know what they’re going to do first, second, third, and so on. It lets them know what is coming next and what they’ll need to do to prepare for the next thing. Most importantly, QuEST accommodates the messiness of strategy creation, given that it is a creative act and one that’s almost never neat and tidy. It helps you to make the messy choices in a conscious and engaged way.
The QuEST process framework is built on four repeatable core phases that focus your team on the essential decisions you need to make by the end of each phase. The process framework helps you turn business opportunities into visions, visions into strategies, and strategies into specific and measurable plans of action. It leads you through a set of steps that allow you to clarify the problem as a team, figure out what success looks like, ask and answer the right questions, generate ideas, sort ideas until you arrive at one final best strategy, and then create clarity and accountability for what needs to happen.
The Question Phase: How It Fits
The first phase of the QuEST process framework is the Question phase (Figure 4-1). During this phase, you build a rich understanding of the situation you are facing by asking and answering the right questions. It precedes the Envision phase because you need to know what the problem is and have everyone understand what you’re trying to accomplish. The Question phase is done before the Select phase because you need to be clear on the problem scope (which I’ll discuss in the next section), so the resulting strategy will match the problem.
Working Parts of the Question Phase
The Question phase is about making sure you understand the problem with enough fidelity, gather all the facts you need to get a clear picture of where you are today, and organize and share the results of the fact-finding to build understanding of and agreement on the problem being solved.
The Question phase is about going in with an open mind, so everyone is open to new information, insights, and directions. It requires stepping into the initial discussion of the problem in an inquisitive way to look at what the problem actually is, and to gather all the relevant information necessary to understand what needs to be solved.
There are three steps to the Question phase: identifying the problem, gathering relevant information, and sharing the findings to make sure the problem being solved is well understood. Let’s talk about the first step of the Question phase, which is necessary to accomplish this: identifying the problem scope.
Step 1: Identifying the Problem Scope
How many times have you jumped straight to the resolution of a problem, only to realize later that if you had been more thoughtful and asked more questions first, you could have come up with a far better solution? This preliminary step in the Question phase, then, is about deciding that a particular problem needs to be solved, a difficult issue needs to be tackled, or a new challenge needs to be confronted.
For the purposes of our discussion, I’ll be using the word problem as shorthand, even though some people perceive problem to be a negative word. Think of it as a way to talk about the gap between where you are today and where you want to be. I could just as easily call it “opportunity,” so if it helps you, you can mentally substitute that word. Once you’ve identified and clarified the difference between what you have and what you want, you have defined a problem. And this is the point at which you can begin to develop your thinking and start to engage the organization to work toward a solution collaboratively.
Establishing the problem scope is identifying what you intend to work on or believe needs to be tackled. Note that I use the words “intend” and “believe.” What I’m pointing to is not a definitive “this is the problem,” but rather the problem scope is a hypothesis to be tested. It’s not about “following your gut” and jumping to a conclusion (Figure 4-2), although the problem scope will surely be shaped by your gut or intuition. It’s about identifying the right people to involve, or the characteristic of the right people, similar to the way that Adobe chose Hans because of his natural gifts (see "Profile of a Collaborative Leader" on page 87). Perhaps even more importantly, it’s about setting the stage to create a solution by clarifying the underlying nature of the problem, which lets you develop an early understanding of what you, your organization, and your company are up against. Because strategy is never a theoretically perfect solution, but rather the solution that would most likely work given your context, competitive situation, capabilities, and so on, the problem scope needs to take into account the lay of the land.
I often refer to this step as the problem architecture. You are defining the shape, size, and perimeters of the problem you want to take on. Just like you might architect a house to be a “3,000-square-foot Craftsman on a hilly property,” you would architect a business problem to be “enterprise-customer-focused in the North America region affecting product line X.” To know what we are building, we need some architecture of what it generally looks and feels like. This is because encountering new problems—and beginning to think about solving them—is unavoidable. It’s the natural result of having solved other problems earlier.
The problem architecture is about characterizing the problem, getting a handle on the parameters of it, and then naming it. Getting to the essence requires that you stay open to the size, scope, basic nature, and even the name of the problem itself. It’s about clarifying who’s involved and what they care about. It also includes identifying what’s stopping or preventing the problem from being solved now. But more than anything, defining the problem architecture revolves around trying to connect what appears to be the problem with what the problem actually is...to the even more important thing that people are trying to solve.
The fact is, most complex business problems are not clear-cut, meaning there is no obvious right or wrong answer. It’s almost always about data gaps, human issues, understandings or misunderstandings, and gaps between what is and what needs to be. The problem architecture step includes both facts and data, as well as making sure you understand the human side of the business problem so you ultimately solve the full problem in such a way that it’ll stick to the organization and accomplish something.
It’s essential to determine the problem scope as the first step in the Question process phase because everything that follows depends on it. Without it, things don’t line up. When everything does line up, people can make conscious choices about how they’re going to bound the problem well enough to start building the team, confirm the scope, and, ultimately, develop the strategy to attack it.
Defining the scope of the problem necessitates embarking on a small discovery process. To do this, you may want to engage in discussions with your peers, talk to a few key people who are close to the problem, and/or have a discussion with your boss about possible new angles and questions such as: “What do we really need to do here?” or “What do we need to fix?” or “Where can we have the greatest impact?” Do everything you can to challenge your own assumptions about what needs solving. Aim high, but not so high that you lose sight of what you are actually looking to achieve.
When the focus is correct but not clear enough to act on, you’re on the right road and headed in the right direction. However, you’ll need to do some additional work to make sure the problem is bounded, but with a clear charter. Bounding the problem gives you the scope: it says what’s in and what’s not.
Table 4-1 lists some examples of statements that are directionally correct, and others that are properly bounded with a clear charter to create scope statements.
|
DIRECTIONALLY CORRECT |
PROPERLY BOUNDED WITH A CLEAR CHARTER |
|
We are going to figure out how to drive international expansion. |
We are going to build a plan to expand the video line by 20% to affect fiscal year 2010. |
|
How do we find volunteers to support our nonprofit growth? |
What are the key areas where we could use volunteers based on our 2010 goals? What skills will they need? How big will the tasks be? How many volunteers will we need? |
|
How do we sell more health care software to small businesses? |
We will find and identify the customer group that represents an underserved part of the hospice market. Target companies should range between 10 and 1,000 employees. |
When you define the scope of a given problem, it’s important to strike a balance between identifying a problem that’s big enough for people to get excited about and one that’s so big that they feel as though they’ll never make a dent. Your job is to define a scope that is bounded by a well-formed outcome or tightly coupled set of outcomes. Once you’re clear on the scope of the problem you intend to address, it’s time to identify the people (or the characteristics of the people) to talk with to learn more about the problem itself. These are the people who have something to add and aren’t narrowly defined by their job titles.
Problem scope: Roles and responsibilities
In the problem scope step, you (as the operational leader) and your team have certain responsibilities, as listed in Table 4-2.
|
LEADER’S ROLE |
|
|
COLLABORATOR’S ROLE |
|
When you’re ready to invite people into your process and launch into the next step of the QuEST process framework, you’ll want to have a kick-off meeting where you clearly state the purpose of the team and answer what seem like basic, context-setting questions such as:
Why are we here?
What do we need to accomplish as a team?
Why does this matter?
How will we know when we are done?
As simple as these questions seem, getting the team to articulate their answers is essential. Being clear about the answers at the outset will help team members know why they, specifically, are on the team and what you are trying to accomplish as a group.
This preliminary kick-off meeting is the place to begin establishing a culture of safety, because it gives you ample opportunity to set the ground rules for how you hope team members will interact, both with each other and with those who are not on the team. Getting both individual team members and the team as a whole to understand your role as leader and what you expect of them is another excellent place to establish group norms.
This meeting is also the right place to review the overall QuEST process framework, as well as the leader’s role, the collaborator’s role, and how all team members will be expected to engage during each phase of the strategy creation effort.
From here, you can move on to Step 2 in the Question phase: fact gathering.
Step 2: Fact Gathering
The second step of the Question phase, fact gathering, involves interviewing people throughout the organization (and possibly beyond—customers, partners, suppliers, etc.) to generate a deeper level of understanding of your problem or opportunity. It is about exploring what questions you need to ask (and answer) to know your strategy problem well enough to solve it.
The goal of this step is to create a comprehensive picture of the problem, so that you can discuss and share it up front, eliminating the possibility of not being on the same page about the problem your team is solving, or worse, being out of sync with the reality of the actual problem. Fact gathering is not about proving your hypothesis. It is about learning/testing to see whether the hypothesis is accurate. Whatever you find while disproving or proving your hypothesis, you learn something important.
The fact gathering step of the Question phase is critical, as many people launch into solving a problem with incomplete data and therefore an incomplete understanding of the problem they are trying to solve. This step allows you to avoid this pitfall by getting you to define four things:
What you know (and can prove) about the problem that you want to solve
What you believe (but can’t prove)
What you doubt
What you suspect are outliers or “red herrings” (conflicting or misleading “facts” that are not relevant)
Also, fact gathering creates a forum for people to voice their hunches, questions, and concerns about doing something new early on in the strategy creation process. This lets you factor in nuances such as politics and other important aspects of the situation and include them in the ultimate solution you create.
During fact gathering, you’ll learn what matters most to the organization and, therefore, what solution should you choose when it comes to selecting a strategy. So be sure to make special note and keep track of what people say is important, because it will become part of your criteria for success and you’ll want to come back to it. We’ll talk more about criteria for success in Chapter 5 and Chapter 6.
Fact gathering activities
You will engage in several activities during the fact gathering step:
Elephant hunting
Interviewing: mining wisdom
Researching: gathering data for reference
Let’s look at each of these activities in detail.
ELEPHANT HUNTING.
For the fact gathering step to achieve its goal, you and your team need to be “inquiry experts.” This means you need to stay open to what you don’t know, particularly if everyone on your team has significant expertise in the subject matter area of your problem, or if a good portion of the team has been in the organization for quite some time. It’s often the case that a group of experts or seasoned employees will be aware of topics and assume that everyone understands them.
To account for this, the fact gathering step must seek to reveal “two kinds of elephants” (Figure 4-3).
The first is the elephant in the room. This is the big issue that almost everyone knows about but it’s a somewhat taboo topic, so no one brings it up and the issue never gets addressed. Big, unaddressed “elephants” in your project can cause lots of trouble, so you definitely want them revealed. If left unaddressed, big elephants can stampede around and cause trouble in your project, so get them out in the open.
The second elephant is one that looks different from every perspective: an important but multifaceted issue that many people see, but each in only a limited way. We each have our own limited aperture—what we’re willing to look at or what we see. Sometimes our area of responsibility in the organization limits our perspectives. Other times, it’s a function of our own lack of understanding.
If I were to put an elephant in the room you are in right now (and cut off your olfactory powers and blindfold you for a second) and have you touch it, I could have you describe what you felt and ask someone sitting on the other side of the room to describe what they felt. As you both report it out, the two of you could appear to be in violent opposition. The tail is going to feel different from the tusk; the toes are going to feel different from the back. So one of you is going to say, “It’s smooth,” while another says, “It’s hairy.” Both are true. Applying this to business, typically each of us sees only a part of the full picture because we work inside complex organizations. The silos that separate us can be huge. But it’s when we can break down those silos that great learning can happen.
This second elephant is about getting to a clarity or consensus about the nature of the problem. It’s only possible to understand the full concept of an elephant when you have more complete information than each individual point of view and when you add that information up. When important issues lack a joint understanding, they’ll lead to problems down the road. But when everybody can look at the same picture, together you can solve that problem.
In order to successfully “reveal the elephants” in your project, it is important to adopt the right approach to the fact gathering step. People often come at the task asking simply, “What do we need to know?” This seems logical, but putting a focus on answers can undermine the Question step and put pressure on people to “find relevant data” to “get it right.” Factual answers alone don’t encourage people to talk about the elephants that need revealing.
A more effective approach is to put the focus on the kinds of questions that people need to ask instead of the kinds of answers that need to be found. By way of example, here are sample questions that might start a fact gathering session for a team that is strategizing on how to defend against a competitor:
What do we know about what has been done before?
Who has been involved?
What results did they generate?
What do we need to know about why this worked or didn’t work?
By beginning with process questions, you’ll treat the fact gathering step more like a discovery process, and it helps you stay open to what you might find. Adopting a position of inquiry doesn’t take much time, but if you miss it, you can’t add it back later. Make sure to commit to this step before moving on to the legwork of the fact gathering step: interviewing and researching.
INTERVIEWING: MINING WISDOM.
When you’re ready to begin fact gathering, you’ll want to interview people. This involves talking to people in your organization, and sometimes outside it, who are interacting with some aspect of the problem. You will learn how they experience the problem, so you can understand what they know about it. The process can be a bit like building a mosaic. Up close, things may look random and unordered, but stepping back reveals the entire, clear picture. At the end of the process, when you’ve put together all your pieces from all your sources, you will have a complete set of valuable information. You will know what has already been tried and has failed in the organization, how people feel about the current problem, what they believe to be true, and what key data they think is central to consider.
Interviewing is an efficient way to find sources of quantitative information, and it’s the best way to gather qualitative information; in other words, the kinds of perspective, knowledge, and insights—valuable nuggets of organizational wisdom—that help you make meaning out of the data.
It’s remarkable how often I see teams focus on numbers from formal reports and spreadsheets. They do this because they think numbers are more concrete than qualitative (subjective) information. Perhaps it doesn’t occur to them that quantitative information has its own kind of “fuzziness” and can be misleading for any number of reasons. Numbers don’t provide the empirical set of facts we often think they do.
Remember that, according to Benjamin Disraeli (and popularized by Mark Twain), “There are three kinds of lies: lies, damned lies, and statistics.” This quote is well known because it’s so easy to manipulate numbers so they say what you want them to say. That’s why it’s so important to gather the human intelligence as well.
Mining wisdom requires that you recognize the need for a balance of both quantitative and qualitative information. Sure, quantitative data is critical. It’s the language of business. But keep in mind that because numbers appear concrete, people tend to discount the “soft stuff” during strategy creation, even though subjective information—such as insights about what’s most important in a given situation or what the organization is actually capable of—is just as crucial.
In addition to being an important way of collecting data, knowledge, and insight, interviews offer the added bonus of helping you build support for your strategy early in its creation. So, with that in mind, whom should you talk to?
Pay attention to whom you ask. In the Question phase, whom you ask shapes what you learn. Many people only ask key questions of people at the very top of the organization, thinking that they must know more. Although the people at the top do hold important knowledge, be aware that as information gets farther from its source, it is distilled, distorted, and stripped of its critical nuances.
Be sure to interview deep within your organization, where things are actually happening. Make sure you talk to the people who are more familiar with how things are working day to day.
To expand your list of interview candidates, ask your initial group of candidates to nominate three other people within the organization to talk to, and pay attention to names that get nominated multiple times. These individuals can be a great resource, and they can often nominate three other people to talk to.
When the problem is a product that isn’t achieving revenue goals, talk to the salespeople who are missing their targets. Resist the impulse to go only to the people who are achieving their quotas, because they have most likely found a way around existing obstacles, or might never have encountered them in the first place. The people who are losing deals are much more likely to be aware of what needs to be fixed in the product (or channel, or sales operations) to achieve growth. When finding out about lost deals, be sure to probe for other factors that may be influencing the problem, such as pricing or the sales exception process.
For example, when you want to find the obstacles preventing the business from scaling, talk to the people handling customer service calls. Ask them what their customers complain about, because unsatisfied customers will tell you what’s not working and why they won’t be buying the next whiz-bang gizmo. The people handling these calls hear these complaints every day, and they hear them first. Chances are, they’re keeping a list, and this list often contains the raw data of what is truly happening on the front lines.
When the problem is to discover the next big opportunity, look outside the company. Opinions inside the company typically are limited and held down by “what can we do.” Instead, try talking to non-customers to find out what you might do. Ask partners, or developers, or people who run industry associations about what they need and what problems they wish the company would solve.
I know how important it is to dig in and keep digging. In my company’s early years, we worked with an organization that was trying to reconcile the pricing of a product. The product management team thought the price was too low, and the sales team thought the price was too high. Each team believed the other team’s view was self-serving and was therefore putting its revenue growth projections at risk. Both teams had talked to customers and had gathered facts that supported their different points of view.
When we took the time to interview customers, we looked beyond the questions the teams had already asked, and kept digging to find something that would allow both sets of facts to be true. What we found was that two distinct kinds of customers were using the same product in two different ways. One customer group was willing to pay a lot of money, whereas the other believed the product was overpriced. We brought these results back to the company, who shifted their discussions from pricing to figuring out how to differentiate the product into two different product lines. This fact gathering step was critical for uniting the two conflicting points of view and finding a strategy that would allow both teams to focus on the shared goal of revenue growth.
Interviewing techniques matter. For the fact gathering step to be as fruitful as possible, you’ll want to conduct your interviews carefully.
Let’s review how interviewing fits into the Question phase. I’d like to highlight some suggestions that you’ll want to consider before you begin the interviews. For deeper guidance on how to conduct interviews well within your organization, check out the “Tips for Interviewing” section in Appendix A.
First, conduct your interviews in person whenever possible, especially when dealing with complex problems (but don’t skip an interviewee if the phone is the only practical option). Remember that most times the business problem you’re investigating affects the people you are talking to, so what you learn from them matters to them. Talking with people face to face will give you insight into the factors influencing their input, as well as who the people are beyond just the role they play. Although some people might think this exercise is only for extroverts, in reality it can be done by every type of person. This is not a social exchange; these interviews are about learning, and the process is about discovery.
Knowing who the players are, what makes them tick, and what their deeper, underlying needs are will allow you to tailor the eventual strategy so that it can take those needs into account if appropriate and ultimately achieve your goals.
Tip
For a strategy to work, it has to meet the needs of the people who must support it.
Interviewing opens the door to finding things that you may not even know you’re looking for. Questions pop up in the heart of a discussion that don’t arise when you’re sitting at your desk staring at a blank piece of paper. More often than not, the more unusual the question is, the better the discovery. If you find yourself wanting to ask some unscripted question, do it. Crazy, off-the-wall questions in the heat of the moment are a signal to your interviewee that this is a wide-open conversation. This can take the interview to new place, or prompt the person being interviewed to recall something that she wasn’t aware she knew. I frequently ask, “If you were king/queen/ruler of the universe for a day, what one thing would you do/fix/change?” (see Figure 4-4). “Tell me what I need to know” complements this.
Although many people are comfortable with the concept of interviewing to gather data, knowledge, and insight, the idea of asking for help seems foreign. But asking for help during the Question phase can produce excellent results. Approach each interview as an opportunity for partnership. Ask people to help you understand what is happening. Ask them to share what they believe you ought to know. Ask them what matters most in this situation. Asking for help will open more doors than demanding information. When you ask people to help, they will often share the most vital information you need. Remember to tag the topics that matter most as potential success criteria for use in later phases.
As mentioned earlier, one area where you might want to ask for help is in gaining access to quantitative data as good reference content. If you do ask about this, try to do it toward the end of the interview. Asking for this kind of information too early may push the conversation in a quantitative direction, causing you to miss the chance to learn about the more subjective nuances, which are important. When you do talk about data, be sure to ask basic critical questions and especially about any caveats the data brings with it. Is there anything else you should know about the data you’ll be gathering? For more on asking good questions, see Appendix A.
RESEARCHING: GATHERING DATA YOU CAN REFERENCE.
Quantitative, hard numbers from reports and databases are an important part of the Question phase, but use them with care. The ubiquity of computers and vastness of the Internet mean that quantitative information is everywhere, and much of it is free and of dubious quality. Still, numbers can be a gold mine, as long as you know how to interpret the data.
The first step in knowing how to interpret your information is knowing where it came from. If you identify that the 2008 consumer software total available market (TAM) was $X zillion, it matters where that data point was found. Were the numbers from a 2009 study? Or from a 2007 projection? You may need to revisit the source of a “fact” in order to evaluate the assumptions and vocabulary of the source. Keeping track of your information sources also increases the credibility of facts in discussions down the road.
Beyond the source, try to get perspectives on the validity of the data. If you gained access to databases or reports during your interviews, hopefully you also got some sense of the accuracy and reliability of that data. For external or web-sourced content, see whether you can find other people in your company (or externally) who can attest to its usefulness.
Finally, check that your team has some data analysis skills. If they don’t, borrow someone with those skills. Two particular skills will be useful. First, if you have raw data, it will be very important to have someone with the ability to slice-and-dice numbers in search of insights. Second, you need someone who can “see through” and comment on conclusions drawn from statistics, particularly on information from polling data. For example, was there a sampling bias? Did the wording of the question make it impossible to answer accurately? What did the analyst mean by “open systems”? The skills of an insightful number cruncher can be very useful in this phase.
Fact gathering: Roles and responsibilities
As you’ll recall, each phase and step of the QuEST process framework relies on a set of unique activities. Accordingly, your role as leader and participant will by necessity vary somewhat, depending on the point in the process.
Because some of what you’re responsible for might seem straightforward and simple, you might be tempted to skip activities or ignore certain responsibilities without realizing how painful the long-term consequences could be. Moreover, as you lead, you will undoubtedly be tempted to rely on clever, familiar techniques and shortcuts to keep people, activities, and the process moving along. After all, these skills and traits have helped you get this far, right? Why ditch them now?
We avoid taking shortcuts because the goal of capturing facts is to explore the scope of a given problem as fully and completely as possible. The picture we paint of that problem must be as vivid and comprehensive as we can make it, a picture that people across the organization can validate, question, and challenge.
As the leader, you are responsible for this. The artifact of this process (discussed a bit later in this chapter) involves creating a summary document, which you’ll want to share with people as it makes sense.
In the fact gathering step, the leader plays the role of facilitator, and each participant is a discoverer. As a facilitator, your job is to make sure that every person involved leaves with the sense that they have really been heard, and that their contributions will be seriously considered and incorporated wherever and whenever possible.
From the leader’s perspective, the important part of this step is going the extra mile to set appropriate context. Remind interviewees why you want to talk to them, let them know how it’s important, and share with them who is involved and any key events that have happened. The leader can do a lot to create a safe environment for the people being interviewed so they share as openly as possible. It can’t be overstated how worthwhile it is to make the extra effort and foster the kind of environment where interview subjects don’t hold back. Unspoken concerns and silent objectives will only surface later.
Responsibilities during the capture step for both the leader and the team are listed in Table 4-3.
|
LEADER’S ROLE |
|
|
COLLABORATOR’S ROLE |
|
Step 3: Sharing the Findings
Through interviewing and researching, you will discover a good collection of “facts,” hunches, insights, and perspectives. Some of this information will be objectively true and validated in many ways. Some pieces of information may conflict with others. Some may not make sense at all.
The final step of the Question phase is to create a report back to the team or larger organization of stakeholders and players. I call this “sharing the findings.” The goal in this sharing phase is to create a shared understanding of the problem and the current situation.
Before we can share findings, they need to be organized in a form that will make it straightforward to share with everybody, so they can develop a shared understanding. Ultimately, this shared understanding will become the information basis that in effect enables the organization to think about the problem fully, and helps the team develop a strategy that will solve the problem at hand.
You’ll have to sort through the information and organize it into logical buckets to create more meaning. The way you organize these facts will change for every situation, but in general, the categories tend to include what is known, what you believe, what you doubt, and what doesn’t fit, like this:
- What is known and can be confirmed
This is information that is irrefutable, confirmed, and can be presented as fact. This can include hard numbers from validated sources, or it can be a series of facts gleaned from stories people have told in the organization. Create two subcategories for this kind of information: one bucket for information that has already been confirmed, and another bucket for information that needs to be confirmed. Note that if your data comes from a previous project, make sure to put it in the “unconfirmed” bucket. Don’t treat last year’s market share numbers or customer buying habits as automatically confirmed for this year!
- What you believe, but don’t have enough facts to confirm
This is typically something you know or sense from your own experience or something many people believe, but that you lack sufficient data to support. It’s OK to have unconfirmed facts; just make sure you tag them as such. Later, when you’re making decisions based on pivotal information, you’ll want to avoid the risk of making a key decision on information that you never backed up.
- What you doubt
This is information that somehow you don’t quite believe. It could be data from a source with a reputation for fluffy numbers, or some signal from your nonsense detector that something isn’t quite right. You can tag something as questionable, even if you don’t know exactly why you doubt it. Quite often, it is these points of doubt that show you where there are noticeable gaps between various people’s views of the situation.
- What doesn’t fit
This section is for identifying any “red herrings” or stories that people believe but that aren’t relevant to the task at hand. For example, perhaps there was some big sales deal that occurred in the past and it’s used as an argument to take a particular course of action. However, on closer inspection, the story is debunked by some hidden assumptions or special circumstances. Another example is when an issue that’s broadly recognized as a thorn in the side of the business is inappropriately tied together with the problem you’re trying to solve, because people think they can get their problem solved if they can associate it with something that is going to get resolved and/or resourced. This is like an unrelated attachment to a piece of legislation that’s obviously going to pass. When something is perpetually a problem in the organization, people often find a way to drag that issue into every project or strategy because they hope it can be solved “alongside” the core mission you are carrying. However, this will dilute your efforts. So be clear about this type of issue so it can be set aside and not revisited in every meeting. If it really is an issue, solve it discretely.
At this point, you’ve filtered and categorized what you’ve learned and put it into logical buckets so you can look at everything more clearly. The next step is to create a document called a summary of key findings, which lets you share what you have learned, what you believe, and what you understand with the people throughout the organization. The buckets we just talked about are a good exercise and will help you develop your own deep understanding of what you have discovered during the fact gathering step. However, they aren’t the final output of your report. Your report back is a much more comprehensive view and a story. When you’re confident that you have a solid framework of key findings, you need to share it. For recommendations on doing this, see the “Building a Findings Framework” exercise in Appendix A.
There are two compelling reasons for sharing the findings with your whole team. First, you want to be certain that they have the opportunity to weigh in on what you’ve learned, and to shape and add to it. This ability to add perspectives is particularly valuable for multifaceted issues, so make sure the team knows that their feedback is welcome.
As you share your findings, the team will have the opportunity to see the comprehensive range of things they need to address. They may have some new insight to share that will shape the view, or they may simply see the situation in a whole new light. Be sure to capture any feedback or insights that come up during sharing.
Second, the sharing provides an opportunity for many team members to learn things they didn’t know or weren’t comfortable admitting, which is essential to forming a common understanding. Part of the “team learning” aspect is coming to terms with the unvarnished truth of the situation. This can be an uncomfortable conversation, but it’s one you need to have in order to move forward. If it helps, consider yourself a reporter in this role, describing “what is” so that it can be dealt with. Figure 4-5 illustrates how the output of the Question phase is all about shared understanding.
Another way to look at the sharing activity is to think of it as publicly revealing the elephants that you discovered in the fact gathering step. Getting your team’s perspectives about the multifaceted topic gives shape to the different parts of the elephant that the blind men couldn’t see. One thing that commonly happens during the sharing step is the naming or spelling out of the elephant(s) in the room. In other words, this is the place to openly identify and discuss taboo topics so that people can understand them more clearly.
For specific help on how to share sensitive information so that people can learn from it, review the “Speaking Truth with Clarity and Power” exercise in Appendix A. There are three high-level things to keep in mind:
Present everything you say in terms of “early findings,” not as truth. Early findings suggest you are doing thorough fact gathering. Truth suggests you are making judgments (see Figure 4-6).
Don’t gloss over anything. Say exactly and specifically what you want other people to know, using as many distinctions and details as necessary. You want people to learn about the situation with as much fidelity as possible, so that everyone has a chance to question, learn, and ultimately come to a shared understanding.
Tone matters, so approach this session assuming that people want to hear what you’ve found and want to do something about it. Don’t unnecessarily shelter them from the findings or appear to be confronting them in an aggressive way.
The key part of this step is to ensure that team members call out all of the issues (and not try to duck, discount, or hide them) without necessarily trying to solve them. You may want to talk about company history. You may want to list what hasn’t worked in the past so you can make sure to avoid those pitfalls. You may want to bring up any unspoken elephants in the room. Good. You may even want to draw out implications for what you think all the findings might mean. Again, good. Do all of that, but do so without making any recommendations.
Sharing the findings: Roles and responsibilities
Table 4-4 outlines the roles and responsibilities for leaders and collaborators during this sharing step.
|
LEADER’S ROLE |
|
|
COLLABORATOR’S ROLE |
|
Don’t run from any conflict, deal with it; it’s a necessary part of the process. One benefit of reporting the findings and getting resistance is that it alerts you to areas and issues that might generate resistance later in the process. Better to know now than later. Better to know what you still need to ask/answer to address those issues. Face into that tension to learn what you need to learn.
Another thing that comes of this shared findings work is making sure those working on the problem don’t have confirmation bias—where people more readily notice things that confirm what they believe and discount facts that contradict their beliefs. Confirmation bias skews the facts when data that supports a belief is included preferentially and data that is contradictory gets filtered out. When the report back is public, people are less likely to become victims of confirmation bias, because at some level they think that any distortion of the facts will be exposed. There is a natural self-correction built into the system when findings are shared publicly.
Sequences of the Question Phase
Often people want to know the sequencing of Question and how many meetings it takes. We’ve talked about the three steps in this chapter; now let’s add fidelity on what types of forums are needed and who to involve. Although it varies by situation, the average Question phase for a relatively complex problem takes 1 to 10 weeks. Table 4-5 captures the steps and some key forums, and summarizes the outputs.
|
STEP 1: IDENTIFYING THE PROBLEM SCOPE | ||||
|
Who |
Forum |
Output | ||
|
Initiates |
Consults |
Decides | ||
|
Operational leader |
Experts; multilevel influencers |
Operational leader |
1–3 group meetings |
Statement of scope |
|
STEP 2: FACT GATHERING | ||||
|
Who |
Forum |
Output | ||
|
Initiates |
Consults |
Decides | ||
|
Members of strategy team |
People in all parts of the organization who might have insights/perspectives |
One-on-one interviews |
Raw data (quantitative and qualitative) | |
|
STEP 3: SHARING THE FINDINGS | ||||
|
Who |
Forum |
Output | ||
|
Initiates |
Consults |
Decides | ||
|
Operational leader |
All involved parties; open invitation |
Group meeting plus follow-up email |
Summary of key findings and implications | |
The entire sequence of Question steps goes quickly, yet it involves a lot of talking and gathering information with people to learn the problem. The operational leader will most often be the best person to serve as the process overseer (though depending on skills, another member of the team can take this role, or you may bring in a skilled outsider). You, as the leader, will oversee the interviews, create the summary findings, and organize how facts get reported back. Take care in choosing the people who are doing the interviewing, ensure that a representative variety of people are being interviewed, and verify that the information you gather is fully validated and understood by your organization before you move forward. Although you might wish to delegate the task of reporting back what the fact gathering step uncovered, ultimately it’s still the leader’s responsibility to manage the discussion that surrounds the event.
The Goal: Getting Shared Understanding
The Question phase creates buy-in among the organization because if you have the courage to call out the issues and publicly report back what you think needs to be solved and why, the broader population generally comes around and starts to naturally support the effort. That doesn’t mean this part is easy. It just means this part is necessary.
Recall that we talked about how when we know the problem, we can solve the problem. That naturally happens in the Question phase. Even if you didn’t get the right problem statement at the start of it, you will have a chance to test it and change it if necessary.
We’ve described the process as talking to key people and engaging them in conversation without trying to solve anything. There’s an openness to doing the questioning so you can keep learning. It’s this learning during Question that lets you understand the situation fully and with a broader view than if you jumped straight into problem solving. You also will see the individual problems that often are part of a single big problem. Until you unravel the issues with a degree of clarity, you cannot address all the holistic or core issues.
Of course, we complete the Question phase by naming the problem in public. This may seem unnecessary, but it is a key output of this phase. By naming all of the issues, the people involved won’t be ducking, discounting, or hiding them. At this point, you’ve already achieved some success. But there’s still something else that needs to happen.
The purpose of sharing the findings is to build a full, 360-degree view of the problem in people’s minds with minimal bias, so that team members have a larger understanding of the problem itself. This creates—or rather, supports—an organization that thinks rather than simply does the bidding of others. If you blur the lines between this effort and the next phase, you’re less likely to have clarity amongst the people involved. This means you’ll have accomplished part of the goal of Question, but will miss an opportunity for people to click on their brains to get it, challenge it, and make it their own.
After sharing the findings, you and your team have a clear and shared picture of the problem. You now enter the second phase of the QuEST process framework, Envision. Envision is where people get to work on the creation and development of your strategy options. This is often the most enjoyable part of a project, because you get to start working on the solutions to all these problems. So, let’s have some fun.
Get The New How now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
