After getting started in construction management, Anna Jacobson traded in the hard hat for the world of data products and operations at a VC company. Anna, who has a structural engineering undergrad and a masters in data science, is also a Founding Member of the Data Product Leadership Community (DPLC). However, her work with data products is more “accidental” and is just part of her responsibility at Operator Collective. Nonetheless, Anna had a lot to share about building data products, dashboards, and insights for users—including resistant ones!

That resistance is precisely what I wanted to talk to her about in this episode: how does Anna get somebody to adopt a data product to which they may be apathetic, if not completely resistant?

At the end of the episode, Anna gives us a sneak peek at what she’s planning to talk about in our final 2024 live DPLC group discussion coming up on 12/18/2024.

We covered:

• (1:17) Anna's background and how she got involved with data products
• (3:32) The ways Anna applied her experiences working in construction management to her current work with data products at a VC firm
• (5:32) Explaining one of the main data products she works on at Operator Collective
• (9:55) How Anna defines success for her data products
• (15:21) The process of designing data products for "non-believers"
• (21:08) How to think about "super users" and their feedback on a data product
• (27:11) How a company's cultural problems can be a blocker for product adoption
• (38:21) A preview of what you can expect from Anna's talk and live group discussion in the DPLC
• (40:24) Closing thoughts from Anna
• (42:54) Where you can find more from Anna

Quotes from Today’s Episode

• “People working with data products are always thinking about how to [gain user adoption of their product]... I can’t think of a single one where [all users] were immediately on board. There’s a lot to unpack in what it takes to get non-believers on board, and it’s something that none of us ever get any training on. You just learn through experience, and it’s not something that most people took a class on in college. All of the social science around what we do gets really passed over for all the technical stuff. It takes thinking through and understanding where different [users] are coming from, and [understanding] that my perspective alone is not enough to make it happen.” - Anna Jacobson (16:00)
• ​​“If you only bring together the super users and don’t try to get feedback from the average user, you are missing the perspective of the person who isn’t passionate about the product. A non-believer is someone who is just over capacity. They may be very hard-working, they may be very smart, but they just don’t have the bandwidth for new things. That’s something that has to be overcome when you’re putting a new product into place.” - Anna Jacobson (22:35)
• “If a company can’t find budget to support [a data product], that’s a cultural decision. It’s not a financial decision. They find the money for the things that they care about. Solving the technology challenge is pretty easy, but you have to have a company that’s motivated to do that. If you want to implement something new, be it a data product or any change in an organization, identifying the cultural barriers and figuring out how to bring [people in an organization] on board is the crux of it. The money and the technology can be found.” - Anna Jacobson (27:58)
• “I think people are actually very bad at explaining what they want, and asking people what they want is not helpful. If you ask people what they want to do, then I think you have a shot at being able to build a product that does [what they want]. The executive sponsors typically have a very different perspective on what the product [should be] than the users do. If all of your information is getting filtered through the executive sponsor, you’re probably not getting the full picture” - Anna Jacobson (31:45)
• “You want to define what the opportunity is, the problem, the solution, and you want to talk about costs and benefits. You want to align [the data product] with corporate strategy, and those things are fairly easy to map out. But as you get down to the user, what they want to know is, ‘How is this going to make my life easier? How is this going to make [my job] faster? How is it going to result in better outcomes?’ They may have an interest in how it aligns with corporate strategy, but that’s not what’s going to motivate them. It’s really just easier, faster, better.” - Anna Jacobson (35:00)

Links Referenced

• LinkedIn: https://www.linkedin.com/in/anna-ching-jacobson/
• DPLC (Data Product Leadership Community): https://designingforanalytics.com/community

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I’m really happy to have one of our founding members of the Data Product Leadership Community on the phone with me. I guess we’re not on the phone, we’re on remotely, but Anna Jacobson, how are you? What’s going on?

Anna: I’m doing great, Brian. Pleasure to be here.

Brian: Yeah, I’m excited. So, you’re going to be giving a—or hosting—one of our live group discussions at the end of mid-December here, end of 2024, and I thought it’d be fun to give people kind of a sneak peek of what you’re going to be talking about in that, and more on the themes, at least in this episode, kind of overarching themes and ideas about data products. The first thing I wanted to ask you, though, is, like, when I saw your title, I was like, oh, Operations and Data Partner, I know Operator Collective is a venture capital company, but how in the heck are you, like, involved with data products and, like, how did you find yourself over to the [laugh] DPLC? Like, what’s the connection there?

