Are you more of a left brain or right brain thinker?
If you don't know what I'm talking about, left brain folks tend to be more analytical and metric focused, whereas right brain folks are more likely to use storytelling to make sense of the world.
So when we think about qualitative and quantitative research, you can probably guess which types tend to gravitate to which research methods.
And that's great, we need both after all, but as it turns out, putting the two together is a lot easier said than done.
How do you blend numbers and stories to paint an accurate picture?
And regardless of research method, how do you ensure that your data is any good?
My guest today is the amazing Laura Klein, principal at User's Know and the author of Build Better Products and UX for Lean Startups.
Over the past 20 years, Laura has worked with a lot of product teams and watched many of them stumble over the same challenges when it comes to conducting and applying user research.
She's about to share some of her most useful observations and advice for product teams, particularly later in the episode when we get into the key role of segmentation and research.
You're going to need both sides of your brain for this one.
So let's jump in. Welcome back to the Product Manager podcast.
Laura, thank you so much for making time in your schedule to talk to us.
Thanks so much for having me.
We'll start off talking a little bit about yourself and how you came to found User's Know.
Yes. So as you said, I'm a UX and product person.
I'm a recovering engineer.
I have been around tech since the 90s.
So it's been a while I've done a whole bunch of different things.
I originally founded User's Know back in early 2010s.
I actually don't remember the date I used to know for sure.
I learned how to do design at a really great boutique design agency where we would do design and research for clients.
I learned a huge amount there.
It was great. This was after I had been an engineer for quite some time at startups mostly.
I finally left, honestly, because I wanted the ability to fire my clients.
That is the 100 % truth.
When you work for an agency, I always joke that when you work for an agency, you've got to make a lot of people happy.
You've got to make your bosses happy.
You've got to make your clients happy.
And you also, ideally, if you're a UX designer, have to make your clients' customers happy.
And weirdly, sometimes those things are in conflict.
And what I realized was that I did much better when I could work with clients who were very much on the same page with me about how we were going to do the work.
And I've really enjoyed working with people who buy into my way of working.
Not that it's particularly didactic, but I have a specific way of doing things.
And if you're on board with it, then we get along great and do a lot of good work together.
I come from an agency background myself, and I can very much relate to things just work so much better if it's a fit.
You can't force a fit sometimes.
You know, like, oh, you want this other thing that I didn't negotiate with you.
And I'm not sure I can do that for you.
And like, half the time, when I actually do biz dev for users now, which is not always because sometimes I have full time jobs, or sometimes I'm fully booked.
But when I'm actually doing biz dev, I spend a lot of time telling people, oh, I don't do that.
You want to talk to so and so, you know, somebody that I know who does that thing, you're just going to be much happier with them because they're better at it than I am.
And so I spend about half my time turning people down, because there's only one of you and you only need you know, a couple of projects.
You want to find the ones that like really like, oh, that's a thing I could really do well, right?
Yeah, I think that's almost like a marker of success to to be in a position where you are able to really choose the projects that are going to get you and your client where you both want to be.
So I very much respect that.
So today, we're going to be focusing on combining qualitative and quantitative research to make better decisions in a product context.
So what can you tell me from your own experience?
What do you see teams struggling with in terms of combining those two disciplines?
All of it. So this is one of the ways in which I work that is very specific.
I really think so. Here's the problem.
I see people struggle weirdly with both sides of this.
A lot of folks really have a hard time with doing qualitative user research.
A lot of folks have a really hard time between quantitative user research.
And I mean, when it comes down to combining the two, you're kind of looking for your unicorn hunting, right?
It's just a really hard thing to do, because you've got to get so much right.
And yeah, I'm not kidding.
Like they struggle with all of that.
A lot of people don't know how to do good qualitative research.
They don't know when to do it.
They don't know when to hire all of the wonderful professionals who are out there who do this for a living and who are fantastic at it and who really know what they're doing.
On the quantitative side, you know, math is hard, right?
It's not just is like the math hard and statistics are not intuitive for anybody, really.
And beyond that, it's hard to instrument your product so that you can get the right data.
So many companies collect all the data, but somehow none of it is correct.
It's just a mess on both sides of it.
And then when you take sort of badly done qualitative research that maybe didn't address the real problems or didn't have a good question that they weren't fundamentally answering, and then you combine that with data that's sort of haphazardly collected and maybe not even correct.
And then you try to combine the two, you get what you get.
And none of it goes.
And this is not everybody.
That's right. Worst case scenario.
I see often companies that are, you know, like maybe they've got a really great qualitative research team, and they're great at collecting that information, maybe not so good at integrating it into the product decision making.
Or you see product managers sometimes who are so focused on the data that they're not looking at the qualitative side of things at all.
So they don't really understand why anything's happening.
They're just looking at numbers all day.
But they're like, well, maybe it's this, maybe it's this other thing, maybe it's the other thing.
That's a really common pattern is the quote data driven product manager, which, look, I'm all for data informed product decision making.
But the data don't inform you about why anything's happening.
They just tell you what is happening.
And sometimes they don't even do a great job of that.
So yeah, all of it's hard, which is why you shouldn't bother and you I'm sorry.
Yeah, absolutely not the takeaway.
That's absolutely not the absolute takeaway is not give up.
No, we forge on the show must go on.
Yes, we acknowledge that what we are doing is difficult.
And we give ourselves the space to learn new things.
And we admit that we might not know it.
And I say I've learned stuff all the time about both sides of this.
And, you know, we work with experts who are good at each side of it and do the best we can.
I'm excited to dig into that a little bit and a little bit about also some of the ways that we can ensure that the data that we are collecting is a little bit more reliable or provide some better source of insight for what we're trying to achieve.
But in the meantime, let's make the leap in assumption that we have good quality data on the qualitative and quantitative research side just for the purpose of this example.
Yeah, we're great at both.
Yeah. Yeah, yeah. Well, imagine we have got the best of the best on the job.
What are some of the ways that we can start to bring those two types of research together in a product decision making context?
Right. So let's say that you've got like, we won't even say that we have great data.
We'll say that we have the people and the processes in place that we can go out and get the great data because the first step is really trying to figure out what question you're trying to answer.
That's just as hard as the rest of it.
A lot of people have, like I said, a lot of sort of like, oh, we have dashboards in place.
We have, we do, you know, usability testing all the time.
And we do all these things.
It's like, okay, but you're trying to make a decision, right?
Like you're trying to make a specific decision.
Do we want to do X?
What new feature do we want to build next?
What is my priority?
Whatever. All the kinds of decisions that we make every single day as product folks.
Great. Which one are you trying to make right now?
How should we improve the activation on this particular feature?
Or how can we improve acquisition?
Or how can we keep people from churning out after X months?
These are the types of questions that often we need to ask ourselves, right?
Sometimes we have to ask ourselves, is this feature or this feature, right?
Which is more likely to do the thing that I must need to do, which again, kind of comes back to that, what are my metrics and what the hell am I trying to do with them?
So you got to start with a good question that can be answered.
And it can't be like, how much would somebody pay for that?
Well, I mean, it can be, but that's actually a super hard question to answer in either sense.
So that's a tricky one.
But sometimes you have to answer that one too.
But you really have to narrow it down.
What is the thing I'm trying to answer?
And then you have to look at, okay, great.
Like I said, the quantitative data are going to tell you what is currently going on with your product.
And when I talk about quantitative data, I'm not necessarily talking about like market research, although that can also be something that you want to bring into it at sort of maybe the earlier stages.
But I'm talking specifically about analytics metrics that you know, things that you're measuring on your product.
So for example, the quantitative data often don't do a great job of telling you anything when you are pre product, you don't have a thing out there, you don't have any quantitative data.
Or you if you don't have a lot of users yet, you may not have enough quantitative data.
So you got to kind of think about when you're going to use that.
But fundamentally, all it's going to tell you is, what are people doing?
What are people clicking on?
What are people buying?
If they click on this, do they go on to buy this other thing?
If they saw this, you know, it tells you all sorts of stuff about why qualitative data.
And we're talking here about user research and or usability testing, which are two different things.
Generally speaking, when user research is kind of the whole thing, but user research, really understanding your users, what their mental models are, what their context is, what they're trying to do, what kinds of problems they have in general, and with your product, all these sorts of things, that's
going to help you understand why the things that are happening are happening.
That's it. Will I tell you what is going on?
In fact, considering the fact that qualitative research is often done with much smaller sets of people, and you know, this is it's an iterative process.
It's not like you do five and you're done forever.
But you know, you might be making some decisions based on talking to five people.
But you know, you're talking to some people and then you're doing another round and you're talking to more people.
So you're talking to people constantly.
But you can only talk to so many people.
And you're talking to over a long period of time.
And it is entirely possible that you can talk to people and you can get a really good vision of who they are and what they're doing.
But like, you are never going to get as good a picture of what is going on just by talking to people.
But you will understand why.
And the examples here are things like let's say that you have a checkout process, we'll just go with something real easy and sort of something we've all done, something we may have all built, right?
Like, this is, this is a thing that is very common.
Everybody on here has been through a checkout process on a digital product of some sort, they generally tend to be fairly linear, they have several steps, there is some information that the company absolutely needs to get from you.
And if you have your data instrumented correctly, you can see where people are falling out of that process.
And I guarantee you, somebody has fallen out of that process.
We call it a funnel.
It's more like a sieve, right?
Everyone gets to the end.
Best case scenario, it's the funnel.
Actual case scenario, people are falling out constantly.
Shitty funnel. So this is happening.
Data will tell you exactly where they're falling on.
That's great. Then what I see a lot of product managers do is they say, everybody's falling out at this part where they have to put in their credit card information, and then they start solutionizing or ideating.
Oh, we should do this.
We should make this change.
We should make this easier to see.
We should change the, okay.
Or you could just watch some people use the damn checkout process and try to understand is there something obvious that's happening here, because it may be a lot of things.
I've seen dozens of different things that make people fall out of checkout processes or onboarding processes or anything, data collection.
I have seen people fall out for all kinds of reasons.
And the important thing, the reason that this matters, the reason that the why matters is because the correct solution to that problem depends on what the damn problem is.
And the problem isn't people are falling out.
I mean, that's your problem.
Their problem is, I didn't understand this thing.
Or I've seen this, there was a bug that prevented me from doing this thing that if you don't see it, or you don't know that it exists, you just will never fix it.
You'll never fix the checkout problem.
Or you don't have the right payment methods or a dozen other things.
And it's sort of shocking when you just watch something and you're like, Oh, it's that little thing.
I can just fix that.
I've had engineers watching me run user research sessions or usability testing, and they have fixed the bug that was causing the problem during the test and pushed it to production.
Like we caught a problem.
It was obviously a problem.
It was obviously a bug.
The engineer watching it literally, their laptop and their lap just fixed it.
We came back to it later.
It was funny, because we came back to it later in the session.
And the person was like, Oh, I thought this was broken.
I was like, so did I.
And I turned her out and the engineers like, okay, just like kind of nod, kind of nod at me and gave me a little thumbs up.
And I'm like, well, I guess it's not a problem anymore.
So I'm just saying, this is a good example of not just understanding what is happening.
And then jumping to like a whole bunch of ideas about how to solve it, but figuring out actually why it's happening.
And then maybe there's this like very simple solution for it.
And moving on with your life and moving on to more important problems.
What do you think is preventing us from reaching for that solution first, rather than solutionizing?
Why is that not the go to in your view?
Qualitative research is hard.
It is often seen as time consuming.
And in fact, it can be time consuming.
In some organizations, it is just much harder to do than others, right?
If you're in an enterprise organization where you are very limited in the number of sources you're even allowed to talk to, or it's just very hard to recruit people, or you don't have a solid research ops process set up that helps you to recruit folks.
It can be a lot of work.
It can be reasonably easy if you already have things set up so that you can spin up the right kind of research at the right time.
Some people just don't have that expertise.
They don't feel comfortable going out and talking to people.
And also, ideating is easy and fun to do.
And you can just do it in a room.
And it's just a very human nature kind of thing.
I can't tell you how many times I can have conversations with people about anything.
No products, just anything.
What do you want for dinner?
Oh, I don't know. We'll just start talking about different kinds of foods.
You're not sitting there thinking like, okay, well, you don't have a whole process for figuring it out.
Human brains, I think, are kind of meant for...
They're kind of perfect for just coming up with ideas, right?
Ideas. Fun. Easy. Not always great.
And not always the right ones.
That sort of a thing.
It's just also, I think sometimes a lot of product folks have very strong opinions about what is wrong with their product, right?
We all know the things that we make are not perfect.
And we may have very strong opinions that it is very easy to get caught up into this.
Well, I knew that this was a problem because of blah, blah, blah.
And so I'm going to go and solve this problem that I know exists, even if it maybe isn't technically related to the problem that you're running into.
I see that a lot too, right?
Folks are like, well, but I want to add AI.
So all of the problems are that we don't have enough AI.
And I mean, I... Sorry, I'm sorry.
I couldn't tell you right now that your problem is not that you don't have enough AI.
Say it louder for the people in the back.
I could do a whole other episode on that.
No, me too. There are problems that you could certainly solve with AI.
Some of them you might even solve better with AI.
Who knows? But the problem is not that you don't have...
I always joke that like your problem is not that the product doesn't have enough features.
I'm serious to that.
Yeah. And definitely not that it doesn't have an AI feature.
Yeah. It doesn't have a specific feature.
Yeah. Your problem is that it doesn't solve the user's problems in a way that is useful and valuable to them.
Yes. I need a tattoo of that.
Maybe just get an embroidered on a pillow.
It's a little long.
It doesn't really flow on the body.
Anyway, let's talk a little bit about some of the different situations in which it's appropriate to apply one versus the other.
So qualitative versus quantitative.
I think that's a really good succinct example that you've given about how one informs the other.
Obviously there are contexts in which one is more valuable than the other.
So let's talk a little bit about some of the outliers.
Okay. Some of the things that you need to remember are sometimes one or the other is absolutely not available to you, in which case you do the best with what you got.
Like I said, sometimes it is very hard to get qualitative data from the right people in certain kinds of environments, often enterprise.
And enterprise is fascinating because you have multiple types of users, right?
Often you have the buyer and the customer who are wildly different.
And have entirely different needs and desires.
And so it might be very much easier to get input from one or the other.
And that's just, you know, don't get me started on the administrators.
Although I've done a lot of research with them and it's extremely useful, but they're hard to get.
So sometimes it's just very hard to get that, but still totally worth it.
And in that case, my recommendation is get a process in place that helps you find those folks.
Quantitative data, once again, enterprise is a good example.
Sometimes you just don't have enough, right?
Like quantitative data, especially if you're talking about quantitative data in terms of A -B testing, which I often talk about and think is incredibly useful in certain circumstances and not the way most people use it.
But A -B testing is great if you have enough people to just be able to see the difference.
But if like, if you're early in a direct to consumer market, or you have too many different types of segments to really understand the difference, or you're in some kind of enterprise organization where you just don't have that many users, you're just never going to get that data.
You can't. That is not an option for you.
I'm sorry, you are going to have to do qualitative and do your best guess.
I'm so curious, how do we determine the sample size that we need before we proceed with figuring out what our goals are in terms of getting that kind of quantity?
Okay, on the data side of things, I'm going to tell you that you need to talk to an actual data scientist, because I wasn't kidding, math is hard.
And this particular type of math is incredibly hard.
And I've seen people screw it up a lot.
And there are all kinds of weird problems that you don't expect to happen.
Like the peaking problem, that's P -E -E -K -I -N -G, where you're not supposed to like look at the data before it's done.
Anyway, this whole thing, there's tons of information out there.
So I'm not the one to explain that math to you.
And it is too varied.
And it depends too much on the number of, like there's the number of people that you need in each branch of an A -B test.
There's also the question of, there's variance, that's something that just, we run into this problem a lot, where if you are in a situation where you can have massive outliers in your data set, like if you have whales, if you have people who spend tens of thousands of dollars, but like most people spend
a dollar, that's very easily going to throw off your A -B data sets if you need to start looking at things like that.
So there's all kinds of different variables that you need to look at to get your data right, which is why I say most people suck at it, because it's hard.
Then you need experts doing that.
Qualitative research, I also recommend that you get experts to do it, because it's also hard, but in a very different way.
I always like to say, I'm qualitative for sample size.
Sample size, you're not looking for statistical significance.
That's just not a thing that you're going to get.
And people who are like, oh, we did a statistically significant qualitative.
I'm like, no, you didn't.
Come on. Now, what you're looking for is you are looking for patterns that repeat and are predictable, which is why there was the old study that's been around, I think since I started doing research back in the 90s that said something like, you're going to see most of your problems in five people, but I
mean, okay, sure. That's very much about usability testing specifically.
That is finding barriers in a particular interface for a product.
It makes a lot of assumptions about everybody uses the product the same way.
So that might actually be true for something like a checkout flow that is only in one country and only has a couple of different types of users.
Yeah, you might be able to find a lot of your usability problems in four or five people.
Hell, I've found that bug that we talked about earlier in one person.
Like, oh, if that's happening for that person, that's probably happening for a lot of people.
We should just fix that.
And that was true. So you can find certain things like that very easily, very quickly.
But you often have to talk to folks until you start being able to predict the patterns that you're going to see.
So one of the things I like to do is I like to do sort of continual synthesis of the data.
So as we talk to somebody, we then go back and we start synthesizing, okay, what were the takeaways?
What were the observations?
What were the behaviors of this person?
What were their needs?
What were their problems?
What were their goals?
That kind of thing.
And then continually sort of building that up until I can say, oh, it's this kind of person who's coming in.
I think they're probably in this group, whether you use personas or org -sonas or whatever, you say, okay, this kind of person is coming in.
I predict that they're probably going to do things this way and have these problems.
And then if you're right, you're kind of like, okay, I'm starting to see the patterns here.
And like I said, qualitative should just be an ongoing thing.
You should just always be talking to folks.
So you don't need to worry too much about sample size if you're seeing...
If you see a few people really struggle with something, they're probably not the only three people in the world who had that problem.
You probably didn't get uniquely stupid users.
If you did, then that's an interesting thing because maybe you should look at your screening process.
Or I don't know, maybe those are your users.
But they're not. Generally when you bring people in to talk to them about stuff, you see the same stuff pretty quickly over and over.
Or if you don't and you're seeing wildly different things, you may be dealing with a problem where you have not properly segmented your research subjects.
So not everybody uses products for the same thing.
Not everybody uses products the same way.
And if you're talking to power users versus brand new users, you're probably going to get different issues.
If you're talking to people who only buy in a particular way or if you're talking to people who buy wholesale versus people who buy just for their families, you're going to see different behaviors and they're probably going to have different needs.
So if you're seeing wildly divergent needs from all these folks, maybe you need to figure out why they're different.
Are they actually in different groups?
Yeah. And I'm so glad that you brought up segmenting.
This is something that gets overlooked often when we're looking at developing a data set that actually we can make decisions based on.
So what are some of the pieces of advice that you might offer?
If we're going into a research process and we know whether it's qualitative or quantitative, that segmenting is going to be a major factor.
How do we kind of approach that proactively?
Yeah, segmentation is almost always a big deal.
But once again, oh, God, I'm going to say it.
I apologize. I'm going to be a UX designer.
It depends. I won't stop there.
Here's what it depends on.
A lot of different factors.
Some of them, for example, let's talk about an AI feature that I once saw implemented.
It was a product that helped job recruiters do outreach to potential job seekers.
So I'm sorry, but whenever you get that outreach on whatever platform you're on, it says, hey, we saw your resume and thought you might be interested in X.
And so it turns out, and this is not going to surprise any of you, turns out a lot of people are really bad at writing those emails.
Even people who do it professionally, some of them kind of suck at it.
Those emails are kind of hard to write.
And so kind of a large percentage of people are bad at it, especially people who don't do it all the time.
People who are looking for like your hiring manager, maybe looking for one or two people, you haven't really thought about like, how do I reach out to this person and say, hey, are you interested in coming in and talking to me?
So the company decided to do some AI magic, sprinkle AI on it to help people write better outreach emails.
And they did. And it's one of the uses for AI is to sort of summarize a topic and write a better email.
And they let you sort of say, oh, you want to make it more chatty, or you want to make it more formal, or whatever.
So they kind of let you do that.
It turned out overall, really helpful.
It turned out that the emails that the AI was writing, like it helped bring in all of the information when the job posting that was important.
And it helped just make it a little clearer and helped make it feel a little less spammy.
Overall, great, improved things, got more responses.
Here's the problem.
There is a small group, I assume there still is, I don't know, there was a small group of people who use this product, who were truly experts at this.
This is all they did.
They just wrote those outreach emails, they A -B tested them themselves.
They had corporate standards that they had to follow.
These are people, imagine like a really professional recruiter who all they do all day, send these emails.
They had teams of data scientists on their side, figuring out which of these are doing the best, right?
Hey, guess what? The AI didn't help them.
In fact, the AI could potentially interfere with their flow.
They definitely didn't want something rewriting a template that met their corporate standards, that had all of the legal information that they had to require, that they had A -B tested, they did not want that replaced, they wanted to use their thing.
And of course, those are the people who used the product the most and who were the most likely to pay for it.
So here you've got a situation where you've got a huge group of people who don't pay you very much money, and a small group of people who pay you a lot of money.
And now you need to decide, how are you going to deal with this?
Well, I mean, obviously the answer is give people the option to do it, but don't require it.
But if you're only looking at the data and you're saying, oh, but people, I'm waving my hands about vaguely, people, generally people, all of our people did better with the AI.
No, the majority of your people did better with the AI.
The small percentage of people who actually pay you the most money did worse with it.
So no, we are not forcing this on everybody.
This is not a thing that everybody needs to have.
So just keeping that in mind, that you can have very different groups of people and some groups of people, I'm sorry, are more important to your company than other groups of people in terms of their behavior, right?
Yeah, this is such a very good example of how segmenting, it's not even just about who you're segmenting, who your segments are, but the role that they play in their overall business value and the strategy of the product and end.
So I'm glad that you brought that up, because this is something that I think, first of all, I would love for all of us to be taking this into account when we're integrating AI features.
It relates to all features, but yes, AI especially.
It's such a bone to pick with it.
But anyway, I digress.
So because we are kind of coming to a close here with our time, I did want to talk a little bit about how we can have fun in the research process, because I feel like research, it gets pegged as this dry or, you know, it's like a time sucky kind of thing, but there's just so much insight.
And I think that there's so much value in the ability to talk to people and get insights, but also a lot of fun involved in that.
And I think that's something that you'd spoken to as well.
What is the most fun that you've had on a research project?
So sometimes they turn into arts and crafts, which if you're like me is kind of just an enjoyable thing.
Here's the thing, not everybody is like me and adores things like Excel spreadsheets and pivot tables and data.
So I get that and I'm not going to try to convince you that those are fun, even though, you know, they're fun for me.
So I like that side of the data.
That part of it is fun.
The qualitative side can legitimately be really creative.
So if you're a creative kind of person, finding creative, interesting ways to answer problems is very cool.
I can't tell you how often I have done things like, oh, if you're working on like in person stuff, right?
There's a really fun sort of service design exercise for people who design airports, right?
And they will sometimes or hospitals, hospitals is actually a really good example, they will sometimes set up a fake hospital, right?
Because you don't necessarily want to go in and start messing with an actual hospital where there are people dying.
Like that's frowned upon.
Like, you know, getting better, you know, also getting better, but like, whatever, you don't want to interfere with that.
But I've seen people like set up fake hospitals to study the flow of people going through like do carts fit, if there's going to be technology integrated, where should it go?
Should it be like a thing that you carry around?
You're actually having people do things.
It's fascinating. I've followed people.
This always sounds really creepy when I say it that how much I enjoy following people around at their jobs, but I do enjoy it.
It's fun. Following people around as they're selling things to people or as they're doing their jobs and just understanding, like, you're not just asking them questions, you're not testing them on anything, you're just understanding more about how they live their lives.
I don't know, maybe I secretly should have been an anthropologist.
There's an enjoyable aspect to understanding more about how people do things.
You can set up co design activities that are really fun.
Some of them involve Legos, like look up co design activities.
They're really enjoyable.
You know, you can have people sketching things out or drawing maps or working with you.
There's all this sort of mixed methods, qualitative research.
It's not just fun, right?
It helps you understand people's mental models.
It helps you understand how does this person think about the thing that they're trying to do.
And if you're at all like me, which I for your sake, I hope you are not.
It's just enjoyable.
It's a little peek inside people's minds.
There are less fun parts of it, like sometimes usability testing, if maybe the thing that you built and you were really excited about doesn't go so well.
I knew an engineer who really had a hard time watching usability tests because he called them hostage videos because it always looked like the person was like really struggling and terrified and like it was just very painful to watch.
It can be very painful to watch somebody use something that you made and it doesn't go the way you expected it to go.
But it's not necessary pain though.
And you know what the fun part of that is?
Fixing it and watching the next group of people just breeze through it.
That's the fun part.
And remember, if you didn't go through the hard bit, then the people who are struggling with it, even though you don't have to watch it, they're still there and they're not buying your stuff.
So anyway, the fun part is, I think, seeing the problem, figuring out the problem, really understanding it, having that aha moment and going, oh, now I can come up with a really cool idea for how to fix it.
Anyway, I think it's great.
Like I said, but then again, like I said, I like pivot tables.
So what are you going to do?
Personally, I think it's very interesting to talk to people and be a fly on the wall.
It's part of why I love the podcast so much.
But speaking of fun, this conversation has been a great deal of fun for me.
I really enjoyed talking to you and I'm sure everyone else has enjoyed listening to you and where can they follow you to get more of that online.
Right now, the only place to really see what I'm doing when I occasionally do it in any way publicly online is on LinkedIn.
I am on Blue Sky. I don't really talk much about work there, but might eventually.
But I am on LinkedIn.
I will hopefully eventually sometime this year be launching a class on Maven about qualitative and quantitative data and how to combine them.
So if you want to come and learn things from me directly, it will be much longer than this and have lots more details and lots more exercises and templates and things.
I wrote a couple of books, but they've been around for a while.
You're welcome to read those.
And I sometimes podcast on a podcast called What is wrong with hiring?
And it's all about hiring in the design and research and product space.
If you're anything on there like you are on this conversation, I cannot wait to check it.
I curse a lot more.
I'm sorry. Sign me up.
I'm subscribed. Okay.
Well, thank you so much for making the time, Laura.
This has been immensely fun and very informative.
I really look forward to the feedback that folks will have with this episode.
Thanks so much. It was great being here.
