Category Archives: insights Newsletter

Back issues of my newsletter, insights. You can sign up to receive my newsletter using the form on the right side of the screen.

Self-facilitation Skills for Teams

© 2004-2010 Esther Derby

Self-organizing teams don’t just organize the technical work. They make technical (and non-technical) decisions. Not every situation requires facilitation, but when a team faces an important decision, applying facilitation skills to the problem saves time and yields better results.

Jason was frustrated. The Release 6.0 team had been chewing on a major design decision for two weeks. Jason knew they had to make a decision or they’d run out of time to pursue any option. Jason pulled the five other team members together and told them they weren’t leaving the room without a decision.

Jason started restating the option that Sara had put forward last week.

“I don’t see how that’s going to work,” Josh said.

“Well, I don’t hear you coming up with any better ideas,” said Sara.

“We could go back to the idea Alan suggested last week,” offered Jen.

“Look, we’ve been going back and forth between two ideas, and we’re no closer to a decision now than we were two weeks ago.” Jason sighed and looked around at the rest of the team members seated at the conference table. “You guys got any other ideas?”

Alan and Keith shook their heads. Jen shrugged.

“Fine. We’ll go with Sara’s idea,” Jason said. “We need to move forward or we’ll miss the market window for Release 6.0 completely.”

The Release 6.0 team filed out of the conference room. None of them really liked the idea—not even Sara. But after two weeks of rehashing two competing ideas, the team was tired of talking.

Like the Release 6.0 team, many groups struggle with decisions. Some groups pounce on the first plausible idea only to find out later that they’re down a rat hole. Other groups discuss and argue endlessly and never reach a decision. Still others choose by default or let the loudest voice decide.

In order to make timely decisions that the group can support, teams need to be able to:

  • Generate ideas
  • Narrow the number of options
  • Reach agreement

When I see teams who argue endlessly, can’t decide, or pick an option no one supports, one (or more) of these elements is missing.

There are dozens of techniques and methods that can help teams reach decisions. Here are three that will help with decisions that require broad support and buy-in. I’ve chosen these methods because I’ve seen teams use them successfully without extensive facilitation skills or a great deal of practice.

Generating Ideas

There’s no shortage of good ideas in the world. But sometimes, when people are under pressure, ideas are elusive. Many teams generate one or two alternatives and then stop. That’s not enough. Teams need at least three alternatives to have a real choice. Plus, thinking of three alternatives helps the group explore the problem.
Consider using a combination of brain writing and affinity clustering to generate many ideas in a short period of time.  Pairing these two techniques allows the group to integrate ideas and find common threads. Traditional brainstorming results in a laundry list of ideas and favors the people who are most vocal. This technique includes individual work, so people who need a bit of quiet time to think can participate fully.

Here’s how it works:

Write down the problem the group is trying to solve in the form of a question and post it where everyone can see. This question will help the group focus their thinking. Here are some examples from groups I’ve worked with.

“What are the risks of implementing the foo feature without backward compatibility?”

“What are ways that we can increase throughput in the amortization function?”

“How can we effectively test the risk areas of the product with our current hardware resources?”

“What are practical ways we can improve communication on the team?”

“What are the most important values we hold as a team?”

Allow 5-10 minutes for individuals to write down their own ideas. Ask for at least ten ideas. When the time is up, form groups of three or four to share individual lists. Have the small groups identify the best ideas and write them on sticky notes. There are bound to be duplicates between groups, but don’t worry—duplicates show where there is common ground.

Using a wall or a whiteboard, post the ideas and cluster them into affinity groups. Don’t start with a set of categories; allow the categories to emerge from the ideas. As people move the ideas into affinity groups, they’ll talk about how ideas are related, which are distinct, and how they fit together. These conversations help the team learn about each other’s ideas. When the affinity clusters are settled, name each cluster. The name represents the group’s agreement on the underlying ideas in each cluster.

Brainstorming and clustering will generate 5-7 alternatives in about 30-40 minutes. Sometimes the alternatives warrant further development before the team evaluates them. Organize small working teams to flesh out just enough detail to permit an assessment.

