Tag Archives: communication

/Estimating/ is often helpful. /Estimates/ are often not.

Recently, I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

/Estimating/ is often helpful.

Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..

Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions.  Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.

Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.

When the group knows enough about the “what” to think about the “how,” they can analyze implementation.  Working out implementation details reveals more assumptions, and generates more questions.

Sometimes estimating reveals you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as X.

But sometimes, estimators realize that they don’t know enough to think about size or effort in any meaningful way.

This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.

/Estimates/ are often not helpful.

People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method.  Meeting needs fades in priority.

People construe estimates  as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.

People construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (or compensation for bosses who are known to cut estimates to fit wishes. See below).

Inappropriate precision in estimates implies that people know more than they do.  When expectations and reality meet, people may feel disappointed. More likely, they feel  deceived. Trust and openness suffer.

People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.”  Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.

So please, estimate. But don’t get caught up in estimates.

Fill in the blanks

I’ve been noticing what’s missing lately. In some ways, its harder to see what’s not there than what is. But there’s lost of useful information in what isn’t said, as well as what is.

For example:

A manager, talking about one of the people who reported to him said:

“He’s difficult to manage.”

What’s missing?

“He’s difficult (for me) to manage.”

“(When he does X), he’s difficult (for me) to manage.”

“(When he does X,) he’s difficult (for me) to manage (because I don’t understand his actions).”

“(When he does X), he’s difficult (for me) to manage (because I don’t understand his actions and I don’t know what to do).”

There may be another follow-on sentence, that hints at the crux of the matter.  That sentence might be…

And I’m worried that if I can’t bring him around, I’ll miss my goals and my boss will think I’m not competent.

And I have judgements about that behavior because I was criticized for that when I was in school.

And I feel threatened.

And I feel I have to defend my ideas.

I know what I’m asking doesn’t make sense, but my boss told me to do it.

It may have been more comfortable for the manager to say the first sentence, as he did.  He may even believe it.

As long as the manager deletes parts of the sentence, it’s easy for him to see the other person as the problem. As long as the problem resides entirely with the other person, there’s not much he can do to improve the situation (other than fire the “difficult to manage” person).  But the deletions contain important information that could help him improve the situation.

What examples would you add?

The Agile Blindside

(this article originally appeared on gantthead.com)

Agile project management depends on transparency and feedback. Visibility into the product and process is built in with iteration reviews and retrospectives. Task walls and Kanban boards make progress (or lack of it) and bottlenecks obvious. Stand-up meetings seek to raise impediments to management attention. But are managers ready to hear about these problems?

If organizations want to realize the benefits of agile methods, managers need to act on the problems that bubble up from teams, deal with unexpected events on projects and proactively find and fix problems that derail projects. Unfortunately, many managers behave in ways that communicate they aren’t interested in solving problems–and ensure they won’t learn of problems until it’s too late.

“Don’t bring me problems, bring me solutions.”

I suspect that managers who repeat this sentence believe it will encourage people and teams to solve problems on their own. But people don’t approach their managers with problems they know how to fix and can solve (or believe they can solve). The problems they raise are ones they don’t know how to solve, don’t have the organizational influence to solve or need some help to solve.What really happens when managers talk this way? Team members struggle in isolation or ignore problems, hoping they will go away. Managers who tell people not to bring them problems ensure that they won’t hear about small problems that are part of a larger pattern.

“Failure is not an option!”

Managers who rely on this exhortation ensure they won’t hear about risks and issues. The phrase sends the message that success is a matter of character and will rather than the result of planning, observation, re-planning and course correction when something unexpected occurs.

Will and character are assets in any endeavor; however, they are not sufficient for success. Success requires removing impediments and proactively finding and ameliorating problem situations. Failure may not be an option that managers like, but it is always a possibility; ignoring that fact forces problems underground and makes failure more likely.

“The thought that disaster is impossible often leads to an unthinkable disaster.”- Gerald M. Weinberg

“Get with the program or get off the bus!”

When managers give the impression that their minds are already made up, subordinates are less likely to bring up weaknesses, problems or alternatives. People fear that their concerns won’t be heard. Worse, they fear (often with reason) being labeled as naysayers or whiners. Discourage people from shining the light on problems and they’ll stop.

But managers don’t need to be obvious in their discouragement; more subtle actions can also plug the pipe.

