Continuous Discovery In Practice

Teresa Torres, Flavia Neves, Kevin Newton at UXDX USA. Video: https://www.youtube.com/watch?v=TJL5H_E0dI0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Welcome and introductions

[00:00:00] Flavia: Hi, thank you Catherine. Great to have everybody here, great to be here. Welcome to the Continuous Discovery in Practice panel. I'm beyond excited to spend the next 30 minutes with Teresa and Kevin, and we're going to talk about all things continuous discovery related. I will try my best to actually ask questions about how to make this work for teams in reality, because we tend to talk a lot about the theory, but I think it's important that we also cover how do we actually go about doing continuous discovery.

[00:00:33] Flavia: So I'll do a very quick intro of Kevin and Teresa. Kevin has a background in applied anthropology and social psychology. He currently leads the Talent, Learning and Careers UXR programs team at LinkedIn. This team is quite interesting because they are focusing on scaling research through programmatic approaches, while of course maintaining the necessary rigor. And Kevin has been really interested in exploring models to enable non-researchers to do quality research, which is something that I'm super interested to know about and to discuss.

[00:01:07] Flavia: Teresa needs no introduction. She is an internationally acclaimed product discovery coach and author of the Continuous Discovery Habits book. As a coach she helps teams at companies of all sizes gain valuable insights from customer interviews, run effective product experiments, and also drive outcomes that create value both for users and for the businesses. In her book Teresa teaches a structured and sustainable approach to continuous discovery that ultimately helps product teams infuse their daily product decisions with customer input. So welcome guys, I'm so excited to have you here. Thank you.

[00:01:54] Flavia: For those of you listening, I don't know if you probably already heard this, feel free to drop your questions in the chat. We'll try our best to cover them all, and if we can't then I'm pretty sure we will get those questions and be able to answer later on.

Making the transition to dual track

[00:02:06] Flavia: So I wanted to start this conversation by talking a little bit about the transition from the more traditional project management kind of format to a dual track environment and doing continuous discovery. I know that this can be challenging, especially for those who are more used to a more predictable way of tackling projects, who want to know exactly what's going on and how to plan long sprints of work. So I'm interested in knowing, how do you guys help teams make this transition smoother? Do you have any tips? Kevin, we talked a little bit about this, I don't know if you want to start.

[00:02:46] Kevin: Sure, yeah. It's interesting. I think you're right, I think teams get locked into their projects, or trying to plan everything out. But for us at LinkedIn, I think a practical tip is to make it available to them. So that's the approach that my team is taking in this programmatic approach: making it easy, making it templatized, making it available, and then essentially making some suggestions when we're around them, and saying, hey, we have this thing, it's really easy, you could just come by anytime and get your insights. And then from there they get value, and then they tell their partners, and that's how we've done it at LinkedIn for sure.

[00:03:31] Flavia: Is there anything that you can share with us on how to make this transition, which seems to be so hard, a little bit smoother?

[00:03:39] Teresa: Yeah, I think it really starts with find a teeny tiny place to start. And what I really recommend teams do is just find a customer to talk to. If you've literally never talked to a customer, go sit in on an account management meeting or a customer support meeting, just get some exposure. And then from there you can ask, can I ask a question in the last five minutes? And then from there you can get into, can I turn that into a 20-minute conversation?

[00:04:02] Teresa: So I think the key is, if you've never done anything like this before, be nice to yourself. Don't just suddenly book an hour-long interview when you don't know what you're doing, but just find teeny tiny steps. And most of us have friends that work at our company whose job it is to spend all day with our customers, so go leverage them and have them help. I find that when you talk to customers more often, all the other good things start to fall into place. So you don't have to be an expert in all of the practices, you don't have to do what you hear about at conferences or reading books from day one. You just have to find a teeny tiny place to start.

Do you need buy-in from leadership?

[00:04:38] Flavia: Yeah, that makes me think about something that I usually get asked a lot when I'm talking at conferences. Almost always somebody asks me, how do you actually get buy-in from stakeholders, how did you do this amazing thing of convincing the leadership team to actually do discovery? And I don't know if you feel the same, but I find that, while that's true that sometimes you kind of need buy-in — if you need to interview customers and you need to have some sort of incentive for them to talk to you, you definitely need that — but I think that people in the product teams tend to underestimate the power that they have to do small steps towards doing discovery. They don't need a perfect setup, they can just start talking to customers, like you were saying, Teresa. So it's just start somewhere, ask questions, and get involved, frame the goals and the objectives in a different way, from the user perspective. Do you agree with this, or do you think that the product teams do need a lot of buy-in from the organization to actually do a good job?

