Want Feedback? Best Article of Month Teaches You How

I just read an excellent article in Forbes about new and better ways to measure performance. These really are new kinds of metrics. Way better than the usual revenue-derived ones that are slapped on people who have nothing to do with sales. They are somewhat esoteric, but they are eminently linkable and valid to the concept of customer feedback because they are trying to judge how things such as learning, joy, usefulness, and improvement.

I found that points 3, 4 and 5 can be related not just to managing a team, but also to getting feedback from people (whoever your customer is, be it internal or external), and using it to improve things.

Perhaps the most interesting one is Metric 4: Compound Weekly Learning Rate. If you can determine what someone has learned and made themselves better by, be it a software shortcut, a new way to make a meal 5 minutes faster or just tastier, or anything that opens your mind. Or someone else’s. Or makes a better product. Doesn’t really matter, but it demonstrates that you can see people being happy through the joy of learning, and that it compounds, and that joy translates into either more sales, more productivity, more friends, etc. Just a better life.

Metric 5 is sort of like the net promoter score but for real people, not just customers, but it does emphasize being positive and passing along the positives in life to make sure thee are more positives than negatives. Sort of like positive ions for the management soul.

Worth a read, that is for sure.

3 Tips to Keep Focus When the Customer Changes

It has been an eternity since I last posted anything here. And that is because things changed and I lost my focus. My role changed at the company, twice in fact, and it is now that of a manager in a highly visible area where there is a criss-cross of management needs and customer needs, which don’t always jive.

My customers have changed, because they include the people I manage, who manage me, and the companies who buy our products.

When these changes in circumstances happen under a spotlight, the natural reaction is to react first and fix later, whether it be a product plan, a strategy or even hiring. And when you firefight and react to everything immediately, you lose focus. I know I do. So I have to fall back on my best practices and strategies for dealing with it, and these apply whether it’s software development, client meetings or hiring talent.

  1. Don’t just react, instead acknowledge. So often people react without thinking — look at how we behave in traffic — because they feel threatened or they think their job is in danger. Usually it isn’t and stopping and acknowledging that there is a problem, and what exactly what has gone wrong or right is the only way you’ll ever learn. And it allows you and your team to stop, discuss and focus on the problem so you can focus on your customer.
  2. list_imgMake a mind map and then make a list. If you’re not sure what a mind map is, check it out on Wikipedia.  The short version is an connected yet not definitely structured (in terms of priorities) graphic depiction of your ideas. It’s a great starting place letting you figure out where you are running into problems, what kinds and how you can resolve them so you can go back to focusing on the tasks at hand. Once you do the mind map, make a prioritized list, with a backlog of items you want to check off. It’s a slow distillation process but worth the effort. Budget half a day for the whole exercise.
  3. Put your foot down. You may not have the ultimate power to decide anything, but make sure you have certain hard points or priorities that you are willing to fight for. They become your focus points of action. You may need to convince your team or your boss or your customer that these issues are important to  resolving the issues your customer perceives. There may be disagreement, but be prepared to make your case why you don’t want to budge on these things.

The Kickoff

I held a kickoff meeting last week for the customer feedback project I am leading and like all kickoffs, I found you need to define goals and deliverables  in simple clear terms, and very crucially, define those terms and ensure there is agreement on them. And that requires a lot of forethought especially when you are dealing with people on other continents as I am.