Narrowing Options

When I see a team stuck evaluating alternatives, it’s usually for one of two reasons: 1) People don’t have a common definition of the options under discussion, or 2) the group is talking about all the options at the same time.

To ensure that everyone is working from the same definition, write the key points of each alternative on a flip chart and post it where everyone can see it during the evaluation step. Review each alternative and clarify as needed before starting the evaluation.

Overcoming the second problem takes some discipline: Evaluate each option on its own before comparing options to each other.

You can do this by drawing two lines on a piece of flip-chart paper, creating three columns. List the “plusses” and “minuses” of the options in the first two columns. Make a note of what’s interesting about the option in the third column. Answer all three questions for one alternative before moving on to the next.

Alternative 1
+ Interesting
~~~~~ ~~~~~~ ~~~~~~~~~~~~

After the group has completed this activity for all the options, it’s usually obvious that some of the ideas are unsuitable.

Agreeing on an Option

An individual making a decision may agonize over it, but when more than one person is involved, it can turn into an argument. Teams need a way to test their agreement, discuss concerns, and arrive at a decision that all can support.

The Romans indicated their will in the gladiator’s arena with a thumbs up or a thumbs down. A modern modification of Roman voting helps teams arrive at a decision.

Thumbs up = “I support this proposal.”

Thumbs sideways = “I’ll go along with the will of the group.”

Thumbs down = “I do not support this proposal and wish to speak.”

If all thumbs are down, eliminate the option. On a mixed vote, listen to what the thumbs-down people have to say, and re-check agreement. Be cautious about choosing an option if the majority are thumbs sideways: This option has only lukewarm support.

This technique generates consensus. Consensus doesn’t necessarily mean complete unanimity. Consensus means that everyone must be willing to support the idea, even if it’s not his personal first choice.

Sooner or later, you’ll have a situation where one person withholds support for any option. Manage this situation before it happens. At the start of the consensus process, set a time limit:

“We’ll work really hard to reach consensus until the end of this meeting. If we don’t have agreement by that time, we will

turn the decision over to _________, or

take a vote, or

__________ (a technical expert, coach, manager) will decide.”

Most people don’t hold out to be obstinate; they are responding to a deeply held value or belief. Often the lone holdout will move on, but not at the cost of relinquishing an important belief. Respect the belief, use your fallback decision-making method, and move forward. However, when a group seldom reaches consensus, but instead relies on voting or deferring to authority, it’s a sign there are deeper issues at play.

Putting the Techniques to Work

When the Release 6.0 team held their project retrospective, the team identified decision-making as an area they wanted to improve. Of course, not every decision requires a formal process; but when important decisions come along, the team saves time and energy by applying techniques like the ones I’ve described.
If you notice your teams are stuck in one (or more) of the three decision areas, point out what you’re observing. Ask the team if they are willing to try something different to help reach a decision. Then hand them a copy of this article and try the appropriate technique. Teams who learn to self-facilitate spend less time churning and more time on the business of the business.

Adapted from the Technology of Participation methods, The Institute of Cultural Affairs

Hiring for a Collaborative Team

If you’re a hiring manager, you know that a typical hiring process emphasizes technical skills, functional skills, and industry knowledge. Interpersonal skills are near the bottom of the list, if they make the list at all. However, if you’re hiring for an agile team, or any other team that must collaborate to succeed, put interpersonal skills near the top of the list.
Of course, that doesn’t mean you should ignore technical and functional skills or take a nice person you meet in the street and train them from the ground up. Look for a near fit on technical skills–you can train on that. Focus your attention on skills and characteristics that are a prerequisite for collaborative working relationships. A desire and ability to work collaboratively, self-management and a proven ability to navigate conflict, and self-awareness are key traits to look for. It’s not that people can’t learn interpersonal skills, but these skills are much harder to impart and often require a degree of intrapersonal change, and not everyone is willing to do that for a job.

Screen Out the Lone Wolves