Interrupting

Interrupting a person who brings unwelcome news makes it harder for that person, who is already facing a difficult conversation. People interrupt for many reasons–excitement, the desire for more details, etc. But to the person being interrupted, a stream of interruptions can feel like an interrogation. Interrupting implies impatience–and that anything the interrupter has to say is more important than what the other person was about to say.

Ignoring Intuition

A couple of years ago, a friend felt uneasy about an action his manager was taking. He couldn’t quite put his finger on why he felt concerned, but his feeling strong enough that he went to his manager–who dismissed his intuition, telling him, “Come back when you have some facts and we can have a logical argument.” But the situation outpaced data gathering and blew up.

Asking for excessive proof and demanding data ensures that a whole class of complex and systemic problems won’t come to attention early.

Non-verbal cues

I coached a manager who furrowed her brow and tapped her pencil when people told her about problems. She was thinking hard. They thought she was irritated with them for brining bad news.When there’s a problem on a project, the earlier you know about it, the more options you have to mitigate the impact, make a course correction or re-set expectations. But you won’t hear about problems if you plug the information pipeline.

“The problem isn’t the problem. Coping with the problem is the problem.” – Virginia Satir

As much as we might wish there were no problems on projects, that’s not the way the world works. Problems are a normal part of life. Managers need to know about problems so they can see patterns, find options and steer projects.
Here are three things you can do to make sure your information pipeline flows:

Tell people you want to hear about problems. Sounds simple–and it is. Assure people that you understand that nothing goes exactly as planned and you don’t expect perfection. You may not want every problem dropped at your doorstep to solve–but if you act as if having problems is a problem, you won’t learn about impediments and issues when they are small.

Learn how to listen. At a recent talk, a participant asserted that people from [fill a non-western country here] don’t know how to say “no.’” This is not true. What is true is that many Americans don’t hear it when people from different cultures say “no.” The same is true for hearing about problems. If you want to build an early warning information system, you need to learn how to listen. That means refraining from interruptions. It also means listening for less obvious cues and what isn’t being said. When there’s a long hesitation preceding a positive statement, there’s more to learn. If you don’t hear any mention of risks or issues, delve deeper.

Teach people how to speak up. I don’t want to clog the information pipeline by implying that I only want to hear about problems that have ready solutions:

The most important and dangerous problems don’t have an obvious fix.Here’s a framework that has worked for me. It provides useful information and an agreed-upon format that reduces the psychological barriers to raising issues:

“Here’s my hunch…” This makes it explicit that I don’t require excessive proof.
“Here’s why you need to know about it…” This signals that I recognize that I don’t know everything.
“Here’s my data…” If there is data, it’s good to know. And I’ve heard about intuition being born out enough that “I have a bad feeling about this” is good enough for me.
“Here’s what I’ve considered or tried…” I do want people to think about the issue and I want to hear about their thinking. Problem solving is improved by multiple points of view.

Standard agile practices such as visible charts, frequent demonstration of working product, and retrospectives are all ways to make both progress and problems visible. But if people don’t feel safe to bring up issues, you won’t hear about them until it’s too late. If you take the actions outlined here, it will be easier for people to bring up problems to you. Problems are part of life–and projects. Pretending otherwise creates a culture for them to hide and fester.

Best at argument != Best ideas

I was talking to my friend Penny the other day about a team she coaches.

There’s a really smart guy on the team. I’ll call him Bob. Most of the time Bob is an asset to the team. But when the team needs to decide on a technical solution under time pressure, he’s not.

“But Bob is a smart guy,” you may say. “How is it he’s not an asset? Won’t he have the best ideas?”

When it comes time to solve a technical problem, Bob is always first to offer his idea. Then, Bob dominates the conversation with a constant stream of words, leaving no opening for another to insert facts, ideas, points of view. When someone does find a voice and interrupts the torrent, Bob cuts him off, declaring “I’m not finished.”

When Bob does finish, and another team members asks a question, Bob implies that the other person doesn’t get it, and might be too stupid to see the brilliance of Bob’s idea.

When another team member proposes a different idea, Bob shreds it. He points out the flaws in the other person’s idea, while pointing to the strengths of his own idea.

When he does let others speak, it’s pretty clear that he isn’t listening to learn. Bob is figuring out how to score his next point.