Anna: Yeah, so I think compared to a lot of people in the community, my journey to data product leadership has been non-linear, let’s say that. I started out, I got my undergrad degree in structural engineering, worked briefly as a structural engineer, and then transitioned into construction management. I did that for many years, and then got really interested in data, so I went back to school. I got a master’s degree in data science, and at that point, when I graduated, it was 2020, it was a few months into the pandemic, the world was sort of on fire, and I wasn’t sure what I wanted to do next. And a friend who was starting a venture capital fund reached out to me and said, “Hey, I have a vision for how we’re going to use data at my fund, which was called Operator Collective. Can you come help me out?”

So, I started in a consulting capacity. After a few months, it became clear to us that that was going to work, so I came on full time, and eventually ended up taking over all of the operations functions for the fund. Which in venture capital, that means fund operations, fundraising, investor relations, fund administration, all of the, sort of, internal ops, handling third-party vendors like legal and finance. So, it’s a bunch of different things. So, I would say I’m sort of an accidental data product leader. It was never in my title, it was never in my job description, but both in my work in construction and my work in venture capital, I’ve just sort of naturally gravitated towards building and implementing data products as part of the work that I was doing on a daily basis.

Brian: Got it, got it. So, most of the solutions, these products that you’re building right now, these are going to be internally facing for the investors or the people working inside Operator Collective?

Anna: Correct. A hundred percent.

Brian: Okay. Got it, got it. Tell me about, I know you were doing some of this work when you were doing construction management, and I’m always kind of curious, as you know, when you go to the next chapter, what do you take with you? What do you leave behind? Were there lessons learned? Are you kind of repeating a similar model of how you are leveraging data products to help out these organizations you’re working with?

Anna: Yeah, I mean, I would say at a sort of 30,000 foot level, there’s a group of reasons why a company might want to implement data products. And what I found is even with a lot of differences, not just differences in industry, but, you know, differences in team size and background of users, and you know, goals for the company, even though those things are all different, the reasons why we use data products—again, at that very high level—are quite similar. As you get closer to the ground, the differences show up a little more. You know, construction is a—[laugh] it has a reputation of being sort of change-averse, technically behind, you know, those kinds of things. I think now that I’m outside of the industry, I see that that was not really specific to construction management, but a lot of the behaviors are typical of any legacy industry that just didn’t grow up thinking about data and using data products.

In venture capital, it’s a little different. We invest in tech companies, so we’re very tech adjacent, and I would say, you know, techno-positive, but at the same time, the company that I work for is a startup. It wasn’t even a year old when I joined. And so, the challenges for me are almost the reverse, in that I’m not dealing with a bunch of entrenched behaviors and legacy systems and all of that, but I am building everything from scratch, and you know, not just the tool itself, the product, but also all of the processes and practices that go with it.

Brian: Got it. Got it. Are you able to talk about that at all, about what this is, or just kind of paint a visual image for people when you say this product at Operator Collective?

Anna: Sure. So, at Operator Collective, our founder, Mallun Yen, had a vision very early on that she wanted the way that the fund ran, the fund operations, to be very data informed, data heavy, I would say, given the size and sort of maturity level of the fund. So again, when I joined, we had just started, I was handed a bunch of spreadsheets with a bunch of data in it, and told, “Go.” And so, it was really energizing, in some ways, as a data product leader, to say, you know, this is a new company, like, big picture, I know what the vision is, and you know what the strategy is, but there are a lot of details that are still being worked out. I have this data set—or, again, in this case, it was a bunch of little data sets—how can I bring that all together and create a data ecosystem that’s valuable for the company?

And it’s pretty rare, if not singular, in venture capital. I talked to a lot of people working in other VC funds, and nobody’s doing exactly the things that we’re doing. But I would say that everybody recognizes there’s a lot of data floating around in the industry, and there’s a lot of things we can be doing with it.

Brian: Got it. Are there, like, a handful of specific use cases you can—or maybe the really high value ones or the ones you know that are, like, working well for Operator Collective? Because lack of use, which we’ll probably get into, low adoption, is one of the hardest problems. That kind of to me, is like, this cancer [laugh] in the data product space, is really the secret that so much of this work is not getting used a lot of the time. So, I’m curious, are there specific areas that you’re seeing high reliance on these data products that you’re creating?