Since I had done some background research on who would be participating in the project, I knew what their expertise was and what role they would play as well as what strength they could play on to help the project move forward. But to portray that in a way that made sense, I established 5 things that applied to all participants:

  1. The project – What’s it all about and why are we doing this. If the direction isn’t clear (to you and the team), the participants will lose faith immediately. This is where you start to establish the terms you’ll be using, such as “feedback loop” or “target group.” The wording can’t be too vague and it has to be relevant to all people in the team. And probably most importantly, they have be motivated by the project lead and they have to know they will learn something new too!
  2. The team – Who is who and what expertise do they bring to the table. That lets every one know who they can turn to for specific questions. Try to also see where gaps are when you assemble your team. These could be gaps in knowledge, in coverage, resources, or any other number of things. Anticipating gaps is hard but very useful.
  3. The goals/deliverables – This seems obvious, but goals and deliverables are often confused. What do you want to achieve and in what format will you present the results that are genuinely implementable (if at all). Make sure the deliverables are acceptable to the person sponsoring the project and that they can be acted on. As for the goals, make sure these are attainable chunks comprised of clear tasks. Use a work breakdown structure to figure out what you want to do. This can and will be modified in the course of the project.
  4. The timelines – Know the duration of your project and what are realistic blocks of time to accomplish your goals. And always plan in buffer for people quitting, changing roles, getting sick or the scope changing because the senior manager wants it that way. Above all be flexible.
  5. The resources – What are the repositories, sharepoints, meeting minutiae, agendas and other tools you will be using to run the project. Do you have a proper project charter? Is there a place to store all your info that everyone can access? Did you set up regular meetings? Does the agenda make sense and cover all aspects?  I am not counting the team members as resources here, just the tools you need to get the work organized and done.

So, that is what I used and the meeting went off perfectly. I even got praise from the sponsor and from her boss as well. Feels good when you have a plan and everyone understands it too.

Customer Interaction Framework – Big Name, Lots of Work

Recently I was given the task of running a project that will create what is known around here as a Customer Interaction Framework. In short, it’s meant to determine what our internal customers need when they do their job with our product, and then find a way to get useful and meaningful feedback from them. And once we figure that out, create the framework so it can be applied to all the global teams so they can generate a feedback loop to build in improvements.

Man, that is a lot of work.

The project scope is meant to span the globe yet only comprises 5 team members. We decided that keeping the team small and staffed with people who not only have experience in this area, but who are also passionate about having a dialogue with their customers and encouraging feedback. It will focus on deliverables we know we can get good feedback on, and the people in the project all have their area of expertise.

But one of the aims of this project is to set up a framework where we can get pretty specific feedback on certain deliverables and then act on it at a global level. If we don’t, we run the definite risk of alienating our customers. The tricky part is that some people are nervous about getting feedback as they think it will reflect poorly on them personally. But we have to avoid that.

However, the prerequisite for success in this project, in my opinion, isn’t the team itself being competent or motivated. That was a given. It’s actually doing our homework at the start of the project to make sure we know who we are speaking to — so we can speak their language. This will entail mapping our deliverables to the project phases and the roles that come into play at specific points, and what those people in those roles need to get their jobs done. Not an easy task. But with a name like this, I never thought it would be easy.

I hope to post more updates on this topic as the year goes by.

The Anonymous Channel

I was recently involved in testing changes to our help portal, and we are (finally) going to implement a feedback and rating option on our help topics. For the longest time I thought this wouldn’t really bring much in the way of feedback.  However, it was through a different feedback exercise that I started to realize the value of this anonymous feedback channel.

Based on speaking to our target audience, I understood that they have so much feedback to give, and want to be listened to so badly, they welcome ANY channel.  Face-to-face, or anonymous. Doesn’t matter.

I always thought that when people give ratings and feedback anonymously via a form online, that they wouldn’t really take the time to think about something or state what is good or bad about a document. I thought that ratings were insufficient to give the evaluator a real sense of what is needed to improve our product.

But after speaking with several members of our target audience in one-to-one interviews, they showed their passion for giving feedback on our product.  And then I realized this akin to the multiple platforms out on the web that allow people to state their minds, especially when they are experts. Whether it be blogs, twitter, Facebook, run of the mill websites, DIGG, RSS, or whatever other tool is out there, people who know something want to share their feedback. It’s not just one-sided, it’s real collaboration and cooperation.

In this case, I realized it’s not an inferior channel to interviews or online questionnaires, rather it’s an additional anonymous channel that lets an expert user give feedback using free text and star ratings that the author will eventually receive so he or she can better the product.