Self-organizing cross-functional teams, shared code ownership, and team goals aren’t for everyone. It may seem obvious, but this is an oft-overlooked fundamental. People who crave star status and individual achievement aren’t bad people; they are a poor fit for a self-organizing team. Even when the candidate has fabulous technical skills and experience, move on. The lone wolf won’t be happy on a highly interdependent team, and you won’t be happy about your hiring decision either.

Weed Out the Not-So-Nice

This is a simple test that will quickly eliminate the not-so-nice. Have the unit admin make the initial screening call to verify employment dates, contact information, and other basics. Pay close attention to how the candidate responds. Is the candidate polite? If a candidate can’t be pleasant to the admin, it’s likely they won’t be pleasant to others either.
This little test may seem simple-minded; and while it is simple, it gives an indication about self-management and empathy. Watch mainly for big red flags: A person who isn’t willing to be pleasant may not like working with people enough to function effectively (and happily) in a highly interdependent, collaborative environment.

Involve the Team in the Hiring Process

I like team-based hiring in general, and for an agile team it’s essential. Having the manager make a hiring decision in isolation belies the very nature of self-organizing teams.
There are lots of ways to do team-based hiring, and some to avoid. Skip panel interviews where the candidate is interviewed by several people at the same time. Panel interviews save time for the staff, but can be intimidating for the candidate. Rather, have a subset of the team spend 45-50 minutes one-on-one with the candidate.
Draw up the question list in advance, and then divide the questions between the interviewers–and don’t make the candidate answer the same questions several times! If you’re interviewing more than one candidate, make sure to ask every candidate the same set of questions. You can add additional questions to follow interesting threads, but be sure you have a common set of questions for all candidates so you can compare them apples-to-apples.

Use Past Performance as an Indicator of Future Performance

Behavioral or experience-based questions are open-ended questions that ask the candidate to describe how he or she has responded and acted in the past. Explore with a combination of requests for scenarios and questions:

  • Tell me about a situation where you disagreed with a co-worker.
  • How did you handle the disagreement?
  • How long did you wait to broach the topic?
  • Tell me about three approaches you use to deal with conflict at work.

Look for candidates who can disagree–a certain level of conflict is healthy–without being disagreeable. What you don’t want is a team where people disagree all the time and can’t work together. Use behavioral questions to explore flexibility, ability to resolve conflict, helpfulness, and comfort with having work open to team review.

Watch the Candidate in Action

Auditions are a great way to see how a person works. If your team is pair programming, ask the candidate to sign a non-disclosure agreement, and then have her pair program briefly with several team members. How does she respond? Keep in mind that this is a very stressful position for many people–looking for a job is stressful enough, and you’re also asking her to jump into unfamiliar code. How does she handle that? Is she okay with being a learner? Is she comfortable offering feedback or expertise?
When you’re serious about a candidate, consider inviting the candidate to have lunch with the entire team. A group lunch serves two purposes. It allows team members who weren’t directly involved in the interviews a chance to interact with the candidate. Don’t be too worried if the candidate doesn’t act like a social butterfly. But do watch to see if he talks to the people on either side of him and shows interest in the conversation.

Make the Hiring Decision as a Team

After the interviews, auditions, and other data gathering, assemble the interview team to share their findings. I like to use a “thumb vote” to test the level of agreement on candidates. Thumb up indicates support for the candidate, thumb sideways means “I’ll go along with the group,” and thumb down means “I object and wish to speak.”
If everyone is thumb up or thumb down, the decision is easy. If a majority of the group is thumb sideways, keep looking. This should tell you that if everyone is just lukewarm about the candidate, he probably won’t be a good fit.
Override the team’s assessment at your peril!

Use Psychometric Tests Responsibly

One manager whose company had adopted Extreme Programming (XP) stated that his company was now hiring for a particular Myers Briggs Type Indicator (MBTI). I predict that this company will have problems!
Healthy teams have diversity of thought processes, preferences, and psychological traits. A team of people who all think alike or like to do things the same way will run into trouble. Remember that people of all temperaments can be successful. It’s not appropriate to select or exclude candidates based on MBTI type.
Psychometric tests can be a useful piece of the puzzle. But basing a hiring decision on a psychological profile or even using it as the determining factor is not only inappropriate, it’s illegal.

