Erin: [00:00:00] Hello everybody. And welcome back to awkward silences. We've got a special episode here today. We've got a guest host. It's our very own CEO and co-founder Basel Fakhoury. Uh, he's here with a guest Benjamin Humphrey, who is the CEO and co-founder of Dovetail. So two great apps to throw in your UX research toolkit, and two amazing CEOs and co-founders to talk about the UX research landscape.
JH: [00:00:31] Yeah, another special episode, which is fun. We haven't done a lot of these, but it's fun to mess with the format a little bit. The way I think of this episode is just imagine that you get to be a fly on the wall while two co-founders of user research focused companies get to really kind of geek out and pick each other's brain on all things, user research. So there's gonna be tidbits in there about how each of their companies came to be and how they got them started, what they see as short term opportunities for their respective areas, how they think of the user research space more broadly and what trends might be coming.
So again, it's just like a really cool, you know, look that you don't typically get to hear from, uh, from people who've been really immersed in this space for a number of years now. So, um, hopefully it'll be interesting and people will learn lots about it. So if you're interested in starting a company, interested in user research, all that kind of stuff, I think there'll be different items in here you can take away from.
Basel: [00:01:36] All right. Well, Benjamin, thanks for joining me here just so everyone knows. I'm Basel. I'm co-founder and CEO of user interviews, and this is Benjamin, also co-founder and CEO, but of Dovetail. I'm based in New York, and Benjamin where are you based? Cool. So from all around the world here and we're just going to have a conversation about our companies, you know, what we've been seeing in research. And yeah, so it should be fun. Thanks for thanks for joining Benjamin. Excited to chat.
Benjamin: [00:02:04] Yeah, thanks. But take us away.
Basel: [00:02:07] Yeah. Okay. So maybe we can both just start by giving a little background on our companies. If you wanna go first and just say, what does Dovetail do?
Benjamin: [00:02:15] yeah. Sure. So, we are a small Australian startup we've been around for. Basically four years. So we started in mid 2017 and we build software for researchers to analyze unstructured data and publish your insights, and share things with the rest of the organization. So it's an analysis and repository kind of offering cloud product.
You know, we're like 26 people at the moment. Everybody's based here in Sydney. And my background is in design and computer science. So my co-founder is an engineer. So that's kind of our quick nutshell of Dovetail.
Basel: [00:02:55] Cool. Yeah, definitely. Solving a big pain point. I was just talking with a researcher today and they were talking about how storing the insights, sharing the insights, building that repository and analyzing it is like what they're spending a lot of their time doing. So, definitely solving a pain point. um, And then User Interviews. So, we focus on a different part of the research stack. We focus on the participant management and recruiting layer.
So when people are doing research, they always need users to do research with. And the big split there we've always seen as the company wants to talk to their existing users that they already know, or their non-users people who might be prospective users or competitive users of competitors. So we have products for both of those.
So for the non-user segment, we have Recruit, which is basically an audience of participants. We have about half a million people. And a thick layer of data on them. And our real differentiator is we can find really niche users really quickly. And then when companies want to talk to their own users, they don't care about our audience, but there's a different set of pain points.
So for the end user, a lot of times they have to do a lot of manual tests, sending out a mail, merge, scheduling payment. We automate all of that. Then on the backend, all of that data flows into Research Hub which is a system of record for all of the participant interactions. So it's a way to track who you've reached out to who's participated in what studies how much you've paid them.
And that all is connected to those logistics the data from the workflows flows into that. And then you can invite people to studies directly from Research Hub. And yeah, we've been at it for I guess a little bit before you like a little over five years now. The team’s almost 50 people now, which is wild, how fast it's been growing.
And yeah, so, we're, I think, riding very similar trends and, you know, serving a lot of times the same users, but very different pain points.
Benjamin: [00:04:39] Absolutely. Yeah. I think a lot of our customers, when we speak to them, talk about participant recruitment and management and of management and people showing up for interviews. That's like one of their biggest frustrations. So
Basel: [00:04:54] Yeah. I often think of it like this, you know, this is a very basic framework, but I often think of the kind of three layers of the stack being the tool for conducting the test, which neither of us do, you know, there's a lot of companies doing that. There's Lookback there's the UserTestings of the world.
There's depending on the type of research methodology, and then the participant management and recruitment layer. And then, which is obviously where we play. And then kind of the insight and storage and analysis layer which is obviously where Dovetail is. I'm curious like what's the story behind Dovetail? What made you decide to build it? Cause you're saying it's hot and obvious now, but I imagine in 2017 it probably wasn't.
Benjamin: [00:05:33] That's right. Yeah. So we never started out building it like a repository tool. I didn't even know what research repositories were when we started the company. So the history is that you know, I was working at Atlassian and as a product designer, as a lead product designer on the platform team.
And I was on this one project, which was a growth team project. And the growth team hadn't really been exposed to qualitative research and design.
Like they were very statistical sort of quantitative focused people. So we ran this research project where we, it was a diary study where we asked new people who signed up for a JIRA trial, which was seven days to complete a diary entry each day. And the researcher I was working with, she used Tumblr for this diary study. So she set up a Tumblr account for each participant.
And then we got all the data back after like a couple of weeks or whatever, and you know, the way she analyzed it was printing it all out and putting it onto a whiteboard.
And this whole process by time from starting it from like recruitment, basically all like planning, and recruitment to insights that we could actually use to change how onboarding worked took maybe three plus months.
So like a whole quarter. And I saw this as a designer and I was like, Oh, this sucks, like there must be a better tool than Tumblr.
So I built this product and I call it Dovetail. And it was a diary study tool that emailed and sent text messages on a schedule. Yeah, so I just did that on the weekends and weeknights, you know, while I was working at Atlassian.
You know, we like, I launched it, got a splash page up, put it on Product Hunt, all this other stuff. And this was maybe in 20, this was 2016. And we got a few paying customers. It's just me. And then like, they all churned, they all canceled. And I was like what happened here? And so I talked to them and they're all like, well, we loved your product, but we've finished our project.
And so we exported all of the data to analyze it. And I was like, well, okay, makes sense. How are you analyzing it? And so they showed me their whiteboards, their spreadsheets, their sticky note walls. And they like journals and notepads and things like this. And I was like, man, like this seems like a bigger problem.
So also, you know, how often do you do this? Oh, I do this all the time. All right, great. That's a subscription business. Long story short took about six months for me to convince Brad to leave Atlassian with me. So we just built a really simple cloud-based collaborative tagging tool basically.
And so we started talking to our customers and they were like, okay, this is great, love dovetail. It'd be awesome if it could do video, et cetera. So then we built the video stuff and transcribed the zoom integration with COVID and then, but obviously the big missing piece was while I've done all this analysis and everything.
And I really liked to talk about that. But when I export it, which is hard because it's a relational tool, I take it over to PowerPoint or to confluence or something like this and share it with stakeholders. And I lose all of the, kind of, all of the evidence, right? Like all of it, I can't put the videos and stuff into word documents easily or confluence pages.
And so at the same time, Research repositories were sort of taking off as a problem. And we were, we kept hearing from customers, they wanted to solve this problem. And that's where we really focus right now, because I think that's the really interesting opportunity. And the analysis part of the product is fairly well baked. So I think that, yeah, it's funny how you end up kind of just evolving over time. You start being
Basel: [00:09:10] you're going across the user journey this year. You're going with them. And it's interesting. A lot of the You know, a lot of the kind of decision points in the story like came from user research, right?
A
Benjamin: [00:09:21] a hundred percent.
Basel: [00:09:21] A lot of meta-ness in both of our companies, I think where we tried to build it based on talking to users and sharing those and using those insights and relying on those insights. How do you like to think through that balance of cause there's all like with the, you know, core product at the time or the product that exists it's never done. Right. There's always new requests, at least in my experience. Like how do you balance, okay, we're going to spend this amount of time on this new product or this new feature versus beefing up the core product.
Cause that's something we're always dealing with is like, you know, we could continue to make the screener survey better, the scheduler better, which we want to do, but then we also, you know, wanted to build a research hub and that balance has always been difficult.
Benjamin: [00:10:01] Yeah, that's I mean, that's one of the hardest problems in prioritization is the hardest problem I think for startups. I think shipping MVPs of new features in order to get more feedback on them to improve them.
And then you spend the next quarter kind of, improving what you already have and trying to chip away at some of those feature requests and feedback that you get about the existing feature set. I think you need to the analogy that I use a lot is like the tent pegs analogy where like, you want to lay your tent pegs down first to sort of communicate to the other campers the surface area you're going to take up and then you build your tent up from the ground, as opposed to laying down just a single.
Two tent pegs, and then building a single wall. It's not clear where you're going to go. So I think that for our customers, it's nice to say like, well, this is kind of where we're going to go. So we've got all these features, all these tent pegs that aren't fully baked. They're not fully built. Give us feedback.
What do you want? What do you want us to say?
Basel: [00:11:03] That's cool. I've never heard that analogy before. I mean, the concept makes sense. I feel like I've heard that concept in different flavors, but never the tent pole analogy.
Benjamin: [00:11:10] Yeah, it's kind of like laying the foundation, but I think the important thing is like people don't know what they don't know and they don't really know what your company is capable of. And so I think that like when we built the video stuff, Our customers weren't asking for us to build video like that much.
They were saying like, can you make the text analysis, you know, faster or make charts better, or do some automation or something like that. And then the whole video highlight reel feature that we built, where you can like select stuff, slice it up. And we make it like a highlight reel. I think that most people probably felt like that was just out of the realm of possibility for a company of our size. We were only eight people back then.
And so, you know, maybe there's, self-censor don't give that feedback. And then all of a sudden it opens up this whole world of possibilities.
Basel: [00:11:56] yeah that definitely resonates. We, a lot of times when I'm doing research, we're just talking to our users. You know, you always ask the magic wand question, but then I'm like, don't just think about what's happening with our product. What are you using or what are you doing alongside our product?
That's also a friction point. Cause a lot of times when you initially ask you'll say, Hey, this feature could be expanded, but then, you know, we started asking that and then we, a lot of people were like, well, we also have to send NDAs for instance and have people sign those. And I think initially people didn't think about that as something that was in our surface area. To use your analogy, a very similar idea.