[00:05:47] Teresa: Eventually you will, because eventually you want to change the way decisions get made about what you're building. But in the short run you have a ton of agency about how you do your own job, how much access you have to customers. I meet people that work at a Target or a Walmart and they're telling me they can't find customers to talk to. That's ridiculous, the people you live with are customers. So I think really, even in a B2B context, everybody knows a colleague who talks to customers, no matter what organizational context you work in. So I think the key is to realize you have a lot more agency, and even if nothing about your organizational context changes, you're still being asked to deliver a fixed roadmap, if you personally get exposure to customers you will build better versions of those things.

[00:06:38] Kevin: Yeah, I couldn't agree more. Being in the research function is a little bit different, and I would say at LinkedIn I'm certainly standing on the shoulders of the giants who came before, because they have a certain level of buy-in. We had labs when I joined the team four years ago. But the company I was at before that, I was the only researcher supporting seven brands. Now, the fact that they hired me as a researcher was some level of buy-in, but that's certainly at the leadership level, and it certainly wasn't there at the stakeholder level.

[00:07:08] Kevin: And so I agree with Teresa, and what you've said, that I just did small things, like trying to get the quickest win that you can, that's going to give some sort of value to some product manager — or we call them product owners in that company — or some other stakeholder. And then they become your advocate, and then from there they want a little bit more of that when they can, and a little bit more, and that's how you spread your influence. And before you know it, as in that company, you're being asked to do an ethnographic type study on how scheduling works. So you just have to chip away at it a little at a time.

[00:07:44] Teresa: The other thing I'll add to this is I would actually encourage you not to fight the ideological war. I actually think it does more of a disservice. So if you come into your organization and you say, hey, we have to do research and discovery and this is the right way to do it, you're running into the dynamics of a hierarchical organization. The people more senior to you got to where they are because what they've done in the past worked. So you're below them in the hierarchy, they're going to be like, whatever, go do your job.

[00:08:10] Teresa: As soon as you start doing it yourself and you show the results, people will get curious about how you're working, and you'll have way more ability to influence. This is what's behind show, don't tell. So I really do think the place to start is, what did you do this week, did it include talking to a customer? If not, focus on yourself, find a way next week to talk to a customer.

[00:08:35] Flavia: Yeah, I couldn't agree more. I made the mistake of trying to influence the top and saying, these are all the reasons why we should be doing this, and then I got nothing. It was exactly what you're saying: I was going against all the beliefs and what drove those people to the places where they are today. And then I slowly started incorporating some practices and working with what I was being given, but from a different angle, and showing, you know, this is what I got from this customer. And that's really hard to fight against, because suddenly you have a customer talking about your product in a certain way, and there's no way somebody's going to say, no, they're wrong, we know better.

Customer value and business value

[00:09:16] Flavia: That's super interesting. Do you think that, apart from what you mentioned, that leadership got where they are because of the framework that they used, do you think that apart from that it's also the feeling that we have to either choose business value or generating user value? Do you think that they understand that if you create user value then there will be a consequence in the business, or do you not face this problem?

[00:09:48] Teresa: So I would argue it's not necessarily true that if you create customer value you will create business value. We have lots of examples of companies that have created customer value and could not create business value. In fact, one of the ones that comes to mind often is Google Reader. People loved Google Reader, Google shut it down. It did not create enough business value. So first of all, a lot of designers in particular have this really strong belief that if you create customer value you'll create business value. In the subtitle of my book I said, discover products that create customer value and business value, because I think it's hard for product teams to see how these things can be aligned. We have to create customer value in a way that creates business value.

[00:10:31] Teresa: And I think that leaders push back because historically business has hyper-focused on business value. Some of our best companies and our best leaders talk about aligning those two things, but I think at the leadership level we over-index on business value, and at the individual contributor level we over-index on customer value, and we actually need to be synthesizing the two.

[00:10:56] Kevin: Yeah, I think that's an important point, because I think either way is not good. There are examples that you can point to that created business value but then no one wanted really to use it, because of the way it was created or the way that it was put out into the world. And then, I agree, definitely there are examples of — I mean, Trello comes to mind, no offense, I love Trello. They created an amazing product but they didn't monetize, they didn't know how to bring the business value, until they had to be absorbed by Jira. So I think there is a balance there.

