The Product Manager

The Barriers to Product Adoption Are Not What You Think (with George Brooks)

• Hannah Clark - The Product Manager

Share episode

Product adoption can sometimes feel as elusive as catching lightning in a bottle. There are myriad reasons why users might resist adopting new products, from the fear of change to the comfort of established routines.

In this episode, Hannah Clark is joined by George Brooks—Founder and CEO of Crema—to explore these challenges and draw out actionable insights for product leaders.

Resources from this episode:

Hannah Clark:

This is embarrassing to admit, but whenever I think about product adoption, I think of the 1996 hit movie Matilda, adapted from the 1988 Roald Dahl story, Matilda. If you haven't seen it, it's about a child prodigy, named Matilda, with incredibly practical superpowers, but the people who are supposed to love her just don't give her the time of day. Now I hate to spoil this nearly 30-year-old children's movie for you, but in the end, Matilda is adopted by her first-grade teacher, Miss Honey, who's so taken by her abilities that she, presumably, can't picture a life without her anymore. Now if I haven't lost you in this metaphor yet, your product is Matilda, and your product team is six-year-old me, watching this movie, dumbfounded that nobody around Matilda cares about how amazing she is. And while I'd love to say the movie is also chock full of product adoption strategy tips, the advice of my guest today is assuredly much more realistic. And that guest is George Brooks, founder and CEO of Crema, a Design and Technology Consultancy. Crema's whole MO is actually helping organizations develop bespoke solutions for their own teams, meaning his team works very closely with a lot of end users. Meaning his team is intimately familiar with the many reasons why so many users resist embracing products that, by all accounts, should make their life a lot easier. He's about to share some of the easily-missed barriers to adoption he's observed in the field, some compelling strategies for overcoming friction to adoption, and some intriguing notes on how adoption and culture go hand in hand. Let's jump in. Welcome back to The Product Manager podcast! George, thank you so much for making the time to chat with us today.

George Brooks:

Such a pleasure, Hannah. Good to see you.

Hannah Clark:

Yeah, you too. So can you tell us first a little bit about your background and how you got to where you are today?

George Brooks:

Yeah. So my background actually is in user experience. I started as a user experience designer, gosh, 16 years ago. And I joke that I went out on my own when my oldest daughter was actually in the hospital. So it was one of those things where I talked about entrepreneur journey is often a person goes into it because they are trying to like chase a dream, they're trying to prove somebody wrong, or they got pushed off a cliff and they have to learn how to build a parachute or a plane on the way down. And I was definitely the latter person like circumstances of life pushed me into going out on my own freelance designing. And then I realized pretty quickly that I'm a designer that dropped out of college and I have no idea how to run a business. So the next 15 years was me coming together with my business partner and us learning how to build a UX and now a full design and technology consultancy or a digital product agency together.

Hannah Clark:

Wow. That is quite a journey. And I hope everything turned out well.

George Brooks:

She's great. She's 17. I've had three teenage girls right now. It's the best.

Hannah Clark:

Okay, fantastic. Okay, well, oof. Well...

George Brooks:

I dropped that right on you. Sorry about that.

Hannah Clark:

That's okay. No, I'm just glad everything turned out well. And obviously things worked out well for the business as well. But today we're going to be chatting through some of the barriers towards product adoption that frequently get missed by most product teams. But first, I'd like to frame your perspective as someone in a product-enabled services company, which is a little bit different from some of the more standard SaaS business models, at least that we've talked to on the show. So what is it about this space that has your heart and where do you really see it going in the near future?

George Brooks:

Yeah, it's funny. There are two different types of businesses that you can start. You can start a service business or a product business. And a service business is interesting because all you have to really do is convince someone else to pay you for the thing that they don't know how to do or don't want to do. Now the great thing about a service business is that you can make money literally today, right? If someone is willing to give you that money now in exchange for the service that you provide, then you can make money today. And what's unique about that is that's a one-to-one relationship, meaning usually the unit of time is the measure of kind of your value. So one hour for an hourly rate. This is true across what we do as a design and technology consultancy or a development firm. It's also true when you get into enterprise companies like big management consultants or construction companies or engineering or Architecture, they're all still thinking about like how many hours is this going to take me to do it? What can I charge for that hour and how can I make money soon and hopefully make it profitable. Different than if you're doing a product where you're saying, I need a runway, enough money or cash to burn through or spend wisely to get to the point where I can find product-market fit. And then hopefully at that point I spend like there's no tomorrow, like a blitz scaling, take the Reid Hoffman model. And I'm going to try to get that product-market fit scaled to a point where either I'm profitable, that would be the suggested idea, or at least valued high enough that you could sell it off for profit, right? What I love about services is that actually most of the economy does not run off of products. It runs off of services. So if you think about everything from people that mow lawns, or people that are providing tree trimming services, or your accountant, or your tax preparation team, or your bank is even a service provider. And even product firms tend to have a service provider side of them. So they'll say, hey, we have this tool that you can use, but ultimately, here's a service contract with it, right? So what I love about the services is that there's a unique challenge in service that technology or product can help to solve, which is how do you get past this one-to-one relationship, one hour for one billable unit? And ultimately, how do you get to the point where you can say, maybe it's one hour for four billable units, or one person to 10 customers and start to change that ratio, allowing you to grow. Ultimately, I'm focused on how companies scale. And the reality is, service companies don't tend to scale, they grow. They might grow fast, but they ultimately just grow versus product companies are focused on scale. So different challenges. But ultimately, when it comes down to it, we're still building modern technology to help to facilitate it.

Hannah Clark:

Yeah. And when you say we, I love if you can give me a little bit of a rundown of Crema specifically and how it gives you a unique view into the challenges around product adoption specifically.

George Brooks:

Yeah, absolutely. We meaning myself originally, and then ultimately Dan and I, and then a handful of other folks, started out as user experience agencies. So we were focused predominantly on how do we get closer to the user, design a product that they will want to use, and that will serve them well. And we were working with early ventures in the early days. As Crema grew, we started to take on more roles and responsibilities. So that meant we started hiring our own engineers, our own software developers. We started hiring product managers and training up product strategists and product managers. Started hiring test engineers and lots of other roles that fill out what you might call a squad or a pod or a cross-functional product team, right? And so really what we found is the sweet spot of providing cross-functional product teams to companies of all sizes now that may have developers or engineers or resources in-house, but need a partner to help them innovate quickly or take on more capacity than they normally have. Now the interesting part of that is being still focused on UX, a lot of traditional firms might have an IT department, or an engineering department that is developing some software that helps them run. They rarely tend to have a UX group because that's a little bit like, well, why do I need UX when it functionally works, right? And ultimately, then what that allows us to come in and do is say, Hey, UX is about users. It's about human beings. It's about the person that's going to open the app and they will want to open it, and they will desire to open it ultimately. And if you took it away from them, they would be upset. So how do we start to craft experience and then ultimately a product that will allow them to have that engagement with it? And not, you say, Hey employee, or Hey customer, you have to use this because we built it. And in order to work with us, this is what it looks like. Ultimately, we want this to be something where people feel invited into the experience. And we get closer to the user in that process through really user experience research or UX research. And then ultimately building out that product with them rather than shoving it towards them.

Hannah Clark:

And that actually is a perfect segue into my next question. Because one of the things that we've chatted about before is the irony of how a lot of product teams just aren't very close to their users. But you've been in the position of working very closely, obviously, with the end users. I'm very early stage of the product development process, so just a little bit about your approach to those interactions and how you synthesize those findings into the product development life cycle.

George Brooks:

Yeah, what I find is that actually in the B2B world or in the business world, especially in the services world, technology is a threat, right? I'm going to bring you in a piece of software that might help you be more efficient, which means that you won't be able to bill as many hours. But wait a minute, we make money on the hour, so I want to bill as many hours as I possibly can. Or this tool will actually maybe do some of your job for you. It'll maybe do some of the schematics or it might figure out the estimation that you used to do in your own little pretty spreadsheet. But ultimately, that becomes a personal or identity threat to someone's job. So if you can bring them into the experience, then basically you allow them to feel like they have ownership of this product. They feel like they're a part of the creation of that. So what we do is we very carefully come in and say, Hey, our name is Crema. We are not a threat. No, that's not how we start. We do basically say like, Hey, our name is Crema. We're here to build a tool that's going to help make your life better. Would love to learn more about your life. Right? And so what we do is we start having conversations early and often, even before we start designing anything, even before we start building out anything. And we say, what's your life look like? What's your day look like? So show me the tools that you currently open up. Oh, wow. That's interesting. You look like you're the most proficient person that's ever used this thing. And ultimately building trust. I love Reid Hoffman's model that says trust is consistency over time. Right? So they've never worked with us. They don't know who we are. And even their IT departments don't know who they are because they've never talked to their users. And so what we say is, hey, let's get on the floor. Let's get out on the work site. Let's have a conversation with somebody and go, what's your day look like? Who are you? What's your name? What's your context? Do you have kids? All these factors that go into, now you can trust me. Let's start talking about building a tool that's gonna help you. And that's I think it's really about the human touch. It's about that human inviting ourselves into a human conversation, which some people just, it's funny. People are afraid to do it. People are afraid to say, I don't think I have permission to talk to them. And no one ever told them they didn't. They just didn't. And so what we said, so we have no fear of asking for permission. Hey, tell me who your employees are. Can we get access to a couple of your customers? I'd love to talk to them. And learn more about their lives their context. And it's funny how many people go, yeah, I guess we could do that. And the next thing you know, that barrel rolls into, yeah, let's bring them along on the journey.

Hannah Clark:

An area I think that is chronically undervalued is just speaking to users. Can you walk me through a little bit of the surprising trends and the findings that you've uncovered when working with users closely? I think this is just an interesting space.

George Brooks:

Yeah, I think that the most surprising thing is that people are actually really innovative on their own. So what we found is actually, people are dealing with the problem already. We talk about technology is here to solve problems, right? And sure, we all say that, but ultimately people are solving the problem a different way. It might mean that they have not told the IT department that they're using some SaaS tool on the side, some free version of it, right? Or more than likely they went, well, I'll just make a spreadsheet for it. When I'm doing my kind of onboarding with a new client, I go through a series of questions and one of the questions is what's the spreadsheet that if it got deleted, your company couldn't run? And ultimately what I'm getting at is probably there's a tool that could do that for you, but you just you said now I'm going to hack my own way. And ultimately that's a good thing because you find that as you get closer to users, they have found a way to make their lives work. Second thing is that people are lazy. And I think that's a good thing to just say out loud. And we all are. We all look for habit routines. We all look for disciplines in our life to make our lives just a little bit easier. So we don't have to have the cognitive load of am I under threat right now? And so we try to create these routines that make our life easy, which then is a challenge of change, right? So that we have to be really welcoming ourselves into a conversation and say, yes, this might be a change for you, but that change might actually create new habits, new routines, new disciplines and make your life better. And so I think those are the two things that I'm always surprised by is that most people are really innovative. They figured out a way to, hack the solution. Ultimately, people are also lazy. So they're looking for the laziest, easiest way to hack that solution where they don't have to ever change. And then I think the last thing is just that as you start to look at the role between leadership and individual contributors for the ones actually providing the services versus the ones that are managing the people that provide the services, there can be a disconnect between the expectations of consistency. So the individual contributor cares less about things being consistent because they're like, hey, I figured out a way to make it work for me. The manager or the leadership says we need to be consistent so that I can figure out how to make this profitable. So one of the value props we talk a lot about when we're building solutions is saying, okay, yeah, you figured out a way to do it, but I bet that spreadsheet's been copied at least a dozen times and people tweaked it. So now you have an inconsistent estimate or you have a consistent project management approach. And ultimately if you bake that into a piece of software and everyone uses the piece of software, there's a user adoption challenge there. But if everybody does use it, now you have consistent data to then make better decisions about how to make a profitable service company.