Anna: Yeah so, unlike a lot of venture capital funds, Operator Collective is also a community. It’s a community of operators, which we define as tech executives, and it’s also a community of founders, which are the companies that we’re investing in, they are building and scaling those companies. And so, part of our whole reason for being is to bring those two groups together into a single community where the investors—the operators—are, you know, going to financially benefit from their investment, and the founders benefit from the expertise, the networks, the you know, all of the knowledge that the operators have. So, that’s the model of Operator Collective. My sort of big goal when I came in was, how do we collect and analyze the data to prove that the model is working and/or to identify where it’s not working and make changes? So again, this is not sort of the normal use case for data in venture capital, but a really exciting one to think about in terms of, how does data support community building?

So, one of the ways that I’ve worked on this or thought about this problem, is that we have different functional areas within the company. We have our community, which is just sort of all the people and all the organizations that exist in our ecosystem, and we have our investments, which is a very specific function, and then we have what in venture capital is called ‘platform.’ It’s really all of the post-investment support that an investor provides to the portfolio. And that can include—at least for us, it includes things like events, programs, direct support that we provide, but also all of those connections that we’re making between the founders and our operators. So, what I did was, each of those three things is a separate database that has its own functions, each one has an interface where people on the team can interact with the data, but I also created a database where all of that data gets piped together, and that gives us a single pane view of every touch point, every activation point within our community. And so, my internal team is able to view that in sort of real time, but we’ve also created a practice of sharing that information out within the community as well.

Brian: I see. Like, one thing you talked about, like, is the model working or not, and one of the places I find that we often end up with low adoption, is if we ladder that back, we haven’t figured out what it means to observe it’s not working. Like the words ‘it’s not working’ has to be an observable trait. And it suggests, if the asker, the requester, is saying, “I want to know if it’s not working, or if it is working.” By definition, that must be observable or you wouldn’t know that it’s not working.

So, we have to define some parameters for what working and not working means in order to design anything that might possibly help you change something. So, I’m curious if that’s—and I’m only digging into this—it’s kind of almost arbitrary that I’m digging into this, but what are some of those indicators of it’s working or not working, and how did that end up in some kind of digital form, interface, or however it’s experienced? Can you unpack how you got from kind of the vague statement from leadership down to, like, oh, working means this in this context, and we can now track that and make changes.

Anna: Yeah. So, I mean, these are all great points, and I will not claim to have complete answers to any of it. It’s definitely—

Brian: [laugh].

Anna: A work [laugh] in progress.

Brian: That’s okay.

Anna: I mean, first of all, to your first point, yeah. I mean, proving a negative is pretty much impossible, right? Like, so to start with, proving that it’s not working is difficult. And you’re also in kind of a, like, a Schrödinger cat kind of situation where you know the things that happen, you can’t ever know what would have happened had those things been different, right? So, one of the original challenges for me was even defining what success would look like in that model.

So, it’s very easy to say this is what the vision is, but it took a lot of digging and a lot of thinking to get that down into something that could be supported with data. And so, I actually now have a framework for thinking about that I share with others who are doing this kind of work because it’s not to say that this is the way that I did it; it’s the way I would do it [laugh] now knowing what I know, and that is, basically to start by defining what the vision for the community is. So, that includes who the community is, which isn’t always clear, and you know, what the value that they are getting out of the community is. So, you know, what are they there for? And then, once you do that, I think, then you can start thinking about, what does success look like in that community?

And there are definable metrics of success. So, you know, I do think that engagement is number one for any community. You know, without engagement, you really don’t have anything—you can’t accomplish anything else in a community. But then there are other metrics that may or may not be relevant. So, for instance, there are a lot of communities that use growth as a metric. For us, that was never the intent, so we purposely kept our numbers quite limited. We wanted it to be intimate, we wanted it to be special, so growth is an example of a success metric that we don’t think about or talk about.

And, you know, understanding that really helps because otherwise, as the data person, you may just be tasked with gathering all the data that you possibly can, and not knowing what is actually going to be meaningful. So, for us, connection is really the next success metric. And so, making those connections between the people in our community is very, very core to what we’re doing here. So, that naturally then leads to, well, if that’s the success metric, then what’s the KPI that goes with connection? And for us, it really is about, you know, tracking all of those introductions that we’re making between people. And that can be, you know, via email. It can also be in other ways, like, where we host an event where we’re connecting people.