I don’t believe Bob has bad intentions. I believe he wants to be helpful, and believes he is. Bob is helping the team in many ways, but he’s also hurting the team. Here’s how:

1. The team don’t have enough ideas. Due to Bob’s style, there is seldom more than one idea (Bob’s) that receives serious consideration. That’s not enough. Even if Bob is smart, so are the other people on the team. But Bob is the most extraverted and the best at argument and debate. That’s not the same as having the best ideas.

2. Over time, Bob’s style will wear down the other team members. It’s really not terribly satisfying to be browbeaten, or have all your ideas shot down. At some point, other people will stop offering ideas, and acquiesce rather than endure another argument with Bob.

3. As long as Bob’s ideas prevail, others don’t have a chance to develop their ideas.They are deprived the opportunity to learn, think about problems and risks, and increase their capability. Over the long run, that’s bad for the individuals involved, bad for the team, bad for the organization.

Penny has given Bob feedback on the effects of his behavior. It’s made some impact, but when there’s pressure to come up with a solution, Bob–as most people do–falls back on his default behavior. Chances are, Penny won’t get Bob to change that. Bob’s behavior is driven by his natural tendencies, and years of cultural exposure that taught him that competition and argument are the way to find the best ideas.

However, Penny can change the process so that the team has sufficient ideas to consider, and that credible ideas receive due consideration.

Here’s how:

Separate generating ideas, explaining ideas, exploring ideas, and evaluating ideas. As it is now, all of these are mashed together (and done mostly by Bob).

Equalize participation. From what Penny has told me, I suspect Bob is a strong extravert and the other team members are introverts. That means that Bob is very comfortable thinking out loud, and the other team members need a bit of time to organize their thoughts. Before they have time to do that, Bob is on a roll. One way make room for more participation is to start the process with a few minutes of silent brainstorming. Then, ask each person explain (orally or through sketching) the essentials of his or her best idea.

Apply the Rule of Three. If you don’t have at least three ideas, you don’t have enough ideas, and you probably don’t understand the problem. You may end up with deciding the first idea that came up is the best one…but you may not, or you may refine the first idea based on further discussion.

Test for agreement. Some teams get carried away with voting. But when a decisions are routinely highjacked by one individual, it can help to test for agreement using a gradient of agreement or fist of five.

Establish a small set of tests for technical solutions. In this team, some of the tests that make sense might be:

The solution …

  • is the simplest thing that can work.
  • doesn’t add to technical debt.
  • can be implemented in the timeframe required by service level agreements.

Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas are fully considered. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else.  If the team had a process to consider and refine ideas, that might not happen as much.

It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.

But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.

There’s I(ntelligence)Q, and then there’s I(nfluence)Q

People who work in software are smart people who take pride in their abilities to understand complex information and solve difficult problems. But much of the work isn’t only about smarts. Creating most software requires the help and cooperation of other people. Telling, convincing, and winning arguments won’t work to bring people along, change their minds, or help them help you. That requires influence.

To some of people, influence is a dirty word. The word may bring up images of sleazy organizational politics or strong-arm tactics along the lines of “I made him an offer he couldn’t refuse.”

But influence doesn’t have to be slimy or manipulative. Simply put, influences is the capability to affect the opinions and actions of others. You don’t have to be in charge to have influence; the elements of influence are available no matter what your role.

Let’s eavesdrop on two conversations to see what we can learn about influence.

The Alpha team is working towards their next release. One of the major goals is to make it easier for customers to migrate their existing data when they install a new version of the software.

Brandon knows there are two stories in the backlog that will require table updates: one story is scheduled for this release and one for the next. He has figured out how to design the table to accommodate both requirements with one table change, which means customers will need to do only one database conversion, instead of two. Plus, they can roll out the improvement with this release rather than the following one.

Brandon wants to convince Cindy–who is working on the story that’s part of the current release– that his idea is the right approach. Brandon stops by her desk to chat about his idea.

We’ll pick up the conversation after Brandon’s sketched out his candidate design.

Cindy: You can’t do the tables that way, Brandon.

Brandon: Let me tell you why I this this will work, and be easier for the customer…

Cindy (cutting Brandon off): We’ll have to write lots more code with this table setup. Did you think of that?