[00:11:29] Kevin: But I think, Flavia, to your point, sometimes when we go into organizations we are these opposing forces, this dark and light as we see it. I'm coming in as an anthropologist of the people and I only care about what they care about, and this heartless executive only cares about money, and how am I going to change that person's mind? I think the more we can understand the incentive is the same — we want to create value both for you and for the person who's using your product — and then come together.

[00:12:05] Teresa: And this is where I actually think the shift to outcomes is helping a ton, because we can align customer value and business value in the way that we set outcomes. So the business leaders are going to be focused on financial metrics. That's what keeps you in business, pays your paycheck, that's good for everybody. But the product team has to look at how is the product going to support driving business value, and usually that translation is what's the value we're going to create for the customer that will create business value. And I think if teams, and leaders in particular, do a really good job of being intentional about how does the product create business value in a way that also creates customer value, it is very possible to align these and make sure everybody's working from the same sort of team[?].

[00:12:53] Flavia: Yeah, and that's where discovery helps, framing the problem in the right way, and then asking the right questions, and then going about talking to customers and identifying how we can actually deliver the user value alongside the business value.

From sporadic research to a continuous practice

[00:13:12] Flavia: And then, if we talk now a little bit about — we've transitioned, some teams have realized that okay, we should do discovery, we now understand why we should talk to customers and why we should have frequent conversations with customers. But I think we still see a lot of teams that still do it in very specific moments, and very sporadically. So some light research before we start the initiative, then we talk to customers right before we start, and then if we're lucky they will touch base back again with customers before they launch. How do we move from this model to a continuous discovery practice, where this really is our daily practice and not something that we do because suddenly we need to launch something new?

[00:14:06] Teresa: Yeah, I'll jump in on this one. I think really it comes down to, we're still, 20 years after the Agile Manifesto, trying to wrap our heads around what it means to be agile. Business is really rooted in a project mindset. We think projects have a beginning, a middle and an end, and we do research at the beginning and in the middle and the end. But digital products don't have a beginning — well, they maybe have a beginning, but they don't have a middle and they don't have an end.

[00:14:28] Teresa: And I cannot oversimplify this enough. There's lots of discovery tactics, there's lots of ways to get better research, there's lots of ways to collect more reliable feedback, but fundamentally, if you increase the frequency with which you, the team building the product, are engaging with customers, you will start to shift to a continuous mindset. And it's simply because you're introducing more opportunities to expose the gap between how you think about the product and how your customers think about the product, and that gap is there whether we see it or not. The gap will always be there. I wrote about a lot of habits in my book, but in one of the last chapters I really encourage teams to just start with, try to get to this cadence where you're engaging with a customer every week, and a lot of other things will start to fall into place.

[00:15:16] Kevin: I would say it's the same on my end, although I will say I think that if you're lucky it comes at the beginning and the end, at least in my experience. It would be great if every product idea came to research, or even wanted to talk to customers in the beginning. I think that's one area where we go wrong from the get-go. But if that happens, yeah, the continuous research — at LinkedIn what we're trying to do is create, again, these sort of programmatic ways in which people can get in front of customers every week.

[00:15:51] Kevin: This one is nothing new, but we have an ongoing lab where it's available, we're going to have customers to talk to, and you can just bring — we'll do three or four topics each week, and so you can just slot yourself in and come in and out as you can. We don't have enough resources to support that for every product or every team, but you do have the ability to do that at any point, anytime you have a question.

[00:16:20] Kevin: So I think setting up the systems, especially in a bigger corporation, is crucial, because otherwise, I think we mentioned this in the beginning, you get left with, well, I want to do it but I can't find any target customers. And even though that's maybe a false wall, if the program was there it wouldn't even be a question, because they're like, oh, there's this thing that I can just go to, this go link, and sign up.

[00:16:42] Teresa: Yeah, this is where we're getting into kind of the product operations side of things, or the research operations side of things. One of the things I talk about in the book is to automate your recruiting process. If you're hustling to recruit a participant every week, you're just not going to do it. Even if recruiting is easy for you right now, there's going to be the week where your release went astray, or there's a customer emergency, or your designer who usually conducts the interview is out sick.

[00:17:05] Teresa: So you have to think about how do you build a robust habit around this, and there's a few components to it. You need to make sure that you automate your recruiting process, so the interview's just on your calendar. Sounds magical, lots of teams are now doing it. I would also make sure that everybody in your trio knows how to interview and knows how the recruiting works, so when someone's on vacation or someone's out sick, your habit is more robust than being dependent on that one person.