In short, there isn’t one feedback channel that is better than another, they are all good, whether they be anonymous or not.  Just give the audience the option to speak their minds. The rest is evaluating it later. And that’s a topic in itself.

Evaluating According to Roles & Persona

I recently sat down with one of my colleagues from Knowledge Management who has been working in the area of customer feedback for quite some time. She really has a good feel for how to analyze and approach results, as well as set up a project from the get-go.

She and I were speaking about the definition of the audience and the roles of the people interviewed. She found that defining the roles and responsibilities of the target audience, in particular, what documentation they access to execute their work, gave real meaning to her results. She broke down the roles into technical and process experts, as well as their relative levels of experience in those roles. She then created a personae for each task-based role that a person performs at the company.

In addition the questions were generic enough that they could be answered by all the different roles and people being surveyed. You can’t always drill down as much as you’d like, but this was still a good approach for the team’s needs.

From these almost real personae, she could derive useful generalizations based on “Bob the Programmer” or “Steve the Consultant” or “Miriam the Support Specialist” or whatever she and her group of feedback coordinators deemed appropriate.

But her results didn’t lead to generalizations that were too wide. She did not say “all developers found this documentation useful.” She took samples from both ends of the spectrum to highlight what went well and what didn’t and what was accessed and what wasn’t. The persona was really the starting point so that people looking at the data could give it a human face and put it in a context of a real working environment.

The only real danger with using roles and personae is that there might be preconceived notions of what the role and tasks might entail or if that role no longer exists at the company (which does actually happen).

However, this is an approach I can heartily recommend because it gives you good results and a good story to sell to your manager when you are asked “SO what did you learn?”

Feedback On Feedback

This is just a short post. I had the opportunity to give a presentation to the Montreal chapter of the Society for Technical Communication on all that I have learned over the past few years regarding getting feedback in the world of documentation.

I am always impressed with just how much technical communicators know and understand about what it is they do and how really to communicate in so many different media. And I was happy to see how feedback was something that interested them. I can only hope I did a decent job of portraying my experiences and knowledge in the company I work for. And I hope it wa useful and relevant to them.

I am always keen to get feedback on my feedback knowledge and hope to learn even more as I go on with this topic.

I have also posted a link to the presentation I did: STC_Customer_Feedback


Why Numbers Lie

So often people are asked to give feedback on a given project or piece of work, or perhaps a service or product or experience they had. And so often you get the “On a scale from 1 to 10…” measurement.

And this is just a lie.  No, it’s not a lie in the sense of actively deceiving someone, more a lie in that a number doesn’t reveal the truth behind the comment.

Numbers & Feelings Don’t Add Up

I am compiling a list of responses from a feedback loop we have built-in for our documentation projects at work. We use a 1 to 5 feedback scoring system and we allow the respondents (it’s all anonymous) to voice any concerns or ways they think we can improve our service. Inevitably the feedback we do get does not always match with the scores. We get 5 out of 5 on a bunch of criteria, yet the feedback people write in indicates otherwise. So why the discrepancy? Because people will click off numbers and don’t want to think about too deeply. But as soon as they can air their feelings or ideas, they do, and it’s much more insightful and can lead to really actionable feedback.

In short, numbers rarely convey feelings and often people don’t say what they mean.

So Why Measure Using Numbers?

Well, the short version is, it’s easily measured and evaluated. Sixty percent of respondents liked ‘X’, or the average satisfaction score was 4 out of 5. Great, but there is no nitty-gritty detail in that. The other reason is that the world is ruled by numbers guys. When you go in front of a manager who is giving you 30 minutes of his/her time, numbers make a bigger (and simpler) impression than do words. And while both are always open to interpretation, numbers “appear” to tell the truth. And we know that isn’t true. Also, it’s easy to grasp a number and not so much a feeling or a concept. Especially not in the IT industry.

What’s the Answer?