Brandon: It might take another access call, Cindy, but it makes it much easier for the customer to install the new release.

Cindy: We’re going to have to write ten percent more code, at least. And then we’ll have to test it all. It’s a bad idea.

Brandon: I don’t agree, Cindy. It’s not going to take that much more code. And there are several advantages to this approach.

Cindy: Do you really want us to blow our iteration goal? Is that what you want?

Brandon (trailing off): No, of course, I don’t want us to miss our commitments…

Brandon felt like he was being backed into a corner and it felt like Cindy was picking a fight.

After a couple more brow beatings from Cindy, Brandon gave up.  Arguing with Cindy wasn’t worth it.

Cindy, however, felt a little rush of pride. She believed that her powers of argument had moved Brandon to see things her way.

Cindy is exhibiting one sort of influence, perhaps a sort that gives influence a bad name: browbeating and emotional manipulation.

Brandon is missing the influence boat, too. He didn’t ask Cindy what she needed or what her concerns were to see if they had some common ground.

Brandon made two other mistakes:

  • He responded to Cindy’s objection by explaining his position rather than exploring her objection.
  • He responded to her second objection by arguing the facts.

In another part of the country, Jason and Tom are working on a virtually identical project:

Jason: Tom, the customers are really screaming about having to convert their databases with every release. I think I’ve found a way to eliminate a conversion for the next release–three months earlier we thought we could. I think they’ll love it. Is this a good time to walk through my idea?

Tom: Sure, show me what you’ve got.

Jason walked through his approach.

Tom: Well, the way you have it set up, we’ll have to write another call every time we access this table.

Jason: Ah. That’s true. When I was fleshing this out, I saw there would be an extra call. Can you tell me more about the impact you think that will have?

Tom: Well, I’m worried about writing and testing those calls.

Jason: Can you tell me more about that? You’re not concerned about performance?

Tom: Performance shouldn’t be a problem (but we’d need to test that). I’m worried about Teddy. Teddy is sweating the release plan. He just added a a big new feature, and he’s worried about upholding his commitments to one of our key customers.

Jason: Oh, so your concern is about what we can fit into the release.

Tom: Yep, I don’t see what we can take off the plate to fit this onto the plate.

Jason: I see. Well, what if we talk to Teddy about the tradeoffs and see if we can shift something around to make this work?

Tom: Okay. Let’s to talk to Teddy. And let’s talk to the rest of the team. They may see something we’re missing.

Maybe Cindy would need Prozac to be this mellow. But most people will hear more and be willing to cooperate when they feel like you have heard their concerns and understand that your goals intersect with their goals.

Here’s what Jason did:

  1. When Jason approached Tom, he checked to make sure it was a good time to walk through the design before he started.
  2. Jason stated his goal explicitly, and tied it to something they both cared about, customer satisfaction.
  3. When Jason heard Tom’s objections, he asked for more information rather than starting to explain his position.
  4. He acknowledged Tom’s concern, and obtained Tom’s agreement that he’d heard the concern correctly.
  5. He showed his willingness to help Tom overcome that concern by talking to the Teddy, the product owner.

in short, he connected, listened, learned, and found a potential ally.  That’s high IQ.

Collaboration: more than facilitated meetings

I’ve noticed something lately: when people write about collaboration, they discuss facilitated meetings or affinity grouping stickynotes. Well-run meetings that encourage participation and building consensus are certainly valuable. Grouping stickynotes can help people see common ideas. Yet, there’s  much more to collaboration than meetings and affinity grouping.

True collaborative assumes shared responsibility, shared ownership, and boosts creativity and learning.

Shared Responsibility

Collaborative teams focus on meeting a shared goal. Everyone’s skills and contributions are needed to reach that goal. In the end, they’ll either succeed or fail together. No one can say, “I got my tasks done. It’s your fault we didn’t meet our goal.”

Shared Ownership

A colleague told me a story about a co-worker, Bob, who was very protective of his code. If anyone else attempted to refactor or add to Bob’s code, he’d pitch a fit and remove all the changes. The result was that Bob was the only one who really knew the details of that module, and all features and fixes had to funnel through Bob. That may mean job security for Bob, but it’s risky for the business.

