This episode is brought to you by Sprig.
What if your product team knew exactly what to build to achieve your toughest goals, like increasing conversions or boosting engagement?
Meet Sprig, a product experience platform that generates AI -powered opportunities to continuously improve your product at scale.
First, Sprig captures your product experience in real -time through heat maps, replays, surveys, and feedback studies.
Then, Sprig's industry -leading AI instantly analyzes all of your product experience data to generate real -time insights.
Sprig AI goes even further with actionable recommendations for driving revenue, retention, and user satisfaction.
Join product teams at Figma and Notion by uncovering AI -powered product opportunities at scale.
Visit sprig .com slash the product manager to book a demo and get a $75 gift card.
This is embarrassing to admit.
But whenever I think about product adoption, I think of the 1996 hit movie Matilda, adapted from the 1988 role doll 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, this honey who's so taken by her abilities that she, presumably, can't picture a life without her anymore.
Now, if I hadn't lost you in this metaphor yet, your product is Matilda, and your product team is 6 -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.
Such a pleasure, Hannah.
Good to see you. Yeah, you too.
So can you tell us first a little bit about your background and how you got to where you are today?
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 of 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 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.
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.
Wow, that is quite a journey.
And I hope everything turned out well.
She's 17. I've had three teenage girls right now.
It's the best. OK, fantastic.
OK, well, we'll be right on you.
Sorry about that. That's OK.
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 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?
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 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 blitz scaling, take the Reed 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 for 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.
Yeah. And when you say we, I love if you can give me a little bit of a rundown of Kremma specifically and kind of how it gives you a unique view into the challenges around product adoption specifically.
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 Kremma grew, we started to take on more roles and responsibilities.
So I 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.
The interesting part of that is being still focused on UX.
A lot of traditional firms might have an I .T.
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 a 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.
And that actually is a perfect segue into my next question, because one of the things that we've chatted about before is irony of how a lot of product teams just aren't very close to their users.
But even in the position of working very closely, obviously, with the end users 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 lifecycle.
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 and not your own little pretty spreadsheet.
But ultimately, that becomes a personal 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.
We'd 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 to 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? You know, all these factors that go into now.
You can trust me. Let's start talking about building you a tool that's going to 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, you know, 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 it and what 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?
We'd love to talk to them and learn more about their lives, their 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.
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 an interesting space.
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.
You know, 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 SAS 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 can do that for you, but you just you said, no, 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 to say, yes, this might be a change for you, but that change might actually create new habits, new routines, new disciplines that 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, you know, 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, OK, 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 where 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.
This episode is brought to you by Sprig.
What if your product team knew exactly what to build to achieve your toughest goals like increasing conversions or boosting engagement?
Meet Sprig, a product experience platform that generates AI -powered opportunities to continuously improve your product at scale.
First, Sprig captures your product experience in real time through heat maps, replays, surveys and feedback studies.
Then Sprig's industry -leading AI instantly analyzes all of your product experience data to generate real -time insights.
Sprig AI goes even further with actionable recommendations for driving revenue, retention and user satisfaction.
Join product teams at Figma and Notion by uncovering AI -powered product opportunities at scale.
Visit Sprig .com slash the product manager to book a demo and get a $75 gift card.
OK, 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 of 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?
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 it will say, hey, this could save you 10 to 15, 20, 100 hours.
And they go, no, no, no, don't do that.
That's 100, you know, 100 times whatever our early rate is.
So what we have to do is spin it to say, yes, but you could charge a premium on that out.
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 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 the little maybe buffer of hours because you had tools that help you to be more efficient?
So I think that 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.
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 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, yo, come over and look at this.
We made this together.
And they're really excited and they're happy to champion it.
So I'd like to spend a couple of minutes talking about CultureShift, 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?
Yeah, I mean, I think the reality is, again, it goes back to people are thinking about how do they build out 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 can actually scale.
Right. So now you can go one to infinite, right?
Or one to many multiples of X.
And I think that 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 shift culturally for them to go, I'm in the relationship business, I don't know how to accept that that person is a, you know, 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 that 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, you know, 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 to our 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 kind of going, my phase is here, I hand it off and I'm done, I go on to the next thing.
Ultimately, though, an 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 kind of 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, 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.
If you can maybe frame this with an anecdote, like can you kind of illustrate how this has worked in practice?
Just curious how you've seen this play out in a client interaction and kind of what the outcome was.
Yeah, I think the best example and again, I won't name names, but we were working with a local firm here, was a finance company.
I was giving kind of an update about how to think about cross -functional work and I was saying, yeah, y 'all are you 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 talked to a developer and they got, 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.
And 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 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 the bell goes off and they stand up, they sit down with the bell goes off.
And then all of a sudden the person next to 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 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 races rather than, again, throwing things over a department wall?
Yeah, it's kind of interesting.
That analogy kind of sounds like how many corporate cultures sort of form over time.
It's just bell ringing and people standing up.
And it kind of points to 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.
Well, you know, 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 kind of 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.
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 when was permission taken away from you?
And then so 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 back all 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 that a reason why we work this way?
And then ultimately, structures are really to say, OK, 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 and across functional teams?
Does the structures of our week time effort allow us to better and 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, you know what?
Actually, we just need to we need to rebuild our structures.
We need to allow ourselves to rethink the 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.
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?
I think something we actually stole from somebody else a few years back is there's this, you know, 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'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 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 want to be careful with the word intimately.
But if you know your your user really, really well.
And I think that it doesn't have to be a large, large group.
But if you do not sit down and go, you know, 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 OK, 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 to where.
So I think that I don't know, I just I find that 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.
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.
OK, well, George, thank you so much for joining us.
That's our time. But where can people follow you online after this?
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, C -R -E -M -A dot US.
So Crema dot us. Awesome.
Well, we really appreciate your time.
And this has been a really fun conversation.
So thanks so much. Such a pleasure, Anna.
Thanks for listening in for more great insights, how to guides and tool reviews.
Subscribe to our newsletter at the product manager dot com slash subscribe.
You can hear more conversations like this by subscribing to The Product Manager wherever you get your podcasts.