So, we have a number, then of KPIs that we associate with that one success metric. And then from those KPIs, you can derive what data you need to collect. So, you know, for instance, event attendance is very important to us, and we track not only who attended an event, but also everyone who was invited so we can start to look at attendance rates and things like that. So, I mean, that’s a fairly mundane example, but that is how I think of it is, going from vision to success metric to KPI to data, and then from there you can really start building, how do you share that information?

Brian: Got it, got it. And are you the de facto product manager for all of this or do you have a team? Do you have design and engineering support? Like, how do you—or do you roll all this yourself? How does that work?

Anna: It’s all me. We’re a tiny team. We are six FTEs with, you know, some part time support. So, everything is me. I build using Airtable, which is a no-code and, you know, fairly low-tech platform. But it was selected before I started, and it turns out it’s really great for what we’re doing because it’s very flexible. And so, I’ve sort of become an Airtable expert, and built all of our products through that.

Brian: Got it. Got it. So, tell me about this. You talked about in our group discussion, which I’m looking forward to, about non-believers, the resistance of non-believers, and how we design for people who are perhaps actively against, as opposed to passively or disinterested, they’re actually detractors. That tells me there’s some story there.

Anna: Yeah [laugh]. Yes—

Brian: [laugh]. Where did you get—

Anna: A number of stories.

Brian: —to that?

Anna: First of all, you know, I’ve spoken with dozens of people in the community now. I had the fun task of vetting lots of people who’ve joined the community, so I’ve had a number of conversations with people. And I feel in every conversation, no matter where it starts, we always end up talking about the challenges of implementation. And I feel like this is a very, very common, not just a common challenge, but something that people working with data products are always thinking about is, how do you implement? And because of that, I know that this is a pervasive problem, and nothing that is specific to my experience, but I will say, coming out of the field that I came from—construction management—and also because I was never in a role, and you know the that the role never existed in the company where I worked, where somebody was tasked with data products, every data product that I worked on, which was probably 20 or so, there was a significant role for persuasion as part of getting that product off the ground.

I can’t think of a single one where everybody was immediately on board and it was just like, “Let’s go do this thing.” And so, through that experience, even though I didn’t even know data product management as a term, I didn’t even know that term, and never thought of what I was working on as data products, I knew that there were things that I thought would be good for us as an organization, and my job was to go out and get people to support it, to advocate for it, and then to use it. And that was always the hardest part. The build was easy, right? It was getting that sort of consensus.

And so, when I was thinking about what I wanted to talk about for this webinar, I feel like there’s a lot to unpack in what it takes to get these non-believers on board, and it’s something that none of us ever get any training on. You just learn through, sometimes, hard experience how to do it. But it’s not something that most people took a class on in college. I don’t think anyone did, you know? And sort of all of the social science around what we do gets really passed over for all the technical stuff.

Brian: The implementation, when you said this was difficult to measure, I just wanted to be clear, are you talking about the implementation of putting a data product into use within an org, or the changes one would make as a result of insights derived from a data product—

Anna: [laugh].

Brian: Or the building of the data product? I don’t think you mean the building because you just said that’s the easy part. Can you clarify what you meant by the implementation phases, where these executives struggle?

Anna: It’s both. I mean, it’s the first two things that you named. So, it’s getting people to use it, right? And, you know, it’s not just training people on how to use the tool, but it’s redefining the processes in which the tool is used, but then it’s also everything downstream of that. And so, in some cases, there isn’t much beyond that use case, but in others, it has sort of ripple effects throughout a lot of what we do.

And again, earlier in my career, I really thought that, just by virtue of the fact that I was smart and experienced and meant well and wanted the best for everyone, that anything that I was advocating would just sort of organically be accepted. And then I’ve learned that’s not how people work, typically, and it takes a little more intention than that, and it also takes, it takes really thinking through and understanding where different people are coming from, and that my perspective alone is not enough to make it happen.

Brian: Yeah, I was just listening to a podcast about this, about—this is something I’m trying to teach too in my seminar is that one thing the design field is good for is that you get in the process of separating yourself from the work, and you’re putting zero to one things that you came up with out into the wild, and then saying, okay, I’m ready for teardown and rejection to come. And that is not a skill that I think is taught a lot of places, where it’s like, here’s a tough problem; solve for X, more of an analytical type problem. It’s very different than I don’t know if this is going to work. I don’t even know if it’s on the right track. I’m going to have to, like, throw swings at this and then let people tear it apart, or possibly be completely disinterested, or tell me they don’t even want to look at it, period because they just don’t care. They’re so actively disinterested from it.