[00:17:31] Teresa: A lot of these ideas came from me working with teams and just sitting down and thinking about, how do I make it easier for a team to interview than to not interview, how do I make it easier for a team to test their assumptions than to not test their assumptions. You can apply the same type of thinking to your own work. Where's the gap? It's a design problem, and we're designers. Whether you're a product manager or a designer, you're a designer. So how can you design for this problem and make it easier for you to adopt the right behaviors?

Avoiding the never-ending research trap

[00:18:00] Flavia: I think a lot of people are concerned, especially product managers. They don't really know how to run interviews and do research in general, and so they think that for me to actually schedule an interview with a customer I need to have a specific thing that I need to find out. Whereas sometimes — and I think the pandemic was a good example of this — sometimes you don't really have a very specific question, you just want to know how the market is evolving, and adapt your product to the circumstances and kind of go with the flow. So I think to a certain extent the pandemic helped a lot of teams understand the need to do this continuously rather than sporadically asking people.

[00:18:46] Flavia: I have another question about this, which is related to — it just slipped my mind, sorry, it's late here. So, we move from an environment where we don't even have to ask customers, to, oh, now we have to think outcomes versus outputs and now we need to talk to our customers and know a lot about them. But I've seen product managers, researchers, designers kind of falling into the trap of a never-ending process of, oh, what if I now explore this one little thing more, oh but this is so interesting, let me go down this route now and find something. So how do you, both of you — I'm interested in both of your experience — how do you help teams avoid this common pitfall of just a little bit more, we can know a little bit more? Kevin.

[00:19:53] Kevin: Yeah, it's really interesting, the pendulum swings, doesn't it? You have a team who is like, oh, we don't have time for research, or we don't have time to talk to people, and then you give them the value and now it is, oh, I can't make a move without having research. And so, much like everything that we've talked about, and everything in life, it's finding that balance and finding a way to not squash the intuition that you have as a designer, as a product manager, as someone in the world, but building up the ones where you are a little unsure.

[00:20:33] Kevin: And so I think we do a lot of matrices and prioritization with our stakeholders to see, like, how confident are you on this or that, and then we focus in on specific questions, and then the rest we kind of leave to intuition, because that's why they were hired. They have a great world view and perspective.

[00:20:54] Teresa: I think the key — so I want to build on that, because I think all of that is spot on, and I definitely see teams get paralyzed with, we can't make a decision without research. And that's not true. We're all smart humans. If you spend a lot of time with your customers you're going to make a lot of good decisions even without their input.

[00:21:11] Teresa: So I think there's two ways to think about this. I teach two primary discovery activities. One is interviewing, which is meant to be a generative exercise. We're generating customer needs, pain points and desires, opportunities that we can address. In that exercise you're continuously doing this, your opportunity space is always evolving. We see that with 2020, the whole opportunity space for a lot of teams shifted radically overnight. So that's one piece of it. I like to see teams doing that continuously, that's your continuous strip[?] on what's happening in the world.

[00:21:43] Teresa: But then I want to see teams pair that with really targeted assumption testing. And we're not testing just to test, we're testing to test very specific assumptions that should be actionable, that are supporting decisions about what we're building. I think that's the key, that when you're going into a research activity, to know exactly what the intent is, what you're trying to get out of it, and how you plan to act on it, so that we don't get stuck in this cycle of, oh, but I could talk to one more person, or I could run one more assumption test.

Bringing development teams upstream

[00:22:12] Flavia: We have some questions from our audience. Christopher is saying, in my experience the discovery and development teams are somehow separate and at different ends of the life cycle, especially when it's typically a project. What advice do you have to be able to bring development teams further upstream?

[00:22:34] Kevin: That's an excellent question, and so I'll start. I think it's a little different because we have a research team at LinkedIn, and so the researchers — it's not all continuous learning, we do take on projects, etc. During that time, though, we make a really big effort to bring in the engineers that will be working on the product, and the developers that will be developing it, to talk to the customers and hear the customers, even in the discovery, even before we know what the idea is, but we know what product it's related to. And that has paid tenfold for us, because they don't get that very often and they really appreciate knowing why they're doing what they're doing and why they're building what they're building. And so they become advocates, like we talked about earlier, and then it builds from there.