Hannah Clark:

Okay. And I want to dive a little bit further into product adoption challenges as well. So let's talk a little bit about the friction points to product adoption. So change resistance, I think you touched on. It's a big one. But what are some of the other barriers that you've noticed when it comes to getting end users to adopt after, especially if they've been using that spreadsheet for a long time and they're feeling pretty comfortable with it?

George Brooks:

It's funny, actually. And like I said before, I think one of the biggest challenges is that you would think efficiency is a value prop. And efficiency might be the value prop to the top line or to the leadership because they're thinking, how can we get more done for on the hour? But again, a lot of these organizations have been trained to fill out hours. So ultimately, one of the biggest challenges that I see is that we'll say, Hey, this could save you 10 to 15, 20 to 100 hours. And they go no, don't do that. That's 100, 100 times whatever our hourly rate is. So what we have to do is spin it to say, Yes, but you could charge a premium on that hour. Right? So you could still have a value-based hour or a value-based fixed price in some way, or maybe a lot of organizations, especially service organizations die on the relationship and the margin. Meaning they will cut through margin and just like lose money at the end of a project just to keep the relationship. But what if you didn't have to keep cutting into the margin at the end because you are more efficient and more effective and you had a little maybe buffer of hours, because you had tools that help you to be more efficient. So I think that's a big thing that I've just been so surprised as we go deeper into the service world specifically, especially enterprise services, because we're talking about whatever I'm talking about with one person now times that times 10,000 employees, right? And the biggest thing is this aversion to efficiency. Like you said, change is probably the other big one is that ultimately people get into their habit routines. They know what works for them. They don't really want to adopt a new way. And so you have to do this kind of economic value of saying, Hey, do we need to change everything all at once all the time? Right? Instead, can we go, no, this is a way that we can introduce a new feature. Let's wait a little bit. We'll roll this out or we'll roll it out with a select group before we roll it out with the whole department before we roll it out with the whole division. And so there's a change management workflow in that. But ultimately what I found is if you have an ambassador group, if you have a group of people that helped you from the very, very beginning, like we talked about earlier, a lot of that goes away because then they're just like, y'all, come over and look at this. We made this together and they're really excited and they're happy to champion it.

Hannah Clark:

So I'd like to spend a couple minutes talking about culture shift, which you mentioned in the past is a key challenge to sort of productizing, I'm using air quotes, service-based firms. And what does that look like from your perspective? And what would you say is some one of the interesting lessons that you've learned working in that capacity?

George Brooks:

Yeah. I mean, I think the reality is again, it goes back to people are thinking about how do they bill out of the hour? How do they build out the services and exchange service for some type of monetary value? What you're shifting people towards when you start saying, Hey, either we want you to become a product enabled service, which means we want you to be more efficient with tools. Or there's a possibility that you could take your knowledge, you could take what you know or what you do, and either turn it into a piece of technology or into a knowledge base that you might sell, and then you could actually scale, right? So now you can go one to infinite, right? Or one to many multiples of X. And I think that that's a shift because now you're less focused on figuring out how to work together to make sure the customer and clients happy on this kind of next call, and there's a rhythm to it and everything else. And now you're saying, how do we communicate with a much broader audience? How do we support a much larger client base? And what we find is that when folks are going from being a service company to a product enabled service or a product company, and they're productizing some of those services, the thing they're challenged with is what used to be done on a handshake, even if it's a kind of proverbial handshake, but what used to be done in a handshake is now done through a transaction. And that's an uncomfortable ship culturally for them to go, I'm in the relationship business. I don't know how to accept that person is a, a data point on my user base. And so there's pros and cons to that, right? Because the pro is that actually they probably care more about their users than a lot of product companies do, right? Because they've been serving customers for a long time, so they know what it means to serve customers. The con is that they don't know how to handle the scale of it and it intimidates them. So ultimately what ends up happening is there's a breakdown and kind of their approach to how they can handle that. The other thing that we see a lot is that service firms tend to work in departments, meaning you have the design or let's take architecture, engineering, construction. You have the design team, the architecture team that's designing out a plan for a building or for a school or for, a power plant, whatever it is. But they're designing it. Ultimately, they take those designs and they put it over to a pre construction planning tool or an engineering team. And then they go through and they do their pieces. And then ultimately that gets handed out to a workforce that then plans out all the subcontractors that are going to do that. So they're used to going, my phase is here, I hand it off, and I'm done, I go on to the next thing. Ultimately though, in a effective product culture, it's usually cross-functional work. Because you're iterating on the product, you're refining the product over time. It's that iterative nature, that agile nature, if you want to call it that, that can feel juxtaposed to, I do what I do and I hand it to the next person. It's an assembly line approach. The cross-functional work is new for them. And oftentimes, they were told literally, do not waste time talking to the engineers. Don't waste time talking to that other department. Instead, do your thing, keep your head down, and go on to the next task. So now what we're saying is, no, sit right next to the engineers, right? Sit with a product manager who's going to collaborate with you to connect the business, the technology, the user experience needs. And so this cross-functional nature is unusual for them and sometimes is juxtaposed to the culture or to the norms of the way that they work.

Hannah Clark:

If you can maybe frame this with an anecdote, like, can you illustrate how this has worked in practice? Just curious how you've seen this play out in a client interaction and what the outcome was.

George Brooks:

Yeah, I think the best example, and again, I won't name names, but we were working with a local firm here, it was a finance company. I was giving a, an update about how to think about cross-functional work, and I was saying, yeah, y'all are building some incredible technology. But let me ask you a question, design team over here that's been thinking about what this could be. When was the last time you sat next to a developer, or talk to a developer? And they go, Oh, we're not supposed to. I was like, well, who said you're not supposed to talk to the developers? And they went, well, I don't know anybody said that I wasn't supposed to. I just, we just don't. Then it goes back to that permission. People make up these rules or these narratives that really maybe don't have any basis, but it's the way that they're processing their reality. And have you ever seen the studies where one person is in a room with everybody sitting on chairs, right? And then one person just starts standing up every time a bell goes off. And they stand up, and they sit down when the bell goes off. And then all of a sudden, the person next to them, nobody says anything, and they go, I guess we're supposed to stand up when the bell goes off, and then they sit down. And ultimately, at the end of it, everyone in the room, when the bell goes off, stands up, and then sits back down. And there's this like echo chamber where we just start to follow along with the way it's always been done. But nobody says, what if we didn't do it this way? What if we started saying, designer, go sit with the engineer. Product manager, you don't sit up on an ivory tower, you come down and talk to the user. And how do we get these people closer together on a daily or at least sprint-by-sprint basis, rather than again, throwing things over a department wall.

Hannah Clark:

Yeah, it's interesting that analogy sounds like how many corporate cultures sort of form over time. It's just bell ringing and people standing up, but and it points to like just a requirement to be more deliberate with the decisions that we make when not just forming a culture, but also, I guess, shaping it as it's already becoming more mature.

George Brooks:

Well, and I think it also plays into, it has to come from the leadership, right? The leadership has to invite this idea that we want everyone to contribute to making the organization, the team, the product, the solution better. And if you start with this framing, we have this framework that we use that we refer to as postures, disciplines, and structures. Postures are those principles, those things that are true that you put together. It might be your mission value, those pieces. For me it's often I say we're in the business of people. We just happen to design and build software, right? And so it's these principles that guide you. It's the way you think about your work. We talk also here about the fact like assume you have permission. Because people just assume, well, I don't have permission to do that. It's like, who told you that? But when was permission taken away from you? And then since there's principles, the disciplines are like how you live those principles out. What are your ceremonies? What are your routines? Do you do stand ups? Do you do retrospectives? Do you do sprint planning or backlog grooming or these types of things that are fine? But why do you do them? Do they connect to a principle? Do they connect to a way, a reason why we work this way? And then ultimately, structures are really to say, okay, now how do we connect these dots? What tools are we using? So are you using a backlog management system like Atlassian or Jira or something like that? Do we allow people to be structured in a cross-functional teams? Does the structures of our week time effort allow us to better do our ceremonies or disciplines that then support those postures or those principles? This framework really helps us to go, Is it a principle issue? Is it a posture issue? Or is it something where we go, Oh, you know what? Actually, we just need to, we need to rebuild our structures. We need to allow ourselves to rethink the or rewrite the script, not all the time, but maybe rewrite the script every once in a while to open up permission for people to think in a different way.

Hannah Clark:

I love that. So before we wrap, I just want to bring this back to user research, which is something I think we're all trying to do better in some way or other. What would you say is the single most valuable user research tactic that you've used in terms of ROI, just in terms of raw effort and output that most of our listeners should be able to adapt for their own product discovery and development initiatives?

George Brooks:

I think something we actually stole from somebody else a few years back is, there's this, we all have personas for our user research. I like the idea of giving your persona a name, and that name actually is a real person, right? And so, ultimately what it's about is we try to create these kind of common denominator views. So, I believe all users like this will be like this. And that may be true to some extent. That's, I guess, in some ways it could be stereotyping. And I don't think that's a great idea. But ultimately, again, it's about if you get closer to your user and you actually ask them some maybe personal questions or some questions that better understand the reality or the context in which they're doing their work or the context in which they're using your product, or the way that they're going to interact with your company, then you start to go, I know what is your incentivizes you. I know what you're afraid of because a lot of what we're dealing with is reducing fear. And then ultimately I know what you're dreaming about or what you want to be one day. And if you can allow your product to enable people to shift from fear to this place of what I want to be one day, that's a really awesome opportunity because that's when technology can leverage a larger conversation. But I don't think that's possible unless you, I wanna be careful with the word intimately, but if so your user really well. And I think that it doesn't have to be a large group. But if you do not sit down and go, what's your name? Tell me a little bit about your day. Do you work from home or are you going into the office on a regular basis? Are you using Windows or Mac? And these are not like technical questions. These are like, I know what the constraints of these different platforms are. How often do you open a spreadsheet? How do you communicate with your peers? It's these basic questions that then build up to, okay, now let's get specific. When you're writing an estimation for a 35 story glass building, what does it take, right? And you're building up to this context where, so I think that, I don't know, I just, I find it in user research, people try to do it in like this really broad strokes instead of getting down and knowing the person. This is why I say we're in the business of people, we just happen to design and build apps.

Hannah Clark:

I absolutely love that approach. I think it is so important to be that because it's the only way that you can really understand the nuances of the people who are using your products and then you can develop much more complex personas. Absolutely love that idea. Okay, well George, thank you so much for joining us. That's our time. But where can people follow you online after this?

George Brooks:

Yeah, I mean, LinkedIn for sure, George Brooks, Crema. There's another George Brooks that is a saxophone player, not me. And then check out Crema, Crema.us.

Hannah Clark:

Awesome. Well, we really appreciate your time. And this has been a really fun conversation, so thanks so much.

George Brooks:

Such a pleasure, Hannah.

Hannah Clark:

Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The Product Manager, wherever you get your podcasts.