Be Prepared to Answer Candidate Concerns

Be prepared to answer questions about career path and development. Self-organizing teams blur the lines between job functions and flatten job grades. Most companies have some form of job descriptions including job levels, career paths, and salary grades. This is what most candidates are accustomed to, and they may have questions on how this will work on a cross-functional team.
I recommend having as few salary bands as feasible on a cross-functional team, and standardizing compensation for each band.

Putting It All Together

Hiring for a cross-functional, collaborative team requires a different emphasis from traditional hiring practices. In many cases, languages, tools, and functional skills are much easier to train in than interpersonal skills. Shift your focus to finding people who are able and eager to work in a cross-functional, collaborative environment and be willing to accept a near fit on technology and functional skills. Follow these steps and you’ll increase your probability of building an extremely productive collaborative team.

A Manager’s Guide to Getting Feedback

© 2006-2010 Esther Derby

Author’s Note: In general, anonymous feedback in the workplace doesn’t work. It destroys trust, and doesn’t give the opportunity for followup, clarification, or problem-solving.

But there is an exception.  Sometimes the only way to get feedback up the chain–from direct reports to managers–is to use a process that anonymizes individual responses, and allows for open discussion of the results.

Once a manager establishes that he is open to feedback, will act on feedback, and does not retaliate, people may be more willing to give direct feedback. As long as managers have power to rate, promote, fire, and influence careers, it’s going to take extra effort to receive clear and honest feedback from people in a position of less power.


Like everyone else, managers need feedback to know how they are doing and where to adjust their actions. Managers may receive feedback from their managers; that’s necessary, but not sufficient. Managers also need feedback from the people they manage.

For information on how you are interacting with and supporting the people who report to you, go to the source.

Unfortunately, it’s not always easy to obtain feedback from direct reports. When I ask knowledge workers why they don’t give their managers feedback, here’s a sample of what I hear:

“If I criticize him, I’ll see the effects when it comes to annual salary reviews.”

“Feedback is a one-way street with my manager.”

“It’s not my job. He should know now he’s doing. He’s the manager, after all.”

Beliefs about hierarchy can belie the truth that all relationships are co-created—even relationships between managers and direct reports. So as a manager, you may have to work extra hard to receive clear, honest, and direct feedback about how the people who report to you perceive you and how you are affecting their ability to accomplish the goals of the organization.

Even if you have built a foundation of trust, you’ll have this obstacle to overcome when you seek feedback from your staff. If the trust in your group is low, rebuilding trust is the first priority. Asking for feedback can be part of that—if it’s handled carefully. I’ll say more about this later.

Before you start the process of obtaining feedback, ask yourself if you are really willing to hear the feedback and act on it. Going through this exercise and not making any changes will cause cynicism. Gathering data and then punishing people will cut off your source of information. Acting hurt will telegraph to people that you can dish out feedback, but you can’t take it. You may hear information that is surprising or unsettling. You may learn that other people don’t see you as you see yourself, or that others’ perceptions don’t match your intentions.

If you can affirm that you are willing to hear uncomfortable information and are willing to take at least some action, then proceed. If not, take some time to reflect on why, and consider using a coach or taking a management style assessment to begin learning about how others might perceive you. Once you’ve decided to go ahead, set aside at least two team meetings for the feedback process. Overall, the process takes about a week.

Meeting #1: Identify the Characteristics and Behaviors That Matter to the People in Your Group

State the purpose of the meeting by saying something along these lines: “I want to do my best to support you by creating an environment where you can do the work we need to do. To do that, I need information about what you feel is most important for me to do, and how my actions are supporting you in those areas.” Provide an overview of the process and explain how you’ll use the data. Ask the group to individually brainstorm the qualities and behaviors most important to them. Use stickies to do an affinity sort. Have the group attach a descriptive name to each affinity group. Most groups end up with five to seven groupings.

