Oh you poor, poor customer 43
I just got back from my third time at the AYE conference and it was another great time. I had a real eye-opening experience on Wednesday and it had to do with how I interact with customers, QA and even developers. Pretty much anybody taking a class or starting a project where I am involved.
- There were two of us playing customers – we did not understand the problem and we did not necessarily agree or understand where we had different interpretations
- We were freshly assigned the role and did not quite understand the details of the problem, our actual responsibility or how to interact with the team (a deficit of tacit knowledge)
- Time was (perceived to be) at a premium
The session/simulation was run with great expertise by Don Gray.
My first really strong observation was during the first meeting with the development group – about 5 minutes in. My co-customer and I had spent a few minutes (literally) reading the requirements and coming to some partial understanding. We met with the “simulated” development team and all hell broke loose (at least in my head).
The development team did some things well.- They tried to think of something small they could do in a time-box.
- They presented us (the customers) with concrete examples of things they could do as first examples.
- They asked concrete questions about the requirements.
- The presented some preliminary examples of possible interpretations.
These are all good things; things I would and have recommend in the past – and will contine to do in the future. And these things did not work for me.
“Playing” the role of customer, when I came to that initial meeting there were many things in flux.- I did not really have much of an idea of a time-box.
- I had looked at the problem in a very different way than the development team, so many of their questions simply did not make any sense to me.
- I felt bombarded by many voices, with many different kinds and levels of content.
- I am a big-time extravert (Jung’s definition) and I’ve been the source of this kind of bombardment.
- I need to catch myself jumping right in on what I think is important and instead ask what is important to the customer (or BA or QA or developer for that matter).
- I probably have overly high expectations of what can be accomplished before the team has started to form, much of that initial interaction lacks the tacit knowledge of actual roles and requirements, such that many things are in flux.
- Or, given a team that has been together, I need to get a grasp on its structure before making change recommendations.
At one point, someone mentioned (in essence) that the “actual” requirements were coming from Don, not me, and essentially wrote me off. That was quite a powerful experience as I felt completely devalued as the customer. I can imagine a business person or QA person feeling the same thing.
I think the biggest one-word summary of the experience for me is empathy.
“After” the simulation (I still had not fully decompressed I think), one person expressed concern over how the customers (me) had not followed “the process”. Wow is all I can say to my experience during that simple, loaded phrase.
In my world of the simulation, there was no process – explicit or implicit. If there was one used by the team, it was tacit and I certainly was not aware of it (in fact, I don’t think there was one “the process” as far as I could tell because I was able to both participate and observe). But regardless of whether there was or was not an explicit or implicit process, it does not matter. Can you imagine someone who is not fully available (a customer), being treated as if they were “not following the process?”, which I inferred to mean “I was being difficult.”
When I’ve thought that, consciously or even subconsciously, I’m certain that belief clouded my interactions with other people and it probably has come across as aggressive/offensive/inconsiderate. Maybe a good mantra to repeat to myself is something like:No matter how it might look, people are trying to be helpful to the best of their ability.I know for certain my intentions during that simulation were good. I was trying to give information to the best of my abilities. I just wasn’t yet aware of the requirements and I did not know how the development team was working. To be treated as if I was sabotaging “the process” was in fact quite offensive to me. I am certain I’ve done that over the years. “The process”, regardless of which process it is, is a model of how to do things. And something I overheard really speaks about this:
All models are wrong; some are useful.
(Notice how that applies to things like TDD, BDD, Scrum, XP, ...?-)
If you have a chance to attend AYE next year (or PSL in May), I’d encourage you to do so. But be prepared to be overwhelmed with personal observations.
Great insights. Thanks for sharing this. BTW here’s some info about the source of the oft-quoted phrase about models: http://en.wikiquote.org/wiki/George_E._P._Box
Dave,
Thanks for that link. It’s a great first principle.
Add to that:And you get a great, self-referential set of inconsistent words to live by!
Thanks Brett, this is a great post. We get so caught up in doing things (and making sure we do it “right”) that we forgot software is really about people.
“No matter how it looks at first, it’s always a people problem.” ~ Gerald Weinberg
Also like your mantra and one-word summary of empathy. I hope to remember to do the same!
Great blog, you hit the nail right on the head. From the customer side feeling that your input was being discounted due to a preconceived notion or disposition is frustrating. The art of objective listening is always a premium.
These two quotes for me sum up your experience:
“At one point, someone mentioned (in essence) that the “actual” requirements were coming from Don, not me, and essentially wrote me off.”
“I just wasn’t yet aware of the requirements…”
Although they didn’t show you enough empathy, the still assessed the situation correctly. Empathy is great but more valuable is how to treat people who think they have something to contribute but really don’t. If you aren’t giving the team viable information, surely you are subtley sabotaging “the process” (whatever that may be).
@Chris Wellington:
I have to disagree, at least partially. We’ve all had the “opportunity” to have to deal with someone who legitimately has nothing but their ego to contribute, and pushing them gently and tactfully aside is an important skill.
But just because someone doesn’t have a full understanding of the requirements doesn’t mean they don’t have anything to contribute—I’ve seen a number of cases where someone’s focus is only on a specific narrow area of what’s being discussed, and they have a better grasp of it than anyone else. Dismissing their input because they don’t see the whole picture… Well, read Brett’s post to see how that felt from the customer side.
Thanks for reporting about your simulation.
During the exercise, did the team made any attempt to discuss with the customer (you) the manufacturing process?
Few months ago, I was fishing around for building a new house. I was pleased to see that several manufacturers were offering to explain the building process from A to Z.
In software engineering, we have developed fancy processes to extract requirements, to iterate, to test continuously… But, as far as I know, there is no stress on how to ‘educate’ the customers.
Yes we need to listen you them. But when you build a house, it is relatively common knowledge that you will have the basement before the roof. When you build a software application, there is nothing to see besides the UI.
Chris Wellington wrote:
This seems to be exactly the opposite of my point.
What does your feedback to me say about you? That’s, of course, for you to decide. Not me.
Brett
Thierry Thelliez wrote:
Good question. They may have, if so I wasn’t prepared to receive that information. In the initial “meetings” I was bombarded with lots of information, at different levels, coming from may people. So they might have done so, but I cannot say.
Even so, I want to point out that I’m not convinced that this is a generally good (or bad) thing. Ultimately, we are trying to serve a customer. If the customer is served by being educated about the process, then that is a good thing. If not, then it might be a bad thing.
So I think I need to make sure to work with the customer to know what s/he needs. If I do not agree with what/how the customer wants to work, I have options.In reality the first two form a spectrum and might be applied to varying degrees across the spectrum of the interaction.
In any case, educating the customers is certainly something to keep in your toolkit.
The reason why I put “the process” in quotes was to indicate that even though there was no formal agreement on the process, the team was neverless moving forward in some sort of logical fashion. That sounds like a process, even if it is something as accepted as the scientific process. I would find it hard to believe that they were not.
Okay, I misunderstood the use of sabotage. When I initially read it, I thought whoever had used it intended it to mean it as “unintentionally hinder” (which was my use). However that does not mean that the team should put up with misinformation.
If you don’t know what the requirements are (which you didn’t by your own admission), and you are supposed to convey said requirements, what is your contribution to the team?
I think there is a huge gap between “a process” and “the process”. And 10 people going in their own directions does not to me make a process. We might have different perspectives on that but part of what I am saying is: Activity != process. Even so, I was part of the overall development effort. I do not think I was ever brought in to “the process.” So when I was accused of not following “the process” I felt like I was being blamed. It’s a two-way street. Bring me in if you want me to participate. Do not bring me in? Do not blame me for not playing by your rules.
Fair enough – I assumed a particular interpretation of the word, with negative connotations. I won’t quote the dictionary precisely because words like “sabotage” are thing with different meanings and interpretations; their meaning (like all words really) is in the listener, not the sayer – much to any talker’s chagrin. Even expressions like “plain vanilla” are highly ambiguous (as I learned from Rick Brenner several years ago at a conference called The Leaders’ Forum.)
Really, most of the requirements were well understood enough. One particular word, “stack” was at question. As in, make a stack (or a pile) of X. My co-customer and I had the same interpretation of the word. Don, the facilitator did not – his was easier to work with.
In all the projects I have every worked on, “the requirements” are in flux, changing, and essentially unknown to varying degrees. In fact, there is no such thing as “the” requirements. Maybe I am pulling a Bill Clinton on the definition of “the” but that is how I see it.
What happens if nobody knows “the” requirements (which is the norm)? We could do nothing and wait for them to be understood. That’s moving towards the “sign-off” extreme.
We could come to a best understanding, move forward with that understanding, get there quickly, get feedback and readjust.
Neither approach is “right”. I prefer the feedback path, but keeping the option open to say “no” is important. (If you understand the MBTI system, you can interpret that to mean I generally prefer Perceiving versus Judging.)
Additionally, people are often assigned to a given role and it takes time to figure out what that means. If my team members are thinking: ... what is your contribution to the team?This attitude will almost certainly come out in interactions and it will (probably negatively) affect team dynamics. In fact, I’d suggest that the dynamics will be so affected that using the word “team” will be wrong. It will be a group of people called a team as opposed to a team. To me, those are very different groupings of individuals.
On the other hand if I assume:I think that is going to lead to a team gelling.
Does this mean we have to keep everybody on the team? No. Just as it is important to treat one person with respect and consideration, the same thing applies to other members. In some cases, given individuals will not work well with the team. Being able to have a say in the team makeup is an important thing that in fact distinguishes a team from a “group of individuals called a team.”
This is such an interesting read, I think Brett summed it up neatly when he said ‘the process’ and ‘a process’. I think this statement actually probably applies to many different situations in life generally and not just at the AYE conference. As Jay mentions up above, you have hit the nail on the head. I think ‘customers’ are often bombarded with information rather than being clearly explained to, especially when it comes to software! Makes me think of the complexities of buying a house You never feel like you know where you stand with everyone else, because people want to be recognised, a team IS usually just a group if individuals.
i am poor one
A comment on the need to educate the customer:
In the enterprise context ou rarely deal with customers directly. Rather you deal with users and stakeholders.
In this context you are well served to eucate them, as they should be considerred, and made to feel, part of the team.
I think this reinforces Brett’s point about making all people feel like they are making a valuable contribution.
Yes…poor customers! And it is difficult to be a poor customer too!!
i am agree with face off.
Prudential West
very interesting on customer relations salesjobs
come to have a look
Although they didn’t show you enough empathy, the still assessed the situation correctly. Empathy is great but more valuable is how to treat people who think they have something to contribute but really don’t. If you aren’t giving the team viable information, surely you are subtley sabotaging “the process” (whatever that may be).
Wholesale Brand Name Clothing
Yes we need to listen you them. But when you build a house, it is relatively common knowledge that you will have the basement before the roof. When you build a software application, there is nothing to see besides the UI.
Wholesalers
i am agree with face off
come to have a look
When it comes to table sports games it’s never too late for you to become a “Kid”. The challenge and competiveness of these sporting activities brings out the “kid” in everyone. Show your friends and family that you still are a “jock” at heart by impressing them with your best moves when you go head to head playing table football.
Crazyvids.org is a website designed for sharing with our visitors the craziest and funniest videos we can find on the internet. We do not take credit for all the videos published in this site, we search them on the web and publish them so the public can see our favourite selection of videos.
Introducing the World’s Most Profitable Ice & Water Vending Machine, The Bag of Ice XL1900. This is the smallest, most productive, green ice vending machine on the market.
The development team did some things well.
There are some very great sources here and thank you for being so kind to post them here. So we can read them and give our opinion on subject.
Pretty cool post.It’s really very nice and useful post.Thanks for sharing this with us!it’s my first visit.Pretty cool post.It’s really very nice and useful post.Thanks for sharing this with us!it’s my first visit. Free Hosting With MYSQL
Easily, the post is really the sweetest on this worthwhile topic. I fit in with your conclusions and will eagerly look forward to your approaching updates. Sayingthanks will not just be sufficient, for the exceptional clarity in your writing. I will immediately grab your rss feed to stay privy of any updates. buy jewellery
I think this is really awesome and you really told what actual customers are…We need to be very careful about this..
Great read, I really enjoyed this. Thanks
Latest iphone 4 white Conversion Kit with white color is now available, Let’s try!
thomas sabo australiathomas sabo australia For anybody who is really a trendy splendid lady and someone thomas sabo who seriously loves applying herself intelligent
Almost any situation--good or bad --is affected by the attitude we bring to. Adversity reveals genius; fortune conceals it. As fruit needs not only sunshine but cold nights and chilling showers to ripen it, so character needs not only joy but trial and difficulty to mellow it. Although the world is full of suffering, it is full also of the overcoming of it. tiffany and co outlet
I agree with you.It is correct How we behave with our customer is directly affect on our business.Thanks to share these things I will try to follow these measures to handle the customer.
I like your blog you have studied so much on the behavior of the customer and I am sure that it will be helpful for the people who wants to know how they should handle the customer.Its my own opinion that if we remember and use these measures we can definitely improve the business.
I am agree with you.I would also try to get the chance to participate in AYE conference.It is nice to get the experience about the relationship of customer and businessman.It was a great post.Thanks for the post.
very good.
internette görüntülü olarak okey oyunu oyna, gerçek kisilerle tanis, turnuva heyecanini yasa.
I am totally agree with you.I love your blog I am sure it will be helpful for that people and of course it really helpful for me.Nice Explanation about handle the customer.http://www.classicbedsteads.co.uk/ Thanks for shearing Nice blog.
asd asd+0fsadfss
asdfs df+gs79878788s5ss
asa sd+f89s9s9s9ss
For upwards of seven several years I actually procedure each day studying, I love to understand information sites or maybe reportage like that, through matters connected with general population anxiety in addition to a very efficient in addition to appropriate information and facts. I would personally express so long by developing straightforward which will department is certainly impressive so I would choose to be given additional information and facts