With a team goal, there’s no room for “my code” or “my tests.” The team shares ownership for its products. Individuals still may know a part of the system in more depth than others, but everyone has an understanding of the overall system, and that keeps the “truck-factor” risk low.

Cross-functional Learning

Shared goals, shared responsibility, and shared ownership drive cross-functional learning. Josh, a tester, applies the Java scripting skills he uses for test automation to write code for the GUI to help the team meet its goals. When the team members are worried about meeting their goals for test coverage, everyone pitches in to write automated unit tests. Team members learn from each other and expand their skills outside of their functional silos.

Process and Organizational Learning

When teams hold retrospectives, they share their perceptions about technical practices, work processes, and teamwork. Team members learn about the specific topic they are discussing and also about process analysis, process improvement, and influencing change.

Deciding Together

In business, we search for the “right” decision and often rely on experts to reach decisions for the rest of the group. While that’s the right approach some of the time, other times it’s more important to have decisions that the entire group will support and move forward. It’s a matter of looking for a good decision that the team will support rather than the “right” decision that doesn’t go anywhere.

Thinking and Solving Problems

Most people in the software field are really good at thinking and figuring out problems alone. Collaborative teams make use of each member’s insights and ideas to generate multiple solutions and then pick from the best. Looking at problems from different perspectives drives creative solutions. When I listen to teams that are starting to solve problems collaboratively, I hear comments such as “I never would have thought of that” and “Your comment sparked another idea.”

Creating Together

As with solving problems, many heads are often better than one when creating. Different people see different visions of what’s possible. Team members build on others’ ideas and challenge each other to fill gaps and weaknesses in solution candidates.

If better results, lowered risk, and increased learning aren’t enough, collaboration is also more fun.

I recently spoke to a domain expert, Sally, who was working with a software team to define features for the company’s main product. “After finishing customer research, I used to work on my own to create the perfect feature description,” she said. “Inevitably, I’d miss something or write an ambiguous description. Sometimes, I’d find out later that what I described was technically possible, but expensive. Those discussions always led to finger pointing. Now that the team and I are working on the features together, we catch those things early. They have good ideas that I wouldn’t have thought of, and we’re having fun.”

When teams collaborate, there’s less pressure on each individual to create the perfect part. Everyone realizes that she has the help and support of the rest of the team, and together they’ll create something far better than each could do on her own.

Collaboration Gone Bad

In spite of all these benefits, some people shy away from collaboration. Collaboration isn’t for everyone. Some people prefer to work alone and do their best work solo. Trying to force collaboration on people who aren’t interested is an exercise in futility (and not very collaborative). Some might have had a bad experience and are wary of trying collaboration again.

Just as collaboration isn’t a good fit for every person, collaboration isn’t a fit for all work. A work group responsible for installing and configuring servers was urged to work as a team and “be collaborative.” The group’s work was queued by tickets that specified the setup for each server. Each setup was a one-person job. While there were occasions when it made sense for people in the group to work together, most of the time there wasn’t a shared goal that required the effort of more than one person. Their manager decried the lack of collaboration—not seeing that the work didn’t require it—and the group members felt their boss was unfairly berating them.

A weak goal can undermine collaboration and lead to churn. One company convened a cross-functional team to “redesign the organization.” Each team member had a different idea of the scope and authority of the group. After several weeks of argument and aimless conversation, group members quietly drifted off to more focused and satisfying work. They never reached the point of collaborating because they didn’t have a shared idea of where they were going.

A team needs the right mix of skills to collaborate, too. If the group lacks key skills, they won’t be able to get the work done, no matter how well they get along and how creative and cooperative they are.

I’ve also seen collaborative teams struggle when one person didn’t follow through on commitments or persisted in working as a lone wolf. Teams that have the skills to do so may hold the person to account or coach her off the team. However, if the team isn’t ready to manage its membership and the coach or manager doesn’t step in, that could spell failure for the team.

Also, when the team members have a shared goal but are rewarded and rated as individuals, people have less incentive to cooperate. Depending on how people are rewarded in the company, they may be incented to compete with each other or even undercut each other. Some collaborative teams survive in organizations that stack rank and otherwise foster competition; these teams need some other motivator to overcome the factors that demotivate collaboration.

And collaboration requires specific skills—skills that we don’t normally learn in school. Dealing with conflict constructively, giving peer-to-peer feedback, and reaching sustainable agreements are all developmental areas for collaborative teams.