Benjamin: [00:13:10] Yup. Yeah. What, so what do you think is causing the rise of research Basel?
Basel: [00:13:16] Uh, Yeah, I think, you know, we're both, you know, like you said, there's an element of luck in that our timing has been good. I think there's a bunch of different trends. I think like the base trend across, like all the technology, it's just that the cost of building products has gone down so much that there's a lot more competition, right?
So the usability matters a lot more because you're not the only person doing what you're doing. And because of that, I think companies want to get closest to their users and make sure they're delighting them. And you see this also on the B2B side, specifically for B2B software where, you know, you used to sell to the CIO, or they used to sell only to the VP and then with product led growth with a bottoms up growth You're really selling to the end user.
So the end user cares about the usability a lot more than the CIO cares. So because of that companies then have to go and care more about the end user and do a lot more research to one, be competitive, and to serve them better. So I think those are two pretty big trends that I've been seeing.
And then I'm curious, what do you think, do you agree with those? Anything?
Benjamin: [00:14:20] Yeah, definitely. I think a lot of, yeah, like the barrier to entry for building software is a lot lower now. Like, I think if you go back to the early 2000s before we had tooling, like GitHub and AWS and like segments and all this sort of stuff, you know, you'd have to kind of write your own code to do the hope, do the hosting yourself and build your own analytics engine.
And so then the next focus I think, was, does it look good, which is kind of why design sort of grew in, like, does it look good? Is it usable? And then you started to see companies invest in design, like obviously Google, a pretty famous kind of material design sort of revolution, I guess when they went on Android and mobile. And when I joined Atlassian in 2013, there was only 17 designers spread across the entire company of five, 600 people with Atlassian had 10 plus products. You know, there's not a lot of investment in design. Because it was all functionality.
And then when I left, the design team was 120, 130 people. And this was in 2017, so it had grown quite a lot. And that was sort of also sketch and Figma and Invision they kind of pushed that along and also rode that wave of design. And I think that it was because companies, you know, the engineering side, well anybody could build billing now, anybody can build analytics, anybody can build a website.
And so, like the next question is kind of the, really the kind of hardest one, which is what we're building. Is it useful? Does it solve real problems? And you know, it's a, is it kind of what a product market fit looks like for this feature? And what's the value proposition?
Basel: [00:16:05] Do you think it's like, is it useful or that the bar for usefulness has almost risen because like a lot of the base usefulness has already been built.
Benjamin: [00:16:15] yeah, I think the bar for usefulness is, yeah. So to your point about it being more competitive, a hundred percent, like an, a, another thing I think about is that, you know, we're in the very early days of software.
So if you think about it, if you were going to start a software company back in the early two thousands, a B2B software company, and you're an engineer, the first problems you would try and solve your own problems, you would try and get, build, GitHub. You would build Stripe, you'd build Heroku, you would build you know, you'd build segments, you'd build Mixpanel.
Like you would build problems that solve your own challenges. Right. And cause you know that market cause you are the customer, right? You can dog food it. And so that's what happened. So all these engineers in the Bay area, built products for themselves. And then they, that market is saturated, like developer tooling and pro products for software teams is a very saturated, competitive market.
So now people started companies, which is like, okay we need to build for new markets. We're going to build for energy, for agriculture, for climate and healthcare, financial services. And so all these startups are popping up now in that space. But the problem is that the founders and the engineers and the product team, they're not the customer, right. That they've got a different customer base. And so they need to do research on it.
that's yep.
Basel: [00:17:40] That makes a lot of sense. I think another flavor on that too, is sometimes the first thing to be built is a general purpose tool, right? So not a there's sometimes, you know, a dev tool, like you said, if it's for the engineers themselves, and then maybe number two is a tool that can be applied pretty broadly across departments and across industries.
And then, you know, as clouds become much bigger than anyone expected, and a lot of the software has become much bigger than anyone expected markets that people used to think were small. Like pick your industry or pick your function are actually very large. Um, so then, yeah, similarly, when you're, when you're building for a specific use case, you want to get very close to them.
Benjamin: [00:18:18] Yeah. I also think that just, well, um, kinda practically, I think that it's becoming harder to do research as well. You know, like it used to be pretty easy just to go email the customer.
Basel: [00:18:33] I think this is something that, you know, I've been trying to figure out like how do researchers measure the impact of their work. And I've talked with other researchers about this And you know, you get differing answers as a lot of people say, look, we our KPI is going to be activity, right?
If we can do this much research, we're going to assume that it is having impact. There are others that try to, and the good thing about that is you can measure it, right? Like you can measure with a lot of precision and accuracy, how much research you did on the other side of seeing people talk through, look what we consider impact is how it affects the product roadmap for research teams that are kind of bundled with the product organization.
And we really track like the number of product decisions that are made based on the research we've done. I think that's what you want it to be, right? That's like the ideal world. But then on the flip side, it's harder to measure that in a number of different ways And then and then you also have people who kind of look more at specific features.
So they'll say, Hey, look, this feature we found through our research is going to have a better click through rate, is going to open up this segment. And that's great because this is very tangible, but you know, it doesn't seem to encapsulate all of the research. So I'm curious, like, have you seen other ways, do you have like opinions on
which way
Benjamin: [00:19:53] yeah, measuring the impact is it's very difficult. I think, you know, like research is fundamentally like de-risking. Exercise. It's a way for the business to essentially it's a litmus check or sanity check decisions in a kind of more efficient way than building it and taking something to market to do the same, right?
Like it's a validation tool
Basel: [00:20:18] I wrote a blog piece. And it was like, Yeah. You know, research is the measure once cut twice for product teams, right? You don't want to build it and then to go back and it let's you,
like you said, derisk it.
Benjamin: [00:20:30] Yeah. So ideally the research is more efficient than building the feature and shipping it. Right. And I think that when it is not true, that's where research kind of gets a bad reputation for being kind of costly and slow. And I think that there's different kinds of research, obviously, like I think evaluative is quite easy to measure.
Hopefully you can kind of even quantitatively say, well, we found these many bugs kind of usability issues and we fixed this many of them, and this is kind of the impact we had. The exploratory stuff where you're looking for opportunities. You're talking to customers and getting just broad level, like high level feedback on a product.
I think that's a little harder to measure, but the key thing I think is that research doesn't, it doesn't want to be seen as a cost center. So the Holy grail, when I talk to most of our customers is kind of being able to link a particular insight from a study to a roadmap item or a business initiative, and sort of have the connection such that when that thing has shipped back in dovetail, you get like this nice green tick next to the insight, which says like, you know, this resulted in this work, the work actually got shipped to customers and therefore the research was successful and the loop has been closed.
And then you would kind of take that to the, you know, when the research team asks for more budget, you take that to the CEO or whoever is in charge of the budget. And you say, look his, all of the kinds of risks that we mitigated, like if this had gone out to market without this research, we would have shipped the wrong thing and it would have taken the engineering team three more months to fix it.
But instead we ran a two week long project and we did it, you know, we, we learned the lesson upfront. I think that's the way to think about it, but I think, unfortunately this is a bit of a hot take, but I think that a lot of researchers miss this framing and get a bit hung up in the research and the sort of accuracy and quality and sort of statistical significance of the research almost for research's sake.
And I think the pragmatic approach, a big fan of pragmatism, you have to be very pragmatic as a founder is that research is a de-risking mechanism. And the question is how do we get to the directional insights in a lot of cases as quickly as possible to save the business time and money.
I think that's if you think about impact and from that lens, I think it becomes a bit easier. To justify, but
Basel: [00:22:58] Yeah. I think sometimes though, like de-risking and saving time and money does almost imply the cost center viewpoint. Right. I think it's what you described to me and what you guys are building with the green check mark seems like more than de-risking. It's also like opening new avenues, right? Like it's not necessarily that you would find that without research, it would just take more time.
Sometimes you just wouldn't do it.
Benjamin: [00:23:23] and I, this is just a thought that just came to me, but, you know, I wonder if it's any parallels to sort of, how engineering QA works and how they measure the impact of their work, because in a sense it's kind of product QA almost where you sort of saying, well, this is, you know, like for example, concept testing, like we did a bunch of concept testing in December.
And it was a very quick way to get a heap of feedback, but was it statistically significant or the most accurate kind of rigorous research? Of course not, but it gave our team some really nice directional insights to be able to move forward. And so, you know, we had a quick in dovetail, obviously a quick kind of list of all the insights, and then we'll be able to tie that to some pieces of work that we're doing.
Basel: [00:24:05] I've used the analogy that you used the analogy to the QA team there I've used the analogy a lot too like analytics teams. When a lot of times, like, you know, at the end of the day, both research and analytics teams are trying to get new information, trying to uncover insights and trying to help drive better decision-making.
And I think both of those, and, you know, it's somewhat ironic with analytics, but both of those is really hard to measure, but, But they do seem very parallel and they're just approaching it at a, from different
Benjamin: [00:24:34] Absolutely. I worked on the growth team at Atlassian for a while, and we were going through a phase in the company where everything was quantitative. I think every company goes through this phase where they see quantitative stuff as a silver bullet. I had a chat with another founder earlier in the week. And he was saying, he's got this new product designer who wants to usability test every single feature and the founder's, like, you know, I've known about this problem for like three years and let's just ship it, you know?
And I said to him, I was like, look, I think that the way you gotta think about that is if you have, it's a confidence thing. If you have low confidence, if you have low confidence, then you need to. Build your confidence through usability testing or an AB test or quantitative test. But if you have high confidence, because you've got, you know, you've got the context you have been talking to customers this whole time, you've got all the feature requests, all the feedback, then just get it done.
You know, I think that like, you don't have to AB test everything. You don't have to research everything. I think it's good, it's a confidence thing.
Basel: [00:25:36] That makes sense, but AB tests do though, going back to measuring the impact from research, like that's a great way to measure the impact, right? If you can prove that research moved or caused this feature or caused this change, then the AB test is obviously a great way to measure that. But I agree. Yeah.
It sometimes leads to a local maximum, right? Especially if you're not pairing it with research to help figure out, what should A and B actually be and what should C, D and E be?
Do you think research teams are going to, like, I think right now the plurality is probably they're actually part of design teams, I would say, are reporting into design. There's obviously some that report the products on the stand alone. There kind of seems to be this insight teams that have like analytics and research.
And then what do you kind of see as the most common one now? And what do you think it will be like I dunno, five, 10 years from now.
Benjamin: [00:26:24] Yeah. So like in Dovetail you can self-identify. What sort of department you're in. And it's like a drop down and you can choose design or research or whatever, and 50% of people choose design, just our user base. I know that 50% of our user base is not designers. So I think that a lot of people yeah, are in a design team at the moment.
I think that it's a tricky one because you know, one of the things about the rise of research is that it's also called into question the point of product managers, which is a thing that a friend of mine, who's a distinguished product manager at Atlassian called Sharif. We like to talk about a lot.
It's like if the researchers are doing, talking to customers and doing the research and the designers more and more influential in terms of setting the vision for the product. And running vision workshops and even prioritizing stuff. What does the product manager do, you know, are they kind of pricing packaging and go to market type stuff?
But yeah, it's interesting. Like we have this overlap all the time. I hear about, you know, PM design research and kind of varies depending on the company.
Basel: [00:27:38] Yeah, no for sure. I think you know, I'm not going to say what's the point of product managers. I think I fall somewhere else on that spectrum. But I do think like PM is an interesting role because it's very much like a negative space role, right? Like engineers do have very clear roles, design has a very clear role and in PMs a lot of times are like, how do we make that all work together?
So it's almost defined by what the other ones aren't doing.
Benjamin: [00:28:03] The glue, I suppose.
Basel: [00:28:05] It's like, You have these and it's like, something's missing here and it's
Benjamin: [00:28:09] To also like product marketing as well, in there too, which is just kind of, how do we take it to market? How do we communicate features and stuff? So,
Basel: [00:28:16] Yeah. No, there's more and more like specialized in that bucket, but you didn't, you, you did bring up a good question, right? If there's more specialized roles taking up that negative space, is there negative space
and that's think the question,
Benjamin: [00:28:28] And I think that's what large organizations struggle with. What is the asset that the role produces? Like if you think about it as an economy, what's the currency that a designer or an engineer produces. And so, like, I think an engineer produces pull requests in a sense they're, you know, they're writing code, but like ultimately the sort of object or the asset that they're producing is a pull request.
I think that and then a product manager produces like traditionally, like a roadmap or maybe a strategy. And again, that's where the discussion and the collaboration happens and they're all kinds of IC roles. They're all individual contributor roles and they produced this thing. And so the question is, what does a researcher produce?
What is the asset? And I don't think that's really been figured out. Like, is it insights? Is it a report? Is it research plans, unclear at the moment? I think that's something to figure out perhaps because other roles it's very tangible.
Basel: [00:29:23] Yeah, no, that's that's interesting. I haven't thought about that framework with just like, but what is the output that they're working towards?
Benjamin: [00:29:28] And that's important if you're thinking about it as an IC kind of role because like each IC in the business needs to produce something kind of, to keep the economy going.
Basel: [00:29:36] yeah, we talk a lot about the atomic unit, right? Like, and
Benjamin: [00:29:40] Yeah.
Basel: [00:29:41] someone, I think the clock chain is blocked.
Yeah. He wrote a good one about how to signal atomic units.
Benjamin: [00:29:49] That's right. Yeah. Yeah. So I think that's, I think as research evolves, you know, at the moment it reminds me a lot of design, right? Like you go back to where, when I started out as a designer and we were using Photoshop for all of our design work, which was not purpose-built for design, you know, it was a photo editing tool that dealt with bitmaps. And when you look at it, now it's kind of crazy, right? Because you'd have to use this tool that wasn't even made for it. You'd be creating shapes and buttons and things like this. And it was all kind of terrible compared to Figma and sketch.
Obviously,
Basel: [00:30:26] Tell people we're using like Tumblr
Benjamin: [00:30:28] right. So exactly so flexible tools and to your point earlier, get displaced by purpose-built software as the discipline or the problem kind of is mature enough to warrant it. Right.
Basel: [00:30:41] Yeah. Like our initial customers when we were starting user interviews were using Craigslist. So that's that's
Benjamin: [00:30:46] Yep.
Basel: [00:30:47] you know, for the marketplace, that's the best, that's the big general purpose tool, right? So that's a good one. There's a wall. I don't know if you've seen the blog post that shows all the businesses that came out of unbundling Craigslist.
Benjamin: [00:30:58] right.
Basel: [00:30:59] but
Benjamin: [00:31:00] Yeah. Interesting. Yeah. And so I think that you know, everyone uses these kinds of generic tools and then there's some sort of chicken and egg period where there's just enough people with this use case to warrant a company like a sketch to build. A vector-based purpose-built a user interface design tool, and then there's this pull and push motion, I guess, where these software companies like Figma and sketch and InVision and in the case of design, you know, pump out heaps of thought leadership and content marketing kind of pushed the market along away from generic tools into purpose-built software.
And I think that similar thing happens with research where we're moving from a world of spreadsheets and sticky notes and Google docs and drive and Dropbox and Slack into maybe purpose-built software for like a storage of data and collaboration around the data, which is where we come in.
So, and likewise with user interviews and participant management. So I think that's a macro level kind of what happens. Yeah.
Basel: [00:32:01] Yeah, no, that makes a, it makes a ton of sense. it looks like we're coming up on an hour here, so,
Benjamin: [00:32:06] I've got one month. One more question for you. So I'm interested, like you guys just raised a 10 mil series, what does the future hold for user interviews?
Basel: [00:32:15] Yeah, definitely. So a lot of it is investing in the core product. We already have updated the UX, investing in the audience so that we can make sure that we scale and can find more niche participants, find them faster. I think one general theme for me across everything is like the speed to getting these insights because people have to make decisions very quickly.
And, you know, kind of like your example when you were at Atlassian and if you have to make a decision in a week or two weeks, and it takes a month, you just are not going to do the research. Right. So continuing to bring that speed down. But then looking at what's around us in the space, I talked about those other layers.
It's how do we make the experience very good for these users that are going to be using these other tools? So. I think a big focus for us going into next year is going to be integrations and partnerships so that people have seamless workflows where they can use us to find the participants and then say, you know, no, one's agreed to this yet.
But say like, Lookback for conducting the study or another tool for conducting a different type of study. And that's all one seamless experience. And we think that's really important for us to cement our place as participant recruitment and participant management. But we also think that's just a better experience for everyone involved.
Benjamin: [00:33:27] makes a lot of sense.
Basel: [00:33:29] Cool. And how about you guys?
Benjamin: [00:33:32] Well we are just going to keep trucking away, trying to, like, I think one of the big shifts in how people consume and share their researchers. It's going from a push, like a push out to pull. So, we have this all the time where researchers and not just like, we think about research as like a capital R as in like the title, but then there's also people like PMs and designers and even like CX people
Basel: [00:33:58] full-time and part-time researchers
Benjamin: [00:34:00] time, part time.
Yeah.
Basel: [00:34:01] Then
Benjamin: [00:34:02] Yeah. So like people who do research, you know, they're kind of having the onus of sharing, the sort of stuff is on them. They have to kind of organize meetings and make PowerPoint decks and publish things through Slack and share stuff you know, on confluence with drive and share links around.
And so the overwhelming feedback is basically. Consumers want to be able to pull the data to them at any time.
So this whole notion of a self-service kind of some customers call it a portal where they can go and they can search through all the research. They can consume it in their own time. Whenever they like 24 seven, it doesn't rely on a researcher scheduling a meeting or putting a deck together. So I think that whole self-service repository space is where we're investing heavily in.
And of course, because we have all the analysis in Dovetail, all the data there, all the raw video, the raw transcript and the notes, and then the tags and everything like these insights. And so then we just need the problem is that you don't want to show like the CEO, that level of fidelity it's too granular.
So there's some story on top of but you need to tell,
Basel: [00:35:16] Kate Towsey who runs research ops at Atlassian. She recently had a tweet, I believe that said, you know, I think we always use, have used that term, people who do research because she had a tweet about, we also need to think about people who want research and it seems like that's kind of a shift you're on making, like initially the tools were for the
Benjamin: [00:35:34] Yeah, so it's yeah, so it totally flips a whole kind of mindset. And rather than focusing on people that end up to her executing on the research and doing the analysis and doing the tagging and all this other stuff we're saying right, the product's there for that. Now we need to focus on the full perspective of a consumer.
So that's also like looking at things like, you know, analytics is an interesting feature. So if you publish a finding or a report or whatever it is in Dovetail as a researcher, how do you know if you've got some engagement? Well, You know, maybe we can put some page views, analytics and stuff.
Like we've seen Google docs do this where you can actually see, who's read it, read receipts, you can see how many views it's got. You can put likes and comments on it. Maybe there's a popular feed or something like that. So you can actually have the front page, like Reddit for your organization's research.
And it's this whole kind of social aspect of it, which is really one where we want to focus. Our lead designer calls our strategy, basically building the Tik Tok for research. So that's kind of, that's the approach.
Basel: [00:36:37] are you all going to build a feed? Is that going to be like a
Benjamin: [00:36:39] Yeah, that's the plan. So I think big think if you had YouTube or Pinterest for your research data inside your company what would that look like?
So that's sort of out,
Basel: [00:36:47] That's awesome. I'm excited, too excited to see it.
Benjamin: [00:36:51] yes.
Basel: [00:36:52] All right. Awesome. Well, cool. Benjamin, this was fun.
it again.
Benjamin: [00:36:59] Yeah, no awesome Basel and thanks for organizing it and great to chat to you.