Customer discovery is a balancing act Part II - Methods for product management

In the previous blog, I wrote a thing or two about where customer feedback can be found without lifting a finger. About the places where the customer feedback already exists and what is the cross-functional function of product management with marketing, sales and even support. In this blog text I concentrate more on interviews, workshops and in service design methods that can be used to directly collect feedback from customers.

Photo by Samer Khodeir on Unsplash

Interview to find patterns and similarities

Analyzing this "automatic feedback" I talked about in previous post is good, just remember it's usually biased and are good for hypothesis and assumptions. I've been used to gather this data from support and sales and just counting the issues that are similar, when I get enough data to prove it's necessary it's time to do a couple of calls with few of the customers to do interview. Interviewing can be done by directly calling, taking a meeting or even through support issues - don't get restricted, instead use your creativity! Remember, it's all just learning really fast WHAT your customers are doing and WHY they are doing it!

In interviews I tend to forget about the software in total. I don't want to know how they use the software, but WHY they are operating like that. Usually before I interview the customer I form and idea of a solution already, but keep it in my own head until I verify that my assumption of the root cause is validated. If I wrote a few rules about the interview process, it would be like this:

- NEVER show the solution first, it biases the customer against your assumptions instead of proving them.

- Talk about customer's processess and needs by using open ended questions like : "What do you mean by <whateveritis>, could you explain the process a bit more?", "Who is involved in this part of the process and why they are doing it?".  Ask them to tell a story why, who and how they do things currently, but focus on WHY and WHO!

- It's better to be stupid than wrong. If you don't understand simple things, ask customer to clear them out. Usually it's because you assumed something wrong and knew too much instead of being stupid.

- When doing multiple interviews, look for PATTERNS and SIMILARITIES, usually then you can do a general solution. Don't run after one customer (even they're paying good), but solve for larger masses. It will benefit the software so that It's not customized for one only customer.

In the end of the interview give the customer a pre-thought of solution for short term resolution. It might change a bit during the interview, but at least you know why they are doing it and they get reassurance that you care. It might be harder to use, but at least the work can be done (blocker solved) and you can get time to hone your feature if it proves right. If it's totally wrong, it's a success, you just saved time from not building something!

Photo by Julien Rocheblave on Unsplash

Complex problems need more interaction

Interviews in different ways are one way and can be relatively easy if you got key customers, you can even form a group of your most enthusiastic customers (whatsapp, e-mail, skype-meeting once a week) to do interviews with new features on regular recurring intervals. Interviews don't work on complex and large questions very well, no matter how many interviews you do, you only get a partial understanding of the whole process.  In these cases I'd use service design methods like customer journey workshops or even shadowing. 

These are really good methods whenever there are multiple personas or multiple contact points for certain role to succeed. Let's take payroll management for example: User has to enter the work times, supervisor usually accepts, corrects or asks employee to correct their work times, payroll management calculates the salaries and transfers them to bank so that the employee gets paid. Now if the payroll manager has a problem that someone needs to modify their work times after approval. You automatically assume that these just happen... but be paranoid!

Photo by You X Ventures on Unsplash

Workshops to the rescue!

It's better to keep a workshop and talk about the process regarding the payrolls so that the supervisor and even the employee is there. After all it all might be just because the employer didn't have any notification about the due date of entering the work times in certain date. With only interviewing the payroll manager he just wants to correct the one timer errors instead of improving the whole process. By taking also the other roles in account, it might reveal other problems that escalate further in the process.Earlier contact point might save time more by eliminating the errors in all instead of concentrating on fixing them continuously. These usually are hard to spot on interviews, but shadowing or even small workshops can reveal them.

For example in one company I worked with software that did all sorts of financial stuff. We got quite a lot of support questions concerning it that gave a hint of it being too hard to use. it and decided to hold a workshop. During the workshop it came clear that the most issues came from the point where the first end-users, which weren't the ones calling our  support, didn't enter all the necessary information at all, but tried to go easiest way possible. This escalated later in the process and caused a lot of checking and leading misinformation. Customers who called our support were in trouble just because couple of field's weren't mandatory or weren't informed. We would have made a different and harder fix if we only had listened to the calling customers.

In these workshops I love to use post-it notes to describe the users, and by asking a customer to "tell a story" about "The day when he salaries are calculated" and just by asking things along the story. "Why the supervisor has accepted them? When they should be accepted at last and why?", "How do the employees know when to enter their working times?", "What happens if someone is on vacation during the payroll day?". Record the workshop if possible and draw a flow diagram out of the process and the possible contact points. Repeat it to couple of customers and find the patterns and similarities! You'll get more insight than thought of it than in only interviewing single people.

Photo by Steve Halama on Unsplash

Shadowing to help spot new solutions to hidden problems

Shadowing is another really good solution. By shadowing I mean that you take a recorder and go to your customer's site to just follow people using your solution. Observing customers in real life might show you problems that you even didn't know existed, but can be solved easily with small improvements. During shadowing keep the customer representative talking, keep an eye for how and where they do things. For example when using mobile application, if they continuously walk to the office from around the house to see something, it would be beneficial to use the application to store the information they go see all the time. Keep an eye on papers, physical objects they use, and the places they go to. Connection problems might just be because of bad network in cellars and it escalates in your support by "application is really slow". It's really insightful to see how the customer use your software in real environment and in real life. It just can't be interviewed, but be a detective and always try to find your customers more value!

Summa summarum

The teaching of this blog post is that LISTEN to your users, but listen them SELECTIVELY. It's about WHY it's needed to work that way, not about how it should be built. Customers are biased depending on their position and their way of thinking, people tend to fall in love with their solutions. Use your creativity to proof the way things should work, use workshops, use interviews - for the sakes, use post-it notes against drawn images or whatever, just get to the customer to ask about their processes. It's for the customers you're doing the business.