Tag Archives: questions

Fixing the Quick Fix

Here in the United States, our business culture tends to be action-oriented. We value the ability to think fast and act decisively. These qualities can be strengths. However, like most strengths, they can also be a weakness. Taking action when you don’t know the facts can lead to irreparable harm. Deciding too quickly before you’ve examined your options can lead you down the wrong path. Fixing fast may assuage symptoms but leave the underlying problem to fester.

Treating symptoms may work with the common cold, but with many technical and organizational problems it’s a prescription for disaster. Before you chase a solution, slow down and make sure you are looking at the underlying problem, not just soothing symptoms. (Sometimes, as with the common cold, you do need relief from symptoms in order to make any progress.) Of course, we can’t always tell right away whether we are fixing a symptom or an underlying issue. But, if the problem keeps coming back, you can be sure that you’ve been dancing around manifestations of the problem, not tackling the problem itself.

Start by Questioning Your Questions

Every question contains assumptions. While a question opens one avenue of inquiry, it closes others. The questions you ask constrain your thinking about the problem and your eventual solution. For example, in one company, the executives weren’t satisfied with the speed with which the IT department delivered projects. They sacked the VP of the IT department and brought in a new one with a reputation for decisive management action. The new VP immediately started asking questions, which seems like a good sign, until you know her questions:

Where is the dead wood?

How can we get the testers and developers to work harder and move faster?

These questions assume the source of the problem: lazy and incompetent people. But, what if the reason projects are late has something to do with the fact that people are assigned to several projects at the same time or that priorities change so quickly that teams never reach “done” before they are pulled to work on the latest urgent issue? The VP has already narrowed her inquiry and will only arrive at “solutions” that involve firing the “dead wood” and whipping those deemed “live wood.”

Examining our questions is critical, because not only do our perceptions influence the language we use, but also the language we use influences what we perceive.

Starting with a more general set of questions will help reduce perceptual bias and uncover the facts of a problem situation:

What are the visible symptoms?

What other effects can we observe?

Who cares about this issue?

What is the impact on that person/group?

What is the impact on our organization?

What other factors might contribute to the problem situation?

What other events might influence the context?

These questions may lead you closer to the real problem, or at least help you see whether the area you are looking at is the most fruitful for alleviating pain. Based on this, choose where to delve deeper, and get more specific as you explore the details of the situation:

When does the problem occur?

How frequently does it occur?

Is the occurrence regular or irregular?

Does it always happen, or is it an exception?

Under what circumstances does the problem occur?

What are the circumstances under which it doesn’t occur?

What else is happening around the same time? Are those factors connected?

At this point, you may start to feel you have a pretty good idea of what the problem is, so …

Back Up Your Hunches with Data

These questions will give you some clues as to the problem, but data will confirm your hunch (or point you in a different direction). I’m not talking about a measurement program here, but simple, “good enough” data gathered from observation or existing sources. Once you have data, look at it from several vantage points, or you may miss something important.

For example, at a large financial services company, operations analysts collected data on the number of minutes during which each application was unavailable during core business hours. They presented the data at a monthly management meeting using a pie chart. The chart clearly showed which application had the largest portion “outage minutes” for the month. Presenting the data in a pie chart facilitated putting the manager of the offending application on the hot seat at the management meeting. But, it didn’t help much with understanding the problem, or knowing where to look for solutions.

By the time I arrived to help them solve their problems, they had many months of data, and looking at it differently provided useful information.

I used the questions above to guide how I viewed the data. I looked at the total number of outage minutes each month. I look at the trends for each application. I looked at outages in time series. But, the data didn’t answer the question, what is the impact on our organization? I set out to answer that question, and found that not all outages were equal. A day-long outage in a specialized application only affected ten people. A five-minute outage in another system meant everyone in the department—several hundred people—couldn’t access any applications, but it had only happened once. A short outage in an application used by one-third of the department that happened every day accounted for most of the outage minutes over time. Knowing this didn’t solve the problem, but it told them where to focus their fixing.

Quick-fixers may bemoan the amount of time I spent cleaning the data, looking at it this way and that way, asking more questions and gathering more data. It took about a week. Of course it did take a bit more time to repeat this process at the application level. Still, taken in total, the time spent asking questions and gathering data was far less than the time that had passed while management tried to understand the situation with data presented in way that hid useful information—and less then the outage minutes for all affected employees for one month.

Generate At Least Three Candidate Solutions