[00:23:25] Teresa: Yeah, I think a lot of this comes from problems with our language. When we talk about dual track, people think about that as we have a discovery team and a delivery team. That's not really the intent with dual track, and especially as with agile we're trying to move away from handoffs. So we don't want a discovery team handing off research to a delivery team. That works with project-based research, so if you work somewhere like LinkedIn, where I imagine the researchers are doing longer horizon project-based research, your product team should definitely be leveraging that research and using it, and they should also be getting first-hand exposure to customers for the team that's building the product.

[00:24:05] Teresa: And this is actually really important because product teams suffer from a bias called the curse of knowledge. We forget what it's like to not have all the knowledge we have about our products, and when we get first-hand exposure to our customers it's a very rude awakening of, whoa, our customers think about things really differently than we do.

[00:24:23] Teresa: Now, if you just go and invite your engineers to participate in your discovery, you're going to get some pushback. They're not researchers, they're not comfortable talking to customers. Again, I'm going to sound like a broken record: you have to start teeny tiny. Share a video with them, ask them to watch it on their own time, ask them to share with you the insights that they got from the video. Next time ask them to sit in the room. Next time ask them to write notes. Next time ask them if they want to ask a question. So think about onboarding your engineers to discovery the same way you would onboard a customer onto your product. It has to be a gentle process that walks them through why it's safe, why it's okay, and why it's valuable for them.

When feedback contradicts what you're already building

[00:25:04] Flavia: And incidentally, when we're working in dual track, how do we handle feedback part way through that is conflicting? So we've done our initial discovery process, we are heading in one direction, suddenly we have feedback that completely challenges our initial assumptions. How do you handle this when it's already in progress?

[00:25:31] Teresa: The short answer is you have to adjust. If you're learning that what you're building is wrong, you don't want to keep building it. Hopefully, if your discovery process is strong, you're learning that early in the process. So with assumption testing we're trying to learn, before we put a lot of investment into something, whether or not we're building the right thing.

[00:25:49] Teresa: Now, this is hard for people to wrap their head around, because we're still steeped in a project world, and we're still steeped in validation research. With validation research we do all the design up front and then we usability test it. For some teams it means we do all the development and then we A/B test it. So yeah, you're learning feedback really late in the process, and it's going to be disruptive and it's going to be hard and you're going to have wasted a lot of work. If you shift to a more continuous process where you're getting feedback along the way and you're testing assumptions along the way, you'll still have failed tests and you'll still have to take a step back, but you'll have a lot less to undo, because you'll be getting continuous feedback throughout the process.

[00:26:27] Kevin: And I will say, for the times when it does go awry, for the more project-based, or when you get further down the rabbit hole and you find out that it's wrong, one thing that worked for us at LinkedIn — because this has happened even at LinkedIn — one thing that we did as a research team is we actually encouraged the team and got them excited about going and talking to customers, and we removed them. We're in the San Francisco Bay Area, so we removed them from the Bay Area, we took them out into the field, into another city, for a week. We visited customer after customer, went into their location, watched them work, watched them use this new product that wasn't performing the way we wanted it to perform.

[00:27:12] Kevin: And through that we were able to create a world where, one, we understood and reconfirmed that we were actually solving the problem that we thought we were solving, so that was good, we weren't fundamentally wrong. But there were a lot of ways that we went about it that just didn't work, and so we were able to not only make those shifts, but the team came away more bonded, more excited, more interested in customers, and it really just fueled from there this idea that we need to be doing this on a continuous basis.

Comparing and contrasting

[00:27:43] Flavia: Do you think that helped the teams understand that we're not trying to prove or disprove one hypothesis and that's our one solution, but rather, what Teresa has said in her talk, it's about comparing and contrasting? So it's not whether or not we should do this, but rather is this the best solution?

[00:28:05] Kevin: I do. In that particular instance I do think that was a big part on both sides, because the way we were going about it was already kind of — there was a camp over here who thought maybe it wasn't so good, and then the camp over here that was like, this is the only way, which happens. And so I think getting them in the same room — we had functions across marketing, across operations, across product, across design, engineering — getting them in the same room, one, was useful. And then them seeing and talking about the same customers and seeing the problems made them understand, like you said and like Teresa said in her thing, comparing and contrasting, not one or the other. It's never one or the other, it's always what is the middle that is best for both sides.

