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.
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.
- 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.
- Make 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.
- 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.
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:
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!
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.
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.
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.
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.
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.
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?”
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