Now, it’s time to look for possible solutions. Quick-fix thinking conditions us to choose the first idea that’s even remotely plausible. Don’t dismiss your first idea, but don’t stop there either. Develop at least three candidate solutions. You may go back to your first idea, but by developing additional options, you’ll understand the problem better. If you have difficulty thinking of more than one candidate solution, turn your thought process upside down and ask, “How could we make the situation worse?” That paradoxical question almost always jiggles more ideas loose.

As part of developing a solution, identify at least ten things that could go wrong with each candidate solution. Looking at the downsides might send you back to generating more options. Sometimes the best solution isn’t the most elegant; it’s the one with the fewest or least objectionable downsides.

Once you have several options to choose from, choose one and put it motion. Chances are it won’t work out quite as planned—and that’s an opportunity for learning. Observe and gather data, re-adjust, and try again.

Every solution carries the seed to the next problem. That’s a given. When you apply systematic thinking to the problem, it’s less likely that next problem will compound the problem you were trying to fix in the first place.

This article originally appeared on stickyminds.com.

Manager as Work System Designer: 14 Essential Questions

Questions matter.  The questions we ask open one avenue of inquiry, but close others.  If we want to change the way we manage, we need to change our questions.  And so, here are my slides from my talk at Agile 2010:

14 Essential Questions aimed at refocusing management attention on creating work systems that work–creating products the customers want, returns that are acceptable to stakeholders, and providing satisfying work for employees.

Building a Requirements Foundation with Customer Interviews

© 2004-2010 Esther Derby

This article originally appeared in my newsletter, insights.  You can sign up to receive my newsletter using the form on the right.

“Our customer doesn’t know what he wants,” complained Sandy. “I try to get him to talk about the product and tell me what he wants, but it’s like pulling teeth.”

Whether you are building a brand new product or working on evolving an existing product, understanding customer business needs is the foundation of a marketable product. But few of us are experts in interviewing techniques, and few customers talk about their tasks, needs, and context in neat, concise statements about product requirements.

Building the right product starts with asking the right questions. The right questions are those that help us get beneath the surface and understand the customer’s world, work, and concerns.

First Things First

Before you plunk yourself down in front of the customer and start asking questions, articulate your objective. What do you hope to accomplish by interviewing the customer? Do you want to explore broad options, understand a specific business processes, or learn all you can about how a customer uses a particular feature? Articulating a research objective sets the stage for a successful interview. A wandering, unfocused interaction will yield paltry results and frustrate the customer.

Once you’ve defined your objective, brainstorm a list of all the questions you might ask related to the topic. Then organize the questions into themes and arrange them to flow from general to specific and familiar to unfamiliar. The process of preparing questions helps to identify key topic areas to cover. Following a set list of questions isn’t the point: successful interviewers invest time in designing and testing questions—but then use them as a guide, not a script.

As you prepare for an interview, consider different types of questions. Each type will serve a purpose and elicit a different response.

Context-free Questions

Context-free questions are useful in the early stages of a project, when you are beginning to explore. Context-free questions help you decide which avenues to investigate and provide global information about the problem and potential solutions. Because these questions don’t imply any particular context, they are useful for any design project.

Here are some product-related, context-free questions:

  • What problem does this product solve?
  • What problems might this product create?
  • What environment is the product likely to encounter?*

Context-free questions generate a deeper understanding of the product and project.

Meta questions—questions about the questions—are a special sort of context-free question. Meta questions, such as “Do my questions seem relevant?” or “Is there anything else I should be asking?” are likely to surface areas where the customer assumes that you already know.

Open-ended Questions

Open-ended questions invite the customer to expand on the topic.

Use What questions to learn about events and considerations.

  • What happens next?
  • What factors are involved?

How questions ask about the way things happen.

  • How do you use the product to__________?
  • How do people decide which option to select?

Could questions ask the customer to imagine or express a wish.

  • Could you conceive of an example when you’d use the product this way?
  • Could you see a way to use the product to solve this problem?

Closed Questions

A closed question is one that naturally leads to a one-word answer, usually Yes or No. Questions that start with Can, Do, Are, or Is are usually closed questions.

Q: Do you have any problems with the wonder widget?

A: No.

Closed questions are useful for confirming specific information, but are deadly as an interview staple. You want to delve beneath the surface, and closed questions won’t help you with that.

If you do happen to slip into a closed question, follow with a probing question to uncover more information:

Q: Can you recreate the problem?

A: No.

Q: What steps have you taken to try to recreate the problem?

Multiple-choice questions offer a limited set of options and help to establish relative priority:

  • Which would you prefer, A, B, or C?
  • If you had to choose one, which would you choose, X, Y, or Z?