That is not a skill that is practiced, and I think it’s a skill that’s needed to get used to this idea that, like, I’m separate from the work, and this is a kind of a ga—we’re playing a game here. And it’s like, for me, it’s a fun game, I like the game. I know some people I don’t. Like, why don’t they use it? And they get really frustrated. It’s like, how could you not find this useful? You know, it’s so obvious, of course you’d want to use this data. Like, why would you not? Are you just guessing? And we can come up with all this conjecture, but it’s not their lived experience.

So, can you tell me any stories about, like, an active dissenter or an active—you change names for what do you call it, for privacy, or we’ve changed their names for privacy, as they say in TV, or whatever it is. But like, I’m curious to hear one of these, and maybe what happened during that process. Did you ever get them involved and was there a happy ending to it? Or was it, like, no, you can’t change that, and one of the learnings is to let go. Like, tell me about one of these detractors.

Anna: Hmm. Okay, well, let me think. I’ve got many examples, one that comes to mind, and this one, just to be clear, I was more of an advisor on this one than the lead. But there was a new tool that was being built. A group of sort of super users came together to manage the process of building this new tool.

And the reason for it was that—it was a tool that was used for financial reporting. The CFO wanted to start closing the books on a monthly basis rather than quarterly, and everybody in operation said, “There’s no way we can do that with our current process. It’s too cumbersome. It’s too time consuming.” So logically, the decision was made, well, let’s build a new tool that makes it faster and easier, and then people can start using it to be able to report on a monthly basis.

Two big mistakes, though, that I saw in that process. The first was, if you only bring together the super users, and you don’t try to get feedback from, let’s say, the average user, it often means that you are missing the perspective of the person who isn’t passionate about the product, right, or even about the process, about the results, maybe doesn’t care about having it be perfect, just needs to get it done. That’s one characteristic of a non-believer, to me, is someone who is just over capacity. And so, they may be very hard-working, they may be very smart, but they just don’t have bandwidth for new things. And that’s something that really has to be overcome when you’re putting a new product into place. So, mistake number one was only getting the super users involved.

Mistake number two was conflating the change in process, in this case, the timing going from quarterly to monthly, with the implementation of the new product. Because looking back, somewhat predictably, what happened was, the product got rolled out, and everybody said, this is horrible. I now have to report every month when I used to only have to report once a quarter. Let’s go back to the old tool [laugh] because I liked reporting once a quarter. Again, both decisions were well-meant and somewhat natural, but that product failed badly after quite a bit of investment for those two reasons. And so, that would be one example.

Brian: I bet the engineering and data science got a lot of money, though, because they always say there’s never money to build it right the first time, but there’s always money to build it twice, you know, the second time, to do it right [laugh].

Anna: Absolutely. Yeah, yeah. Well, and I think it was a hard lesson for everyone. And again, you know, pretty obvious looking back that those two mistakes were big ones, but at the time it just, it made sense.

Brian: Yeah. This is one of the tricks too, with, like, product-market fit in the commercial software space, you might want to go double-down and find those power users and say this product is for people like you. It’s not for the average person. It’s not for the, whatever, the accounting team that’s checked out. It’s like, this is for someone who’s like, I get incentivi—like, I get a bonus if I, like, kick ass on my numbers, and this product helps me do that. You might just—that’s your marketing, that’s your audience.

But if it’s, like, an internal situation, it’s like we got to satisfy everyone in accounting, not just the power user. Both have their challenges, right? Because one, you got to convince someone to swipe a credit card or pay you a fee to use it, and the other one, it’s like it’s free, but you might have laziness, or no incentives, or too busy, these kinds of challenges. So, I’m curious, like, how do you get them involved if this person’s too busy, and you know that, like, they’re a linchpin in the data product being successful. What’s your like—how do you think about this now going forward. If you had that playbook again, if you had that assignment again, how would you do it differently? If they’re like, “I have no time to meet with you. And sounds great, but”—

Anna: Yeah no, it is a challenge, and it’s not the wrong strategy to—or I should say it’s not an invalid strategy to say, “I want to get the super users on board. I know they’re going to be excited about this, and then they can go out and sort of evangelize for this product, among others.” Like, there’s nothing inherently wrong with that, and in certain situations, in certain organizations, that may be the best strategy. In this particular case, though, what happened was, you know, the other 80% of the users just got completely left behind, and the super users built a very, very complicated product that then, you know, by the time it got rolled out to everybody else, just felt completely overcooked and unnecessarily complicated.