After the meeting, create a short survey to collect data. The survey might look something like this.

Characteristic & Assessment



1=Behavior in this area is getting in our way

3=Could do more/differently here

5=Keep doing what you are doing

Note that the ratings don’t express a judgment about the person, such as “poor” or “outstanding.” Use wording that focuses on behaviors, not an assessment of your goodness as a person. Distribute the survey, and create a way for people to return it anonymously. Ask that the surveys are returned in time for you (or someone else in your group) to collate the data.

Meeting #2: Discuss the Data

The numbers don’t have meaning in and of themselves, and they won’t tell you what to consider changing, what to stop doing, or what to continue. But they will help start a discussion.

Start the meeting by stating the purpose: to have a frank discussion about what people need from you. Vague generalities won’t help. You need specific behavioral examples of what you are doing that has a positive impact on the group and what you are doing that gets in their way. For areas where the team would like to see something different, engage in problem-solving and identify several possible options.

Here’s what one manager’s data looked like:


Ask for specific concrete behavior examples in each category. One manager I know responded to a low number for “availability” without asking for more specific information.  She instituted office hours and handed out her home phone number. But that wasn’t what her staff wanted. Their assessment reflected the fact that she took phone calls and answered email during meetings (which she continued to do during her “office hours”). You need to hear from the people in your group what you are doing or not doing that leads to their assessment. For areas where your staff sees you at the low end of the scale, ask “What one or two things can I change—either start doing or stop doing—that will improve my effectiveness?”

Chances are that some things you do as a manager will please some and displease others. In some cases, you can have it both ways. For example, if one person in your group feels you check the status  day-to-day work too often and another appreciates your interest and attention, you can adjust your style for each person (assuming that the person who doesn’t like day-to-day attention can work independently). In other cases, you’ll have to abide by the old adage “You can please some of the people some of the time, but you can’t please all of the people all of the time.”

If your team tells you that something you feel is critical to your job is driving them crazy, explain what is behind your behavior, i.e., the management goal you are trying to achieve, and ask them to work with you to find other ways to accomplish that goal. One manager was annoying his team by inserting himself into technical discussions and decisions that the group felt they should be making. He explained that he was concerned that they didn’t have all the facts and might make a decision that would work short-term but would be detrimental over the long term. Once the team understood his concern, they were able to move into problem-solving. The manager and the technical staff agreed that the manager would provide context, set boundaries, and be clear on whether he was looking for a recommendation or a final decision.

Be prepared for surprises. You may learn that you have habits that get in your way. One manager learned that her staff inferred that she didn’t like to hear bad news because she furrowed her brow and scrunched up her face when staff members informed her of problems. They believed her facial expression meant she was mad at them. This manager believed she’d never be able to completely control her expression. But once she was aware of the effect her facial expression had, when she caught herself scrunching up her face, she explained that she wasn’t angry, she was concentrating.

Rebuilding Trust

If the trust level in your group is too low for this method, consider having a neutral party  facilitate the process (perhaps someone from the HR department). A neutral party can help ensure that people feel free to state their perceptions, and help you absorb the feedback and choose how to act on it. Asking for feedback can be the first step in repairing relationships, if you are prepared to take a hard look at yourself and act on what you learn.

Manage Expectations

Whether you are starting from a position of high trust or low trust, your group won’t expect you to be a completely changed person after the discussion session. Just as you wouldn’t expect your direct reports to make 15 behavioral changes in the course of the week, your staff won’t expect that of you either. You may ask them, “If I can change just one thing in the next month, which is most important to you?” Your team will expect you to listen carefully to their feedback, consider their perceptions, and make at least some adjustments.

Achieving Agility: Means to an End, or End in Itself

(c) 2010 Esther Derby

I recently spoke to a senior manager who wanted to know how “agile” his company was compared to other companies. When I asked what he’d gain from that information, he responded that then he’d know what practices the development teams needed to implement next. I’m not the only one receiving calls like this. Companies promising agility assessments are sprouting like dandelions.

How agile you are doesn’t matter. Whether you are 50 per cent agile, 90 per cent agile or agile through and through (what ever that means), doesn’t matter.