Look, you’re going to have to have numbers to justify your arguments, that is the way business works. But if you get a chance to either speak to your potential respondents in an face-to-face or telephone setting, or you can get a blog discussion going, you will get someone’s real feelings and ideas and that is the closest thing to the truth you’ll get. It will lead you down the path of taking feedback and incorporating it into whatever you do to make it better.

Web 2.0 and Feedback – It’s a Delicate Thing

I would be remiss if I didn’t blog about feedback in the Web 2.0 world. It has become utterly integral to the whole feedback loop from a company and personal perspective. If a company doesn’t have a blog or a wiki, it’s losing out on valuable feedback loops, whether it be internal or external feedback. But it’s a delicate balancing act to use these tools. They harbor huge promise and potential, but they  can also spin out of control if they aren’t used correctly. (I won’t go into Twitter just yet — it’s a different animal, even though it’s related to blogs in many respects.)

The two feedback streams I want to talk about briefly are blogs and wikis.


Everyone has one, everyone uses them, it is the place to spew ideas, feeling, concerns, have discussions with the rest of the world (literally). But how can this tool, this medium be used effectively for customer feedback? In short, if you control it, steer it and maintain it, you can garner a huge amount of feedback over a period of time, which can give you a nice snapshot.

If you deliver a service or a product, a blog can be a good way to get a discussion going. GM’s Fastlane blog is a great example where the higher-ups at the company get in on the discussions. And more importantly, start discussions. It can get you in trouble — just ask Bob Lutz and his comments on global warming — but it’s a reminder that controlling the discussion is critical to getting good feedback. Since almost anyone can post a comment, you are open to harsh criticism — and passionate defenders if you take of customers properly.

If you follow a blog discussion, analyze it, and keep it alive, you can mine it for useful feedback and use that to improve what you’re offering.


Wikis are a different animal, and I am not just talking about Wikipedia. I am talking about chipping in, collaborating and possibly making something greater by using the wisdom of the many. Although a wiki is a collaboration tool, it can also be used to garner feedback, and in most business cases, internally. You can post ideas and documents for reviews and get feedback relatively easily. It’s more one-way than a blog, as permissions and editing rights are required here. But it’s a good tool to do virtual feedback rounds with internal experts. Just remember, you can use a wiki for more than just collaboration, but maintain control of who can access it and edit it.

What’s it all mean?

Web 2.0 tools are critical to gather legitimate, actionable feedback, but you have to be careful about who has control of the conversations and how you direct the flow of info.

Getting Feedback One Reader at a Time

I might as well go into my current client’s office in a space suite because it’s sort of like working in a vacuum. I have lots of stuff — like pages and pages — but at this point in the project really very few comments. In order to make the project a success I need the experts to provide feedback. I can only create so much without getting some kind of validation.

I tried the group thing but that was KOD’d by my project lead (see https://getcustomerfeedback.wordpress.com/2009/10/27/no-control-ko/ ). What has worked has been a rotating series of one-on-one meetings. It has a number of advantages:

  • It helps build ownership — everyone that helps out begins to really understand what the project is trying to accomplish
  • I am able to reduce the time I need to get comments as I can target a specific resource for each topic I need to cover and can point their feedback to the specific points I want to cover
  • The conversations seem to travel all over the place so they help answer questions I didn’t even know to ask

How do you make one-on-one meetings really work for you?

  • You must always have something they can comment on. You can’t just have a headline and ask them for the details. You must have at least some details in place already — even if they are 100% wrong. 
  • As you get them to talk, you have to remember that these are the experts and their comments might push you to a new spaces — one small comment might even mean massive changes. But again, these are the experts.
  • Bounce the changes back to them. You have a built-in reason to give them something else to review so take advantage of that.
  • Use the new relationship. If you find you have more questions based on what they said, go ask. As you have the relationship now, they will (typically) give you the space for more time for those last couple of things.

Can’t get a bunch of people to give you a little feedback each? Don’t be afraid to get your feedback one reader at a time.