So, I think if you think about who this sort of average user is, and what the level of complexity that they are going to be happy with is, starting to build to that and then adding features and adding capabilities after you’ve built that sort of MVP and gotten that average user on board with the MVP, in this case, that definitely would have been a more successful strategy. You know, sort of burying people who, again, are over capacity with all the bells and whistles, was just—it just did not work.

Brian: Yeah, yeah. You had said at some point, like, all these challenges come back to cultural problems. Like, all changes are cultural changes, and that’s often the blocker. Can you unpack that a little bit like, what were you getting at there in your LinkedIn post?

Anna: Yeah, sure. So, this was a slide that I was preparing for the webinar where I was trying to dig into what factors prevent organizational change from happening. And I had bucketed them into financial factors, technological factors, and cultural factors, which, you know, sort of looked nice and coherent on a slide, but I started thinking about it a little more, and the financial and technological factors, the more that I thought about them, the more they just felt like cultural factors as well. So, if a company can’t find budget to support, you know, in this case, the data product, that’s really a cultural decision. It’s not a financial decision. Like, they find the money for the things that they care about, so what that is really saying is that they don’t care about this product.

Also, you know, if people are overly focused on sort of short term gains and short term ROI, and that is a cultural characteristic, that’s not really a financial issue. You know, same thing with risk aversion, that’s a cultural issue, not financial. And then, you know, with technological, most of the technological barriers that I’ve experienced have had to do with legacy systems, you know, interoperability issues, insufficient infrastructure, insufficient IT support. Again, those are really cultural issues, if you think about it. Like, those aren’t really technological issues. Solving the technology challenge is pretty easy, but you have to have a company that’s motivated to do that.

And so, then you come to what I originally called cultural issues, which are, you know, ineffective leadership, and inadequate communication, and lack of trust, and fear of the unknown, and all of those. You know, those are, again, obviously cultural, but I think the other ones are, too. And so, the TL;DR on all of that is that if you want to implement something new, be it a data product or, you know, really any change in an organization. I think identifying the cultural barriers which are fundamentally human in some way or another, and figuring out how to bring those people on board, that’s sort of the crux of it. The money and the technology can be found.

Brian: Yeah. I mean, I’m with you. And I mean, I don’t know how you get that to happen, or get that insight from these people. The way I model this in my head and that I teach is that this comes back to exposure. How much exposure regularly do you have to these people so you know what it’s like to be the whatever… accountant in accounting or in the finance department or whoever you’re building for, it’s directly correlated to that.

And if you’re not out there doing the non-technical, non-building, non-data work of understanding what it’s like to be John, then you’re never going to do a great job with that, with producing something that John cares about, or let alone would he even give you the time to talk about what he might care about, especially if he’s already so busy right now that it’s like any change is disruptive and, like, just it’s negative by default. Like, I don’t know how you get past that without regular exposure. I mean, maybe you have—do you have other [laugh]—do you have—how do you deal with this? Like, are you regularly talking to these people? How do you come up with stuff that’s going to be used?

And especially when you have that detractor mentality, or I’m too busy for this kind of mentality, where do you go? Or do you say, I’m not even working on this product yet because I don’t have the right leadership support. They haven’t incentivized that group to make any change, so, like, time out. We’re not even going to talk about any technology yet. Like, how do you deal with that?

Anna: Yeah, so, I mean, I agree with you. It’s incredibly hard. I had the luxury of, again, building internally. You know, I was in my own functional area, and had very close connections with all the other functional areas, so it was never really a problem for me to get access to the people who were going to be stakeholders in the product. I think about that a lot, actually, for people who are working as consultants, or you know, other sort of external data product managers because I just don’t know how you could get enough insight into what anyone is doing, particularly because, first of all, I think people are actually very bad at explaining what it is that they want.

And in fact, I think asking people what they want is not helpful. I really advocate for asking people what it is that they want to do, and if you can get people to tell you what they want to do, then I think you have a shot of being able to build a product that does that thing. But there’s that, and then I also think a problem is working with executive sponsors only. The executive sponsors typically have a very different perspective on what the sort of business case is for the product than the users do, and different motivations for wanting it to be in place. So, if all you’re getting—if you’re all of your information is getting filtered through the executive sponsor, you’re probably not getting the full picture.