What does matter is that your company is satisfying its customers, stakeholders, and employees.


Understanding your market and  customers (and potential customers) is the first step in building products that will sell. You need to know enough about both to create a product road map that guides product investments and lays out which features to deliver when.

If you aren’t sure what your customers think about your company’s current products, or don’t have a clear plan on how to create or evolve products, gather information. Investigating customer support requests, field studies and interviews can reveal how your customers currently use your product, which features need improvement, and give clues about unmet needs (which are candidates for future features and products).


Stakeholders include owners or shareholders, the board of directors, partners, suppliers, regulators and the communities in which you do business. Shareholders may focus on short-term profits; a board of directors or owner may have a interest in fiduciary responsibility and longevity of the company.

If your company isn’t delivering the financial returns necessary to remain in business, it’s time re-examine the factors that influence revenue. Most managers are familiar with traditional methods of assessing profitability. You may learn by looking at two other factors:

  • Value Creation, the process of turning a product idea into something you can sell
  • Missed Potential Profit, how much money and effort is dedicated to self-inflicted coordination overhead, rework, downtime, or support for difficult-to-use features.


In order to build great products and carry out the work of the organization, you need to attract and retain people who have the desire and ability to do the work. Great people want meaningful work, fair compensation, and work systems that support them to do their best. Great people flee workplaces that rob them of motivation and pride in work, throw up barriers or treat them with distrust.

Agile methods can help satisfy all three of these groups.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce completed slices of feature can allow the company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices to add up to a marketable set, you can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

These are all things that matter in business.

Before you assess your “agility,” assess how well you are satisfying your customers, stakeholders and employees. If the data shows that your company needs better results to survive and thrive, prioritize and address first things first.

If you don’t know what customers think of your product or don’t know what product to build, start by obtaining feedback. Bring development teams and the folks who define products close together, so they can collaborate. If you are building the right products with the necessary quality, but not with the desired speed, investigate how cross-functional teams working in iteratively in time boxes can help and start there. If technical debt is costing money and slowing deployment, consider starting with disciplined agile engineering practices. If your employees feel unvalued and disengaged, examine your existing structures, policies and procedures. Dropping agile methods on top of procedures that communicate distrust and foster demotivation won’t bring the results you want.

Agile methods can contribute to improving results. Comparing your company’s agile adoption and imitating others may bring the results you want–if you are lucky and your context is nearly identical to the comparison companies.

Charting a course based on a clear understanding your current situation is most likely to succeed. Data that shows how your company is performing will garner more support for making changes than any pep talk, maturity rating, or agility assessment.

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.

Seven Lessons from a Top-Down Change

© 2007-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.

You’d think that since I’m president of a one-person company, I could change anything in my office in a snap. But a recent incident reminded me that change is always a process.

My dog, Pudge, comes to the office with me every day. Until recently, she spent her day on a blanket by the door where she chewed her on her bone between naps. When she wasn’t chewing or napping, she tugged the blanket around the floor. But this day, I’d stepped on the blanket and slipped one too many times—and frankly, the blanket was looking ratty!

So I decided to replace it.

Lesson 1:  A change usually represents someone’s best idea on how to solve a problem or respond to an external event.

I decided that a cushy new dog bed would solve several problems at once. It would stay in one place, look better, and provide a more comfortable nest for Pudge.

That’s usually the case with a top-down change. Someone is offering the best solution they know at the time to improve the situation. No matter what it looks like from below, people who initiate change hope and intend to improve the situation. But unless managers follow the rest of these lessons, it’s unlikely that the people who are asked to change will appreciate this truth.

Lesson 2: One person’s carefully considered idea is another person’s incomprehensible surprise.

When the new dog bed arrived, Pudge was curious about the box. She was even curious about its contents. But when I replaced her old blanket with the new bed, her curiosity ended. She picked up her bone and headed into the hall for a good chew. Then, one by one, she moved the rest of her toys out into the hall.

