User research is essential to building products that solve real user problems. It is often a precursor to good design and excellent product development. User research typically comes with some clichés - “it’s so expensive,” “we need a dedicated research team,” or “the people that I work for don’t buy into it.”
If you’ve experienced any of these negative stereotypes, or if research is already a part of your process and you want to arm yourself with a toolkit to execute it even better and clearly communicate its value, this talk is for you! Gabrielle introduces a toolkit to help you inject research into everything you do and share her tips on how to turn constraints into opportunities. She shares stories and learnings from the field and send you off with actionable steps so you can begin developing solutions for the problems that your users actually care about.
1 / 23 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Awesome. Thank you so much for the super warm welcome. I'm very excited to be here, on my birthday. I couldn't think of a better way spend my birthday than to be talking about one of the topics I love the most. I'm gonna talk to you guys about bootstrapping user research.
No budget, no buy in, no team, no problem. So I'm gonna start with what was one of my favorite games as a kid, Pac Man. And I'm gonna ask the audience, has anyone ever wished that they had more information at any point? Yeah. Right?
Even for this conference, there's so many talks going on right now that are so amazing. I just wish I had that extra bit of information for the right one that I should be a part of. Actually, when I start any project or when I'm in a pivotal moment of the project, I feel like I'm in the beginning of a Pacman game.
I have some constraints around me. I have some idea of what I should do, but there's so much choice. There's so many places that I can go, And there's so many risks which are represented here by these ghosts. And there's also this huge reward opportunity, that are the cherries and the strawberries and the extra fruits that are coming along, throughout.
And I just wish I knew where to go. And as a kid, I played Pac Man and I got better at it, by playing, which is the intent of the game. Definitely did not master it, so they did a good job at creating a fun experience for me.
And I used my gut and I used my instinct and I got better at playing it. And I feel like any product people here in the room can relate to making decisions with imperfect information. And that is kind of what we do in this game, and that is what we do when we build products.
But sometimes we just need a north star. We need something that will guide us and help us make the best decision for the user, and that is user research. User research is a word that comes loaded with a ton of assumptions. One of them is it takes so much time.
Just so much time, like you're wasting all this time. I hear from people all the time. Your team needs to go. They need to go go go, like run, run. You don't know what direction you're going, but you're running somewhere with your teeth.
Right? You've been there. The other one is it's so expensive. Like, the tools are expensive. The people are expensive. You're already wasting time. Now you're wasting money. Right? That's another big one that I hear. And when people are finally kind of bought in, they're like, we just don't have a team.
Like, we we can't do it. We don't have the team. The people are not there. So I presented you some of the big problems that come attached to user research, and I'm gonna try to demystify those and try to give you some tools of how I used to solve it, and then finally some best practices, of what I use when I'm doing user research.
But I'm gonna present you with a truth that was true then and is true now. People hate change. They don't like it. Right? For some reason, it's sexy to say that you're like change, that you like to adapt, that you like new things.
I can probably count in my fingers how many people actually like change. Your users will tell you, yeah, it doesn't matter if you change my experience, I'll be happy. They won't. Right? They they don't like it. They like routine and they like things that they're familiar with.
This movie is old, but it's still very relevant. And the thing about user research is that it's kind of new. And before, we used to build by who is the loudest person in the room and or who is the highest ranked person in the room, and it was all about their ideas and all about what they believed.
And now we are turning outside and we're asking the users, what do you need? How can we better fulfill that? And we can't really prove the results before we conduct the research. If we could, we wouldn't have to do research. If I knew the answer, I'd just tell you like, hey, you do x, y and z, and then you have this perfect product.
But we can't do that, and that's mainly the reason why a lot of the people here have a job. So I'm pretty happy about that. But it does mean that we need to go through this process. And it's hard to show something that will be time consuming and expensive, when you can't really tell people what's gonna come out of it.
And that's what I'm gonna try to do today, give you a kit of how to solve these big problems and also share some best practices. So first, I'm gonna introduce myself. So my name is Gabrielle. Oh. I'm so happy. Yay. Oh, I'm so sorry for anyone that missed the beginning.
I can do it again at the break. I'm happy too. Yeah. So my name is Gabrielle Buffrem. I am a product manager at Pivotal Labs. Pivotal Labs is a software consulting company where we help clients all around the world to build better products, and we train their teams so that they don't need us anymore, and they can go and be amazing product people on their own.
I also really love data. I am a very self proclaimed coffee snob, so I'm excited for the lattes and all the things that we're gonna get in the conference. So grab me for a coffee afterwards. And I also really love to travel, so I'm very happy to be here in Edinburgh.
Especially with the fringe going on, it seems like an amazing time to be around. So, yeah, definitely grab me afterwards for questions or anything, and I'm happy to stay in touch with everyone. Cool. So let's get started. As a product manager, we're used I'm used to solving problems all the time.
And I like to solve the hardest problem first. It just gives me confidence that I can do the other things and that they're not as scary. So the hardest problem for me here that we're gonna talk about today is how to get buy in.
Because with buy in, you can get money, and with buy in, you can get a team. So if we solve this problem, we can basically solve everything else. So I'm gonna start with my favorite approach, which is show rather than tell. You see a scale here and you see two very different products.
One, on the very dark side here, is the one that fully embodies user research. And it's the one enterprise product or now actually there are a lot more emerging, which is amazing. But they don't think that they have the ability to suck by being an enterprise product.
They think that they need to provide customers a really good user experience despite it being a top down choice. Right? I'm very happy that my company uses Slack. Not everyone gets to use Slack. Right? Some people are still stuck on email and other products that I'm not gonna mention.
But Slack actually takes user input and user needs into consideration when building products. And it helps you go through the process, which makes it a very, very user centered product. So when you show an example like that, that can be really powerful, and they're doing extremely well.
So that should be very telling for the people that you're trying to convince. Even more telling than showing the good example, is showing the other end of the spectrum, which is, or I wanna say it was, one of Silicon Valley's darkest unicorns, and it's Juicero.
So if you haven't heard of Juicero, I highly encourage you to Google it, Spend some time on YouTube watching the videos. It's pretty great. You can take a break from all the amazing content you're getting. So Juicero wanted to make an amazing juicer.
They made a over four hundred dollars juicer that actually squeezes the juice out of that like astronaut looking component thingy that you put within. It's very overpriced. People were not happy to pay that price, especially when they saw videos of people on YouTube being able to squeeze the juice faster without the machine than with the machine.
So talk about a product that was not tested with users. Talk about a product that did not have user interaction, that was made inside a building and not really gone to the outside world before it was released. It's pretty cool to see the New York Time press releases about Jocero before it was launched and then after.
Really cool timeline, you should check it out. So show rather than tell. That's the first lesson. And a lot of the feedback that I get here from the client PMs that I work with is like, I don't have my own product. Right? Like, how can I show? I've never done this before.
Use other people's products. It's okay. The other piece is involve people you're working with in the research process. So what I do every time I start a new project that we're doing user research is I invite the most reluctant stakeholder, the person that is like, this sucks, to come and join us.
They say no, it's okay. Right? After that, I tell them all this info will be on the cloud and it's available and you can access it here through this very simple link. They don't go there. I I swear to you they don't, and they won't go for you and it's okay.
After that, I go and I add snippets of user research in the presentations that I am giving to these stakeholders. So I add actual videos of people using the product. What I found to work most effectively is the videos of people who hate the product.
That are like, I have a video of this guy that is literally pounding on the computer, just being like extremely angry at what we built. And believe me, someone thought and I thought that it was a good idea. And I was very wrong.
And it was okay because we learned really fast. After we show maybe four or five snippets of someone hating the product, Sometimes include good ones too. Otherwise, they'll be like, what is your team doing? Like, you guys are clearly making terrible decisions. They start actually watching the things. It's impressive.
Like, someone told me, they're like, oh, and they describe moments of it vividly to me. And I was like, wow, you really watch this. Like, this is real. And afterwards, they might start asking you if they can come to the user interviews. So it is a left to right, but read it like Hebrew, right to left.
Because it does start by you showing them snippets of real people using the product for them to get the interest and then give you the buy in in order to do more of it. The other piece is concretely share your findings in a way that your audience understands.
I cannot stress this enough. Like, my desk is a mess. A lot of product people's desk is probably a mess too. It means that you're doing great work. It's okay. The hard piece here is research is not a line. It's a very, very, very fuzzy, complicated, and complex mess that then becomes something more concrete that we can put on the product.
So this is actually a piece that is the most organized one that I found within our pictures because it has like clusters and it has people and it has the real users. But if I showed this to, like, a chief marketing officer, they'd be like, why are you playing with all these colorful things, like drawing stuff?
Like, I don't want any of that. But if I show something that is a hypothesis or an assumption, and if I show if it worked or if it didn't work, or if we actually need more research in order to tell, that is more helpful.
That I found to be very powerful because people can understand if something works or doesn't work. They don't need to understand the behind the scenes that you and your team are going through in order to decide if the future is going to work or not for the users.
So make it understandable for them. This is in my best practices, so I'm gonna talk about this method and give you some tips on how to do that later on. Cool. The other one, and this is the most important one, is have a culture where you're allowed to be wrong.
And I can't stress this enough. Being able to be wrong is imperative for user research. Because if you only wanna be right, don't do it. Because you will find that people don't like your ideas and you need to part ways with that beautiful thing that you and your team had envisioned.
Because you are most likely not the user of your product or you're not every single user. And that's okay because you have them in order to give you feedback and help you out. This really reminds me of being a kid and playing with the science kits that I used to buy a lot.
I've never been someone that actually read the instructions. So I didn't really get the predictable results like, oh, you will put this and the crystal will grow. I would always mix one kit with the other kit and then the crystal would go three times the size and it would be beautiful and sparkly.
And other times it would fail. But it was okay because those moments of delight when I got it right or when I made something work were amazing. So encourage your team to ask the question, how might we do this? And to allow your team to say, I have an assumption and I think it's this, but I might be wrong.
I listened to an amazing talk last year at Women in Product by the chief innovation product manager at Netflix. And Netflix has an amazing culture that I really love. And she described what failure is at Netflix. And I took that to heart and I thought it was fantastic.
She said that failing at Netflix is not learning anything. So if you're conducting experiments and all of your results are inconclusive, that's a failure. Right? Like, you need to change the way you're running those things. You need to change what you're testing for.
But if you are conducting experience and you're learning that you were wrong, that's a huge success. You learned this so quickly. You didn't spend months and months of development in order to learn this. You actually learned this in one experiment or two experiments, and that should be rewarded.
So reward people for learning and experimentation instead of rewarding people for being right. And I know no one person can leave here and go and do this alone, but I feel like it takes one person to start for everyone else to follow. So bring back that mindset with you.
The other piece I'm gonna talk about is how to build a team. And the first one is kind of sad because, and it isn't true, I would say, you are the team, right? Leave this conference and be like, hey, I'm doing this. Like I am going to be that person that is going to get out of the building, out of my comfort zone and I'm going to meet real people that are going to use this product.
I heard a really cool story last night that a innovation lab actually built a street and hired people to walk around. Don't do that. Go to the actual street, it's free. You know, you can just go. People are there, you don't need to hire anyone, it's amazing.
I feel like as product people, we are always so tempted to stay in and be present for our team and be there for our engineers and be there for any requests that they might have. But explain to people that you actually need to leave in order to ensure that they are doing the right thing and that you are providing them with the most useful information for them to build their product.
The other piece is a little more encouraging, and it might be a little bit of a shock for some people. And it is recruit your customers to be your researchers. So this is something that I did prior to joining Pivotal at the company that I used to at before.
I recruited some of our customers to do research for us. And they were volunteers, I didn't pay them, and they were just excited for the opportunity to learn how to conduct research and to be a part of a real company project since they were all teenagers.
So what did I do? I recruited them in a platform that they already used. At the time, it was Facebook. They were all on Facebook. I was on Facebook all the time. My colleagues were like, what are you doing? What type of work involves being on Facebook eighty percent of the time?
And it was finding these people, finding people that wanted to help us out. I then built a community and a way for them to talk to each other and to talk to me. And the way I did that was very simple, and I used Facebook groups.
I just created a Facebook group, I posted stuff there, they posted stuff there. It was free, I didn't need a budget for it, it was very easy. And the core piece is my researchers were already on Facebook. So it wasn't like I was asking them to leave the platform that they already used in order to go somewhere else.
They were already present and that they were already engaged. So Facebook groups is not the right thing for everyone. I almost don't even know if I should have put it on the slide, but it worked for me and it might work for you.
So figure out where your people are and help them. And the other piece is you shouldn't expect that all your customers are perfect user researchers. They're they're not. Right? It's hard and it's complicated. So give them the resources to be successful. And what I did, I'm gonna go through kind of like some of my favorite resources right after this, but I used Hangouts On Air, which is very simple service from Google, also free.
It conducts a meeting. I couldn't expect everyone to be free because they had school and jobs and a life. So some people were free and I polled them to see who could join and the other people would watch it on YouTube and it was very easy and very cool.
You can probably find it, I never fully removed everything from there. But it was just me explaining each method that they had to do and I did have a gamification system in place and people got pretty cool things out of it and that will come all in the currency bit that's coming next.
Now, how do you train your team? How do you train yourself and how do you train other people? Here are some of my favorite resources. There are other amazing resources when you Google user research and how to get into it. One of the two that I love the most is IDEO org and Acumen.
They actually partner to give a free design thinking and user research course online. It's amazing. I've taken it. I highly recommend it. They want people from NGOs all across the world to be able to benefit from this, but they're opening up to everyone.
The other one is IDOU, so they're actually doing a research course in different steps of the way. I've taken two of them, they're really great. You pay for it, but you can do the free one and see if you need anything else and then realize if it's good for you or not.
And the other one is a book recommendation, it's called Just Enough Research. It's amazing. It gives you the basics and then you can build on top of that afterwards. If you don't want to read the book, she has awesome talks online. You can just watch that on your way home too.
Download it from YouTube. Very easy. Now we go into the money part. And every PM in the room knows that if you're not thinking about money, no one else is. How to deal with no budget? Having a budget is great. It's amazing. It allows you to have tools, it allows you to buy services, it allows you to recruit the right users, it also allows you to take your team to lunch and people are very happy when they have good food.
So how do you deal with not having that? I encourage you to think creatively and think about what other currencies can you get access to, right? The first one is master of none telling us, rent a swag. And I have printed swag. I have sent swag to be printed.
I've sent people Christmas cards. Like, think about ways that you can reward people for being engaged with you and for helping you out. People love swag. I'm sure people here brought like extra space in their suitcase to take swag home. I did. Right?
I love it. I have a ton of swag at home and it's great. Sometimes I use it, sometimes I don't, but it just makes you feel good that someone sent you something special or someone made that available. In terms of making it available, beta.
Beta is amazing because you're killing two birds with one stone. Betas normally are exclusive and they're only for a select group of users. So whenever you invite people to your beta, they feel special. They're like, wow, they want me to help or they want me to give my feedback and my input.
So you're making them feel special by giving them something that they wouldn't have access to otherwise and you're also getting feedback on your product. It's amazing. You win, they win, everyone's happy. The other piece and it's one that I really love is having ambassador programs.
Ambassador programs are not good for every business. I'm very aware of that. And I feel like it's important to highlight that ambassadors in any business are not every single user. We all dream that our users will be a hundred and fifty percent engaged and will be promoting us everywhere and will be using the product even in their sleep.
They're not. Right? It's okay. We made peace with that, but there might be some people that aren't. And one good example that I find of an amazing ambassador program is TheSkimm. They are a online mail service that sends you news that is very sassy and cool and it actually feels good when you read it, even though some of the stuff is sad that is inside, you feel a little better by reading it in the morning.
And they're growing their business and a huge part of growth is their ambassador program because they actually hire a ton from it because they know these people love the SCIM and they get a ton of new users from their ambassadors. So having an ambassador program and having part of the ambassador program be being a researcher can be a really great trade off for them and for you.
The other piece is show current results without a budget and potential upside you could reach by having one. People love graphs, managers love graphs. I'm sure you can find something that will speak to your audience. I feel like for me, if I explained, hey, I was able to connect with four users without having a budget to recruit.
If I did have a budget, I'd be able to connect with twenty four. Those twenty four will be of the specific demographic that we're looking to test in. These are the benefits. That would be a very compelling case for management, but if you don't do anything and you ask for money, it becomes very hard to prove.
If you do a little bit and then you say how much more you could have done, I always found that that works best. And now, on to the best practices. So my first one is have a map. We've talked about how research is very fuzzy and complex and difficult.
And I will say research can go on forever. Like I've never stopped doing research for products that I'm building right now And I never hoped to. I always want to continue. But it's very helpful to be able to point to a piece and say, now we're doing problem discovery and we want to time box this activity to three days.
And in these three days, we're gonna run these, this, and this, and this is the result we're gonna get out of it. It's very helpful to tell someone that it's not within your team that you have a plan and that you know where you're going.
It's also something that we use at Pivotal a lot. It's called discovery and framing. It's a caveat to the double diamond. If you're not familiar with the double diamond, I would highly encourage looking that up. It's a super great tool in order to frame your research and to give you a map of the mind of where you need to go.
I would be very specific that research does not stop after the double diamond. It is just the beginning. You're doing research here to figure out what you should build first. You will build something else after that, and for that you should continue doing research.
But by doing the double diamond, you should be able to feed your development team with enough stuff that they can start building towards that MVP or towards that next feature. After that comes test hypothesis, not interactions. We have here an example. Users can click on the project on the home page.
I don't care if they can click. They can click, they can not click, literally it does not matter to me. What matters is that it's a good or bad entry point. Do they find relevant having projects as their entry point or do they not?
That should be what you're testing. You should not test interactions, you should test the hypothesis that you're making behind the product that you're building. To test those, you're testing, you're doing all these things. The next important piece is to know how to communicate the results in a way your audience understands, kind of back to that piece of getting people involved and getting buy in.
And these are my favorite ways. So one of them is called red yellow green and the other one is called keep, kick, change. So red yellow green is as simple as it sounds. It's like a light, right? You're like stop on the light.
Red means no, failed, it didn't work. And a good example is like, I don't understand what a project is, I'll just pick a random one. If someone tells you that, please no, right? Let's do something else. Yellow is inconclusive. So someone maybe looked confused but still clicked on the right project.
You're not fully sure if they got it or not and you might want to run some extra tests in order to prove it or disprove it. Success might be someone saying to you like, oh yeah, I get it, this is cloud, I'm gonna click on the cloud and I'm gonna be directed to that.
So when you ask people to speak out loud, getting those quotes, getting that interaction with people is very important and writing them down, right? Like writing down the proof so that those people that have really loud voices in the room can tell you like oh, this is not true.
You're like well John, Bob and Claire seem to think it is. You have like real evidence to back up your opinions. Afterwards, after doing this, I go straight to keep, kick, change. Keep is concept works, the hypothesis is correct, maybe we need some minor UI changes.
Right? And our design team can go and run with that. Kick is it does not work, kick it away. Change is, it works and it needs some small changes, maybe those are more like UX changes that you need to do. And here we decided to kick, user don't understand what it is, it's not intuitive, let's find another entry point.
So here is kind of my two go tos in order to how to communicate with people and I do put them in slide decks and I show them to our stakeholders when they do have questions and I found it to be very powerful as a way to explain the why behind the decisions that we're making.
It's also something that you can track, so if someone joins the team later on and they're like, Oh, why did we do this? You have a concrete artifact that you can point to from the past that has the reasoning. And now the key takeaways from the talk, and this is the like, oh, I'll take one picture of this and then all of it will be in my head, synced in, hopefully.
So the core tips of how to get buy in are explain it by showing rather than telling. If you just tell people that it's important, it's way less likely that they'll believe it. Involve people, especially the most reluctant ones, in the process. They might surprise you and they might change their minds, even though it's hard.
Share your evidence and share your results in a way your audience understands. Not everyone is in your team, not everyone needs to like post its, it's okay, some people are just not made this way. The other one is allow people to be wrong and develop a culture of psychological safety so that people can feel like they don't need to be right all the time and they can learn through the process and learn through building the product.
Building the team, in the beginning, it's you and it's okay. I've been a team of one, and then I found friends, and they're there. Recruit your customers to be your researchers. Try to be creative about budget, and always show to the best predictability as possible what you could achieve if you did have more money or what you're gonna do with this money based on what you did already.
And the go tos in user research for me are testing hypotheses and not interactions, having a map that can lead you through this very sometimes complex and sometimes light at the end of the tunnel journey, the red yellow green as a way to show what works, what is inconclusive and what doesn't work, and having a clear framework to communicate what you're going to keep, what you're going to kick, and what you're going to change in the design.
