Madelen Arnesdotter, Sales and Account Management, Brisk.io
Presentation at SlideShare: Get the team to understand the problem through the eyes of users
April 23, 2015
Do we have any Nevada person here? People that build stuff; engineers? Do we have any Customer Success people? People that interact with customers all day?
All of us have one thing in common which is that we are trying to solve a problem. To solve a problem you need to understand it. You can’t build a good solution if you don’t understand the problem. I’ve noticed that the people that build the product, they’re not the ones that actually talk to the customers. Today I am going to share a method that I and my team use to understand our customers better.
I’ve worked at two startups. I used to work at FOAP. Today I work at Brisk. I’ve always had customer facing roles where I’ve been interacting with customers and people all day. Today I work in marketing too.
The issue is that you don’t have a context when you are about build a product. So you have to go to the people who are actually talking to the customer, or the potential customers. A lot of information might disappear on the way.
The ideal thing would be to make the developers talk to the customers. But it would be stressful. Sometimes the developers might be keen on taking calls. It would cost a lot of time. I heard about a startup that had a red phone on their developer’s desk. When it rang they had to pick it up. They understood the value of everyone understanding the problem, and understand their customers.
The solution is to talk to the customers and get everyone to listen. I do that by recording an internal podcast. How do I do that? It’s not illegal. I am not recording them without them knowing it. This is what I do. As I am always in contact with people, I look for ‘social signals’ and people who are open to communicate. Then I ask them if I can write a blog post about them or about their company, which is publicity and that’s always good. It’s also good for that person’s ego that you asked them, because they get to be the center of attention. Then I make sure to research and plan. I go to their LinkedIn profile to see if they worked with a competitor before this or have they changed roles. I look for what do they say that they do. I also make sure to ask the developers whether they have any questions or anything that they’d like to ask. Being prepared is a good way to show them that you are a professional and you’ve been investing some time in this, before you are actually going to talk to them.
During the call, I record them and I ask them first. I tell them there’s nothing to worry since they’ll get to review the post before it goes live. That makes people feel like they’re in control and they can say whatever they want, because they’ll get the chance to edit it later.
When you have done your research, start asking them. Start digging. Don’t lead them too much. They know the really good stuff about their company. That’s not what’s on their profile or company website. Ask questions. Be annoying. Sometimes when it gets quite for a couple of seconds—that’s when people say really interesting stuff, because it gets a bit uncomfortable. Search for conflicts, or how it makes them feel. And once you are in the same area, tell them about your experiences so that they know that you can relate; in order to bond and have a very nice conversation. The good thing about that is that it’s not a sales conversation anymore. You are not expecting anything from them.
Once it’s ready, I trim it, I cutoff the ‘Weather talk’. And I publish it as a podcast for my team. Suddenly they can listen to it when they are on their bikes or at the gym. What happens is that they get to be a part of these previous calls. But they don’t have to be actually be there or sit there. And they can listen to it again repeatedly, like when watching a movie, you start noticing the good stuff.
Afterwards, you can deep and write this really long heavy ones, or you can just write a top list. Like; ‘Five ways of being a great sales leader’. If you want to make it a quick and easy blogpost, just have those questions before so you can get the stuff for your blog and then focus on understanding them afterwards.
Transcribe, but do not do it yourself, because it’s super time-consuming and boring. Write the post, get an okay. Don’t forget to get an okay. I almost published it, because I was so satisfied. I wanted to get it out. Publish them and mention them on Twitter and give them some credit, because they spent an hour with you.
These are the tools that we use. We go a bit deeper with a blogpost. I ask them for an interview. We schedule a call for the interview. I use eCam to record it. It’s super easy to use. I trim it with a QuickTime player; the ones that you get on your Mac when you buy it. I use JustCast for the podcast. It’s only $5/month. I am not a techy person, but you just put the interview in a folder in my Dropbox and I have a link on my phone. It just shows up. It’s super easy to use. I even think that the first three episodes are for free. Then we use a transcription company which is $1/min. An interview is often between 40 to 60 minutes.
So I send it away and they give it to me. When I get the transcription, I send it to a copywriter. I create a Google doc and share back and forth on it. At the end I get a really nice blog post that I publish.
What do we get?
We get a nice blog post. Once you’ve made one, you can show this to the next person, because when they see that it’s real, it gets much easier to go on and get people to jump on board. The greatest win is that all of takes part of the customer interaction and we learn so much from these interviews. Because you can have the latest tools and the best developers, but if you are not understanding the real problem, you can build something pretty and super nice, but no one will ever buy it.