[00:28:53] Teresa: This is a concept that I think is so critical and is underrepresented in our practices. I think designers are good at this when we're considering specific designs. Almost every designer is going to produce multiple variations of things. We forget to do this at the solution level, we forget to do this at the opportunity level, we forget to do this at the outcome level. And there's so much research on decision making that shows that if we consider multiple options we make better decisions, and especially when we bring in cognitive biases, there's so many biases that get exacerbated when we focus on one thing at a time.

[00:29:26] Teresa: And this applies in everything: design, product, your own life. If you're buying a house you probably should look at more than one house. If you're looking for a job you probably should get more than one offer. I think if there's anything you take away, especially in your discovery practices, the more you can compare and contrast, the better decisions you'll make.

The HiPPO problem

[00:29:46] Flavia: We have one other question that is going back to what we were talking about earlier, how do we convince leadership, etc. So is there a point where we should give up, because it's the highest paid person's opinion that is all that matters? Or can we always sell continuous discovery to anybody, and maybe it's just about employing your sales skills?

[00:30:15] Kevin: The HiPPO problem, huh. I can say from personal experience it's discouraging. I had set up continuous learning programs at my previous company where we did a lot of discovery and we were bringing in a lot of insights, and it led to some great ideas, we thought, as a team. And at the end of the day someone higher up came in, seeing it for the first time, and just said, there's no way this is going to work, and then all of that kind of learning and journey got axed.

[00:30:47] Kevin: And I think one thing that I learned from that is finding ways — and this goes to Teresa's point earlier — finding ways to bring that person baby steps into the process. So do you send a postcard that goes out to executives that's super succinct about the learning of the week? Or do you send a clip, a short clip, where it's like, if you have 10 seconds or 15 seconds, can you watch this clip? And just getting them to see that, so that whenever they get into a room where they see something they're not used to, they don't have a gut reaction of not liking it and then making a decision.

[00:31:41] Teresa: Yeah, I think this is where psychology comes into play again. The way our brains work is you hear about a problem, you jump to a solution. So you're talking to a stakeholder, they know what problem you're solving for, they've already jumped to a conclusion. So when you come in with, hey, this is what we're going to build, your conclusion is very likely different from their conclusion, and you're going to get the HiPPO problem.

[00:31:47] Teresa: If instead you do exactly what Kevin argued, you share your work along the way, you help show how you're getting to that conclusion, and hopefully, if you're doing good discovery, you're sharing new information with that stakeholder that they didn't have when they jumped to their fast conclusion. So you shift the conversation away from this opinion battle about conclusions, and you bring it earlier, to be about, hey, what type of information are we using to make decisions, and you're building a shared knowledge base, so that you're much more likely to agree on a conclusion.

Small iterations versus expanding the product footprint

[00:32:24] Flavia: I'm going to go against the rules now and ask you one more question, even though the UXDX team is going to kill me. So I'm interested to know, how do we maintain a healthy balance between those small little iterations that we need to do to improve the experience, versus those big, not paradigm shifts, but just expanding the product footprint? I kind of know the answer, but I'd love to hear your thoughts on this.

[00:32:53] Teresa: For me I would say it's really just being really clear on the outcome you're trying to drive, and having a deep understanding of the opportunity space. There's going to be times where a really teeny tiny optimization opportunity is going to have a big impact on your outcome, and there's going to be other times where you have to identify an opportunity that's really going to differentiate your product, or even extend your product, that will have the biggest impact on your outcome. I think the key is to make that decision based on impact on the most important outcome you're focused on right now.

[00:33:06] Kevin: And for me I would say the feeling that I'm getting, and what we're thinking at LinkedIn at least, is that there is an avenue where — and Teresa alluded to this earlier — we do have projects, so we do have foundational researchers who are doing longer term, more in-depth investigation into what is the future of work and job seeking and networking and that kind of thing. And I do think, especially as the company grows, that becomes very important to understand, so that you can make some macro changes and some paradigm shifts.

[00:33:56] Kevin: To get there quickly, I would say, as you're getting these quick wins, leverage them and capitalize on them. We did that at LinkedIn until eventually we take our executives out into the field once a year to actually meet with customers, where we pair a researcher with the CEO and his directs. And it pays dividends, because they see, again, they're talking to a customer, which they don't get to do that often, and then that trickles down, and then it allows you to build a more foundational team who is doing that deeper work.

[00:34:33] Flavia: We're going to have to wrap up. I would stay here talking to you both for hours and go completely off script and ask you all the questions that I have that would help me in my practice, but we have to wrap up. Thank you so, so much for taking the time, spending these 30 minutes with us, asking — or sorry, answering — so many questions.