One of the things—an example that I’m planning to talk about in my webinar is a product that I built where I really had three different users at three different levels. So, there was the C-suite person who was sort of the executive sponsor, and then there was a level below them of executives, and then a level below them of managers, all three of whom were going to be using this product, but in different ways and for different reasons. And thinking through how to talk about the product with each of them was part of the challenge. But I know if I had only been interfacing with that COO, I would not have gotten the full picture.

Brian: This is a very common challenge we have in the design space all the time about multiple different use cases, you know, that persona a needs to be able to do X, Y and Z, A, B, C for this other persona. How do you come up with something that’s not going to be kind of crap for everybody because it’s trying to do so many different things there? That’s a really hard place to get into, but I like that you’re at least interfacing with these people. And part of it is that negotiation of, like, frankly, you don’t really know what’s good for them. You think you do, but you really have never done that job.

You’ve never been a manager of a whatever before, of a call center or of a, you know, sales team. You imagine what you would like to get from the sales team, so sometimes it comes out in words about, “They need to use something like this as a requirement,” but they really don’t know what it’s like to be a sales manager or what their incentives are. And they’re not working it backwards from the people on the ground that are going to have to eat and drink this thing all day, or maybe all week or however it’s being used. But those are very common challenges. It’s a messy problem space, you know, and it’s not a technology problem, which is where I think a lot of data and technical teams that work on data products struggle is because it’s not yet a technology implementation problem; it’s still a mushy, yucky person feelings problem, [laugh] incentives. It’s not neat and bundled up, and part of it is really defining that problem space. So, I’m just, like, going on my soapbox here and in agreement with you, I guess [laugh].

Anna: Yeah, no, I totally agree with that. And I also think that when you think about sort of as you sort of move down the hierarchy—and this is a generalization—but my experience has been with the sort of C-suite executive-level discussions, there, you really do want, sort of a classic business case. You know, you want to define, what the opportunity is, the problem, the solution, you want to talk about costs and benefits, you want to align with corporate strategy. Like, those things are fairly tidy to map out. But as you get down to the user, I think what they—at least in my experience—what they want to know is, how is this going to make my life easier, how is this going to make it faster, whatever I’m trying to do, or how is it going to result in better outcomes? And ideally, all three. And so yes, they may have an interest in how it aligns with corporate strategy, but that’s not what’s going to motivate them. It’s really just easier, faster, better.

Brian: Yeah, and if you don’t know what the baseline is for that which you can’t get from just third-party observation, or, like the horses, like, some—if you don’t get it from the horse’s mouth, it’s really just a guessing game because often you get the corporate strategy baloney, like, which, as you said, that is not what someone, individually, in their day-to-day work, is thinking about that most of the time. They’re not incentivized to do that, right? They’re incentivized to get the monthly reporting done. I don’t care what the numbers are. I just need to type them in. It’s your job to care about the actual numbers and what to do about it. They’re complete—

Anna: Exactly.

Brian: I mean, they do care. They want to have a job, but beyond, like, I want to keep my job, and maybe this touches on my bonus incentive or whatever, eh, do you really care that much? In my experience, most users do not. Like [laugh]—

Anna: And the flip side is that most, or I should say, many executives are not going to be motivated by the argument that this product is going to make the user’s life easier, right? Like, especially if—I mean just being honest, if the user is on salary, like, do they care that it saves them an hour a week or an hour a day? Like, maybe not. So, my point is you have to have both. For each stakeholder, you have to have a reason for the product, and it probably isn’t going to be the same depending on their role in the process.

Brian: Yeah, I mean design language, I frame these as user experience outcomes, and then business outcomes, and they sort of can overlap a little bit, but there’s really two distinct things, and you can’t get the business outcome if you don’t make the people using it happy in some way, where happiness really means, I made their life better in some way, saving the time, making them money, getting rid of pain or hassle, whatever that may be. You can’t get to the golden land of the business value piece, which is really what you want, so part of it is, like, in my experience, it’s framing to a leader that what you want has this necessary speed bump you have to get over first. And if you don’t get over that, you can’t get what you want, except guessing. You might get lucky and come out with something that maybe worked that one time, but that’s not a repeatable strategy. If you’re going to be doing this with multiple products, or anything like that, it’s not repeatable.