The people charged with formulating new strategies spend time thinking through the issues, economics, benefits, and risks. By the time they decide to implement a change, they have a thorough understanding. They’ve worked through questions, risks, and their own objections. And then they forget that other people have not had as much time to mull over the issues and examine the pros, cons, and imperatives.

It is very important for people to understand the thinking behind a change. They need information and time to digest it.

Lesson 3: The people seeking a change may value different things than the people expected to change.

When I bought a new dog bed, I was looking for neatness, containment, and easy washing. Although Pudge can’t tell me, I suspect that she valued the ability to tug the blanket around and actually enjoy its odor (she’s a dog, after all!).

When a mid-western company was purchased by a larger firm based in New York, headquarters assumed that the acquired company would appreciate new opportunities for advancement and travel. They were sure the mid-westerners would find their direct approach a breath of fresh air. But the mid-westerners valued balancing work and family life. The mid-westerners believed that being considerate was part of maintaining long-term working relationships. To them, the New Yorkers’ directness seemed disrespectful and rude.

People who ask others to change may not understand what value they are asking people to give up. And in fact, they may not appreciate or even notice what’s valuable to the people they expect to change.

Lesson 4: Change always involves loss.

I had every intention of providing something wonderful for Pudge when I bought her a new dog bed. But she didn’t see it that way. She lost her familiar blanket.

Even when there is long-term gain, the people affected by change will experience loss. They may lose established routines, patterns, and relationships. They may lose prestige, their sense of competence, or belonging. When you plan a change, think about who is benefiting and who is losing as a result of the change, and then be prepared to empathize with people’s sense of loss.

Lesson 5: Choice or coercion depends on where you sit.

I chose to change my dog’s blanket for a new dog bed. She didn’t have a choice—she wasn’t even consulted! “She’s a dog!” you may say. That’s true. Too often, though, intelligent adults are treated the same way when it comes to organizational changes.

People don’t resist change. Change that’s presented as “Follow, or be fired!” feels like coercion. And most people resist coercion.

Along with providing information, engage the affected people in designing the change.  Engagement increases support. People will still feel a sense of loss, yet they are less likely to feel like victims when they have information and some input in shaping the change. And the people closest to the work are likely to have ideas that will improve the implementation—if you bother to ask them.

Lesson 6: How people respond to a change is a rich source of information.

When people don’t do what we want them to do, change management professionals call it “resistance.” Resistance is something to overcome. If we look at it another way, how people respond to change is a source of information to refine ideas and shape implementation.

When people don’t do as we want or expect, it may be because:

  • they don’t know how to do what they’re being asked to do.
  • they don’t feel they have time to learn the new way and still meet existing goals and targets.
  • they believe the existing way is better.
  • they don’t think the new way will work.
  • they believe the new way will cause harm—to customers, the company, the employees, etc.
  • they don’t like or don’t respect the person requesting the change.
  • the new suggestion is counter-intuitive given people’s existing models of how the world works.
  • the new way runs counter to existing reward structures or other organizational systems.

Once you learn about the reasons behind “resistance,” use that information to adapt the change, provide needed training, or review potential roadblocks. Acting on the source of the response increases the chances the change will succeed.

Lesson 7: People change to retain something they value.

The second day after I introduced the new bed, Pudge followed me to the office but stopped at the door. I enticed her onto the new bed with a biscuit. She stepped gingerly onto the bed, picked up the biscuit and left. We repeated this routine for three days. Finally, after four days spent alone in the hall, she came into the office—not because she liked the bed, but because she wanted to be close to her human.

That’s true for people, too. Most people don’t change because there’s a good argument for a change, or even when there’s overwhelming data supporting the reasons to change (witness the number of people who still smoke cigarettes). People change to retain something they value. It may be an association with people or the organization. It may be a steady paycheck. Take time to find out what people value and how the change relates to what they value.

So what does my experience with Pudge and her new dog bed teach us about change? Lack of enthusiasm for a change proposal may not mean it’s a bad idea. But it’s a good indication that there’s work left to be done in introducing the idea, understanding what people value, and incorporating their ideas.