By all means, work to make meetings more effective by using participation and facilitation. But don’t forget the other parts of collaboration: shared responsibility and ownership, learning, creating, thinking, and deciding. When we hone our collaboration skills, all of us are smarter together than any of us is alone.

An earlier version of this article appeared on stickyminds.com in 2007.

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.

The Benefits of Peer Feedback

Peer feedback is a core skill for collaboration. It’s impossible to work closely with out running into some bumps: differences, disappointments, and disagreements. Peer to peer feedback can help keep working relationships on track and improve results (and it keeps the manager out of the transaction so it doesn’t be come a *big deal*).

I teach about feedback in both my team collaboration workshop and management workshops. “But does it work in the real world?” some ask. Ola Ellnestam blogs How I Learned about Feedback.

intake->meaning->feeling->response

Mike Cottmeyer writes about Feelings, Thoughts, and Actions.

When people have a strong response, Mike describes thoughts as the point of leverage to change behavior.

How we think can be influenced more directly… it is somehow less personal. We can learn about our environment and the people that are a part of our lives. We can gather more information about what motivates those around us and learn something about their intentions and circumstances. With new information, we can learn to think differently about what is happening to us…..By guiding thinking, we are able to broaden the perspective of our team and create the opportunity to coach behavior.

This lines up nicely with a model I use, Ingredients of an Interaction, from the work of Virginia Satir.

Intake: We take in data from the environment (filtered by our preferences, education, stress level…)

Meaning: We make an interpretation of the data (influenced by past experiences, education, stress level…)

Significance: We have a feeling, based not on the observed data, but on our interpretation of the data.

Response: We act out of our interpretation and feelings.

(Don Gray describes the Satir interaction model in more detail here.)

When Mike coaches about thoughts, he’s working on the level of Meaning, expanding the possible interpretations. When he talks about bringing in more information, he’s working on the level of Intake.

I find this is a powerful model for untangling communication that’s gone awry, and for understanding and shifting my own reactions.

***

On a related note, Mike talks about telling people their behavior is “unacceptable.”

Rather than start out by telling some one his behavior is unacceptable, I find it usually works better to get agreement that the behavior happened. That usually requires neutral language…rather than “you were pounding the table in our meeting today” I might say “In our meeting, I saw you raise your fist and bring it down on the table.” It’s too easy for people to get into a Yes-you-did/No-I-didn’t argument when there’s any hint of judgment in the description. If people don’t agree with the data, they aren’t likely to listen to anything else you say.

Once I’ve got agreement on the data, I talk about the impact of the behavior. “I was startled. I noticed that Jen and Josh both pulled back from the table, and didn’t say anything else for the rest of the meeting.” Depending on how the other person response, I might go further. “When you hit the table, its hard for me to continue participating in the meeting. What I see is that when you bring your fist down on the table, it gets in the way of people listening to your ideas” (or something like that).

I’d rather let the person conclude that the behavior is ineffective and counter-productive and make a different choice. I find that works better with adults than having me say “That behavior is unacceptable”….especially since it may have been accepted in the person’s family, or some previous context (where they learned it, and where it might have worked–on some level).

There are times when I do say “that behavior is unacceptable here,” but I usually don’t need to do that with reasonably well-adjusted adults.

Face to Face Still Matters

There’s been a discussion going on the the Retrospectives list on how to do distributed retrospectives and planning meetings. The assumption is that it’s cost prohibitive to bring the group together.

People always site cost as a barrier. It does cost money to bring people together face to face. There’s lodging, airfare, time not spent on billable activities… and all these are easy to count.

But what this thinking doesn’t take into account are the costs of not having the team face to face for planning and retrospectives:

Less collaboration, greater misunderstandings, continuation of us/them dynamics (be they ever so subtle there’s always differences in access to power, information, and resources), miscommunication, etc.

And there’s lost opportunity to build relationships and trust which short-cuts many of those problems.

But all those are hard to measure and quantify, and are almost always left out of the cost equation. People look at the costs without any of the benefits.

Even when you have access to great technology for planning, retrospectives or other forms of collaboration, face to face is still superior for communication and collaboration in the moment and in building a foundation for future communication. Face to face is superior in building shared commitment and infusing a project with energy.