I don’t know, that’s my take on it. But this is great. I know we’re kind of, like, in fierce agreement on a bunch of that, which maybe makes for a terrible podcast. I don’t know. I usually like to, like, [laugh] find out we have some disagreement and, like, dig into that space, but I have a very similar framing of the world in my head that I think you do.

So, one thing I want to share with people as we kind of wrap up here is, what would they get in the session we’re going to do? Like, we’re going to have a group discussion. You’re going to kind of kick it off with some slides. It sounded like you were going to go to a case study. And I know you’re not going to give it all away here, but maybe you can give us a taste of, like, what else would be in there?

Anna: Yeah. So, in the webinar, what I want to talk about with the group, and again, this is intended to be a conversation, so I hope everybody who comes will bring their opinions, but I did want to dig into these barriers to change, and you know, sort of what that means to us as product leaders. I wanted to share a framework for thinking about change that I found to be very useful for me. And then, yes, I have a case study. A little case study, but I think one that may be sort of good to illustrate some of these concepts with actual slides from my deck, from when I was out there shilling for this product, so I want to use that both as an example, but also for some lessons learned.

And then I want to dig into some very specific tactics. So, I have some things from my current work, I have some tactics from my old work that I want to share, that are just ideas about how to get people who are, again, who I’m calling non-believers, on board with this. And then at the end, I have sort of four key concepts that I want to talk about with the group, and that’ll be the discussion.

Brian: Cool. Yeah, I’m looking forward to—I imagine we’ll have some good questions and [laugh] some curiosity here, especially if you’re able to deal with these detractors in some way that everyone else hasn’t figured out how to do yet. So, I’m looking forward to seeing everyone, and thanks for your contributions in the DPLC as well. That date is, it’s December 18th, 2024. It’s a Wednesday. It’s going to be the new time for us, 3 p.m. Eastern time. So, I’m glad you’re trying out a new slot. We’ve had most of ours at noon Eastern, so we’ll be giving that a go.

And yeah, Anna, any kind of closing thoughts from you, anything you would like people to take away, if there’s kind of one thing that maybe you’ve learned or something, a key idea that you’d like the audience to hear from, hear you talk about for, briefly.

Anna: I guess it’s the idea that I think pretty much everyone is going to have some non-believers in their life, as a data product leader. And it can be tempting to just ignore them and sort of, you know, barrel forward and do the best you can, but I think, through many years of experience, that there are ways to get those people on board, and that if you can convert those non-believers to believers, they can really help, so it’s worth spending some time to think about it. And again, that art of persuasion is not taught to us formally, but I think it is a big, important part of our job.

Brian: Yeah, yeah. You made me think of something with the persuasion thing, and you said that might be a viable strategy for some earlier, but your comment about, you know, building it for a power user, and then they tell all their friends, this is literally, like, marketing strategy, as taught by people like Seth Godin, which is, marketing isn’t really, like, oh, it’s advertising. Go spend money, try these tactics. It’s really, how do you get someone to talk about the thing, and how it made their life better, or changed their status, or made them money, or whatever the thing is. That word of mouth is precisely what you want to do is create something that’s so good it naturally spreads.

The question, though, is whether or not, is it spreading to people who care about the people who are evangelizing it? Because, as you said, the average user may not care about that power user and what it’s done for them because they don’t aspire to be like them. But that can be a very—in fact, I think that’s almost a necessity is that you want to have some virality in the solutions that you’re building if you’re worried at all about adoption, but it does mean you need to know the audience that you’re serving to see, are all the people over here in this accounting group, for example, or sales team, are they all having similar aspirations, such that if we nailed it for this person, the others would likely follow because they’re all incentivized the same way. So, I think that’s great that you brought that up, and I just had a little connection to—I love Seth Godin. He’s one of my people I listen to quite a bit, and it sounded right out of his playbook, [laugh] that model.

Anna: I just saw something recently that was saying that basically every job, in the end, ends up being sales. And you know, so this is in some ways about what that sales job in data product leadership looks like.

Brian: Sure, sure. Full agreement. Anna, so great to chat with you. Where can people get in touch with you? Is LinkedIn, are you posting on there a lot? Or where can they find you?

Anna: I am an avid LinkedIn user, and I love to connect with people there, so please reach out.

Brian: Cool. Awesome. I will put your link to LinkedIn in the [show notes 00:43:12] here. And thank you again for coming on Experiencing Data. It’s great to catch up.

Anna: You too. Thanks, Brian.