HappyOrNot CX360 Leader Insights: Part 4
Do you understand what your customers are trying to accomplish?
Dan Marinescu-Gava and Eeva-Liisa Lennon manage the teams that set the direction of the HappyOrNot product line (Dan) and then make it all happen (Eeva). They work well together, in part, because they agree that understanding customer challenges is critical not only to producing superior products, but keeping HappyOrNot out in front of market demand. Eeva and Dan spoke with HappyOrNot writer Tom Hagy of Philadelphia for our fourth installment of the HappyOrNot CX360° Leader Insights series, where we share thoughts and best practices for injecting customer focus into your organization’s DNA, and showing how CX will improve both your competitiveness and your bottom line. The purpose of this series is to help organizations get CX right. Read on for what Eeva and Dan have to say about the intersection of CX and customer-focused product design.
Customer-focused design means addressing a need whether the customer can explain it or not
TH: Since you work for a customer experience company I guess you pay extra close attention to what your customers are telling you. What would you tell other product planners and developers about this part of the job? Dan, why don’t you go first.
DM: I’d tell them to embrace curiosity. Then listen, listen, listen, listen. When crafting your product roadmap, first get as much information from as many sources as possible, then overlay those against parallel paths you have experienced or observed that have been followed by successful companies in other industries. For example, look at the mobile computing industry. It started with semi-standard hardware platforms then moved to semi-standardized hardware and software and then data moved to clouds and back again. See what that kind of thing teaches you about the potential path for your product. It’s amazing how similar different types of products can be.
EL: Qualitative data like that is important. We also strongly believe in quantitative data. Traditionally R&D has relied on intuition, and qualitative feedback. Now there are tools to collect invaluable quantitative feedback. For example, we all have apps on our smartphones and many software tools we use for work. Developers keep adding features but that may not enhance the customer experience. You may never use them. If you keep adding them it adds complexity to your device and can actually make it harder to use. As a developer you might think you are improving things but the quantitative data might show that you’re actually making things worse, especially if you’re adding functions and not removing any based on what customers actually use.
DM: When you put these things together, qualitative and quantitative inputs, you are more likely to uncover a solution the customer didn’t know they needed or didn’t know how to articulate it. This a formula for success because if you are only responding to customer needs, which you must do, that will merely put you on the same track as everyone else who is following the customer. Developers need to figure out what path to lead customers into based on their needs. That’s the tricky part of the project management role: deciding the next steps to take.
TH: How did that work at HappyOrNot?
DM: Customers were not originally saying they needed real-time feedback reports. Even last year no one was coming to us with that request. The CX industry is now moving in that direction and we have already been meeting the demand for it. So now we’re already working on the next thing.
TH: How can developers best monitor their customers’ use and their experience with a product?
EL: A good web tracking tool can give developers data on how many customers have used each feature and how quickly they start to use new ones. Just like our customers can use our Smileys to collect quantitative feedback from their customers in the physical environment. You want to know if enhancements are adding value. If something doesn’t get used, you have to think about whether it’s too difficult, or if you haven’t told the customer it’s there, or if it just isn’t useful to them. And if you see it is being used you can analyze it, and use qualitative methods like interviews to get more insight. Why are these people using the new feature? Is it creating some value that you could deliver to other customers by doing something slightly different or is it an industry-specific need?
TH: You’re monitoring HappyOrNot customer data closely, just like they monitor their customer feedback closely using your service.
EL: Yes, and we can even watch the location and battery life of our Smiley Terminals. We have created an alert so we know, and the customer knows, if a battery is running low somewhere. By knowing the location of the terminal, we can advise them on a better placement that’s located where the wireless signal is strong so the battery will last longer.
[clickToTweet tweet=”Good software and UX designers will find the story behind what the customer is asking for.” – E. Lennon, HappyOrNot CX360 Series, Part 4. ” quote=”Good software and UX designers will find the story behind what the customer is asking for.”]
Software and UX designers need to find the story behind what the customer is asking for
TH: When I think of an app developer, I think of someone sitting alone in a dark room illuminated only by flat screens and blinking lights. Do you recommend developers have direct contact with customers?
EL: You probably enjoyed The Matrix.
TH: All 20 times.
EL: Yes, I recommend developers meet customers. We go with our customer success managers and speak with store managers, for example. We review answers to customer questionnaires. We use User Personas (of different types of customers) which helps us walk in the shoes of a shop manager. We will visit shops to see customers using our product, too.
TH: So you really pay attention to the customer and the customer’s customers.
EL: It’s useful, but for developers, it only gives you part of the picture. Sometimes the data will tell you more than the customer might be able to articulate. A customer might tell you what you want to hear. That’s natural. Or maybe they are an exception in how they use the service. Once you collect qualitative data you want to go back to the quantitative data and ask, is this person an outlier? Is this an exception? Is the pattern repeated somewhere else? Is it typical for that industry? We want to know, for example, if there are any connections or similarities between industries and different use cases.
DM: When you have a customer asking for something or finding value in what you have developed, it’s time to ask yourself “does another type of customer want this?” Many problems are universal and span across industries and customer sizes, which means your solution is scalable.
TH: And scalability means more sales opportunities. As an aside, I’ve heard customers jokingly ask if the terminals could clean themselves.
EL: You know, we recently incorporated an antibacterial coating for the Smiley Touch. Our healthcare customers had been asking for that.
TH: Wow! I was kidding, but I could see why healthcare workers and patients would want that. What else are you working on?
EL: The San Francisco 49ers are very creative in how they address the fan experience at their stadium, and we are doing some development to help them improve the operational side of the experience.
TH: True. I’ve interviewed them for a customer story. They seem to have a roadmap of their own.
EL: They wanted their mobile app to have much of the functionality we provide through our web reporting service. So, we added real-time alerts to the app. Now their teams can immediately see on their smartphones when something needs to be addressed at the stadium, like a food stand that is out of hot dogs or the queue at the entrance is too long and even have a discussion around the root cause of the alert, on the mobile app.
TH: I know the real-time alerts made a big difference in their operation. Like how quickly they can respond to a problem.
EL: We’re always working to improve speed, too. That’s an example of working closely to understand the objectives of the customer. We want to increase the speed of data transfer so the alerts will be even faster. We’re working to increase the battery life on the Smiley Terminals, as well. Customers want that.
DM: Customer feedback like that is invaluable.
TH: So, as you said, now you will deliver the solution, and that will benefit other customers. The solution is scalable. I see.
[clickToTweet tweet=”Like a good hardware store employee, good product designers focus on what the customer is trying to do, not just sell them a hammer.” – E. Lennon, HappyOrNot CX360 Series, Part 4. ” quote=”Like a good hardware store employee, good product designers focus on what the customer is trying to do, not just sell them a hammer.”]
“What is it you’re building?” UX designers can learn from the guy at the hardware store
TH: Can you give an example of good customer experience you have had personally? Eeva, why don’t you go first?
EL: OK. I live in an old house. We’ve done a lot of renovations in the last few years. For someone who doesn’t know anything about building it’s awkward walking into a hardware store to buy windows or doors or concrete or tools. I found a place where they have someone always available to help, and now I always go there. I don’t have to hunt for assistance.
TH: What makes them so good?
EL: They have knowledgeable people who first try to understand what I am trying to do. Sometimes you go into a hardware store, ask one question, and walk out with a tool. But you have to come back the next day because you really needed something else. At the place I go they ask, “OK, what do you want to do with this tool?” Then they say, “You need this, yes, but to really do it right you will also need this and this.” They want to understand my objective, not just get rid of me just by answering the question I came in with.
TH: Good point. What can developers learn from the hardware store guy?
EL: Developers should try to understand what their customers are trying to achieve. When a customer asks us to modify the product, its size or shape or color, or if they are asking for a new feature, we first want to understand what they want to accomplish. We might have something that fulfills their needs already, or we might find that what they are asking for won’t give them the results they are looking for.
TH: It sounds collaborative.
EL: Yes, and you have to have people who are good at gently challenging a customer’s request so in the end they get the results they are looking for without feeling as though their input isn’t valued, because it is.
DM: That’s right. The product planner’s job is to ask, why do you need that? What is the problem you are trying to solve? Since developing products is our profession we are skilled at coming up with solutions that best satisfy customer challenges. So it’s up to us to ask these questions.
[clickToTweet tweet=”Product planners have to fight the urge to jump to a solution, then turn to the expertise of the development team.” – D. Marinescu-Gava, HappyOrNot CX360 Series, Part 4. ” quote=”Product planners have to fight the urge to jump to a solution, then turn to the expertise of the development team.”]
Solutions are like conclusions – you don’t want to jump to them
TH: Dan, when a customer tells you their challenge do you, as the product guy, ever want to say, “Hey. We already have a solution in mind for you?”
DM: It is tempting, but no. Product planners have to fight the urge to jump to a solution. When a customer tells me they have a problem, I automatically start thinking about how to solve it. It’s how a lot of product people are wired. But I fight that because our development team has the real expertise to create the right solutions. Product planners and developers have to fight against solution bias.
TH: What about you, Dan? What good or bad customer experience have you had recently?
DM: Over the summer I told a bank what I was looking for and what challenges I needed to address. I gave them an exact list. They came back to me with proposals that had nothing to do with my needs. No one was listening to me. Their CX was appalling. I went to a smaller bank and they came back with a proposal that matched my objectives point-by-point. They weren’t pushy and weren’t trying to sell me anything, either.
TH: I think a lot of people can relate to that story. Like me, for example. Back to Eeva’s hardware store guy. He’s the customer’s main contact with the store in terms of finding solutions. Somewhere along the line someone decided those frontline people had to be amazing.
DM: Product planners often think in terms of whether executives will like the product, since they are the ones making financial decisions. We put a lot of focus on how we can make the product useful for the frontline people, though, those closest to the customer and where the customer can get most of the value. If we can give frontline employees simple tools to improve the customer experience, they will have happier customers, and that will translate into better business results. It is also good for the employees who will be rewarded for doing good work. That means everybody will be happier, from the customer to the frontline teams to the executive suite.
TH: It sounds so simple yet so many companies get it wrong. Besides the employees that represent companies in the marketplace, what can you tell companies about getting CX right when it comes to their technical interfaces with customers, like their websites and apps?
DM: In our case, simplicity is what has made HappyOrNot successful. Simplicity is part of our DNA. We have a lot of new ideas but we always want to remember to maintain the simplicity of the product. It must be easy to use. We struggle with those decisions because we know the moment we lose simplicity we start to lose the DNA of HappyOrNot.
Dan’s job as head of product planning requires a lot of listening and digging and gathering. He spends time studying the markets they serve and prioritizing product enhancements. Then, he says, Eeva’s R&D team does their magic. Dan came to HappyOrNot with experience in product planning, sales development, and go-to-market strategy. He spent time with major software and telecommunications companies. Working on global solutions means he’s comfortable working with customers and teams across time zones, speaking in the morning with professionals in Asia whose clocks are seven hours ahead, then later with people in America who are seven or more hours behind.
Eeva’s research and development team comprises “professionals who do their job really well” – software developers, electronics engineers, user-interface designers, and at least one data scientist who applies a mathematician’s mind to their work. She works on figuring out solutions to customer challenges, then how and when to implement the new solutions. Eeva’s experience includes work on early smartphone technology, gaming programs, and artificial intelligence in the healthcare industry.
Tom Hagy is a Philadelphia-based freelance writer and business owner.
Want to jump to the next article in our CX360 series? Read it here: CX360 Leader Insights Part 5 (or, if you missed Part 3, click here)