Like closed questions, multiple-choice questions have their place, but shouldn’t make up the bulk of an interview.

Past, Present, Future

Ask questions about past use to understand problems and weaknesses in the product or feature. Use present-time questions to learn about how the customer currently uses the product or how he currently performs his job. And ask questions about the future to learn about trends and anticipate future needs.

Past: When has the product failed to perform as you expected?

Present: How are you using the product now?

Future: How do you see your workflow changing in the next several years?

Tell Me More

Don’t stop at the first answer. Follow an opened-ended question with a probe to gain further insight. A good interviewer will elicit a second, third, and even a fourth response. When you want to learn more, use questions like these:

  • What else?
  • Can you show me?
  • Can you give me an example?
  • How did that happen?
  • What happens next?
  • What’s behind that?
  • Are there any other reasons?

Be sure to probe for more information when you hear emotion or judgment:

“I hate the way the floo feature operates!”

“The product does a poor job.”

Dig deeper to identify unmet needs or weaknesses in the product.

Vague statements like “The product must be easy to use” call for probing to learn what “easy to use” really means to the customer.

Questions That Aren’t Really Questions

Some questions don’t elicit the customer’s opinion, but confirm the interviewer’s opinion instead. Biased questions suggest a “right” answer: “My investigation shows that automating the floo process will provide the biggest savings. What advantages do you see in that?”Leading questions make one response more likely than another. Biased and leading questions tend to feel manipulative, and a customer will tune out if he feels the interviewer is leading or putting words in his mouth. Compound questions make it difficult for the customer to respond at all, as in this example:

“Do you think it’s okay to have a question with two topics—unless there are more than that, or if the topic is complex—and is it better to stick to short questions, except in the case where a longer question is better, or is it a judgment call, except in a special case?”

Ask one question at a time, and give the customer time to answer. Rushing in with another question can give the impression that you don’t really care to hear what the customer has to say.

Ask Why Without Asking “Why?”

Curious children ask “Why?” endlessly. They want to know the answers to everything, even things that are unknowable.

We want to know why customers do the things they do so we can understand the tasks they perform and the business needs behind the tasks. But an endless stream of “Why?” questions can wear on anyone’s patience. Worse, “Why?” can sound blaming, or feel like the interviewer is demanding a cogent explanation for something that’s unknowable.

Avoid putting the customer on the defensive by using How or What questions to dig beneath the surface.

  • How did this come to be?
  • What was the thinking behind that decision?

Or simply ask “Can you help me understand this?”

Putting It All Together

Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then try your interview with an internal customer proxy or subject-matter expert.

Most people find that maintaining rapport and tracking the interview takes all their attention. To help with this, consider working with a partner who can take verbatim notes during the interview. At the end of every interview, perform a short interview retrospective to identify what worked well and what you might want to do differently in future interviews.

Most customers appreciate the opportunity to talk about their work and participate in shaping the products they use. Prepare for your customer interview carefully and hone your interview skills through practice. Invest in learning your customers’ wants and needs so you can deliver the right products.

*Gause and Weinberg, Exploring Requirements: Quality Before Design p. 61-65.

Why Ask Why (When other questions will work so much better)?

Yesterday after work, my spousal unit and I started our usual how-was-your-day ritual. He reported on a project he’s just started and a meeting with a colleague from a previous job. I told him about the article I’m editing and a conversation I had with a colleague. I repeated an interesting statement made by a friend who works at the Department of Health: “The DOH is preparing for biological attacks,” I said.

“Why?” my husband asked.

“Because they believe it’s highly likely we’ll be hit with biologicals in this country,” I responded.

“Why?” my husband demanded.

“I guess they have evidence that convinces them an attack is likely,” I said.

“Why?” my husband barked.

“How the hell would I know!” I snapped.

I don’t have answers for all this biological threat stuff. I was annoyed.

And it’s not just me: I noticed a long time ago that WHY? is one of those questions that sets people off.

If you really want to know why, WHY may not be the question to ask. So how do you ask WHY without asking WHY?

Ask HOW: How does this request fit with our other priorities? How will this directive affect our customers?

Ask WHAT: What was the thinking that went into this proposal? What scenarios were considered in adding this feature?

Ask WHO: Who will benefit from this decision? Who had input into this strategy?

Make a request:: Say more about that… Tell me more…

Admit you are puzzled or curious: I’m puzzled by what you just said… I’m curious about….. I don’t understand….

I learn more about Why the less I use that question.