Product Manager at Blend
The Distinction between B2B Users and Customers and the Playbook to Scale Both Effectively
Akriti Agarwal: Great. Let's get started. Hi everyone. I'm [inaudible] could be a good while. I'm really excited to be here. I wake up blind where I both products, um, and blend as revolutionizing the consumer lending space. Um, so really changing how people apply for mortgages and open their accounts and apply for credit cards and such. And I'd blend, I've had the pleasure to be in a different variety of roles, which is what happens when you're seeing your company grow six, seven, eight times in a very short duration. So have engineering, product, and on growth. Um, and I've also tried to building different kinds of products like API, APIs, UX products and integrations. Before Blend, I was at Palantir working, uh, on building products for the government, leveraging data. So today, what am I going to talk about? We are going to talk about building and scaling for our products, off our products and for our users.
Akriti Agarwal: But I have a problem. I have a problem that we mostly just talk about users. We don't talk about customers. Users is just 50% of the puzzle when it comes to B2B products. Customers form the other 50% and as a lot of product managers, we have a lot of empathy for our users, but do we actually consider all the needs of our, of our customers? They are very distinct personas and very distinct participants in the entire process of your product life cycle. Imagine a scenario where you've heard of cases where you're very, a product was not bought by a customer because the security person didn't approve of it or the it person had issues with it or if it was a financial product then maybe legal and compliance had concerns with it. There are many instances where users is not equal to customers and the interesting bit here is I want to start talking about customers and use those in my talk and also within each of those sections I want to talk about building and scaling.
Akriti Agarwal: So let's start with customers. What do we have to think about when we, both for our customers, a lot of times enterprise deals, the decision that is being made on whether or not to use your product is being made in a room with a round table of people in that room who probably won't be the end users of your products. They would be the decision makers but probably would never use it and have never seen it before. So we have to consider their needs very distinctly and make sure that we are having a lot of empathy for what they could be asking for. So what would that look like? That could look something like this. Think about mapping every single person who could be in the room deciding whether or not to use our buy your product and what is one single thing that they would care about when making that decision.
Akriti Agarwal: So as an example of one of the products we recently launched, it's I work at Blend, which is a fintech company and we have to always keep in mind consumer lending laws. And a lot of legal and compliance pictures come into that puzzle. So I had to really be very clear with the legal and compliance teams as to what this product would look like and if and how it will cover all of the concerns they had. So this is something I would suggest extremely essential for any enterprise products when you are trying to get your business off the ground and it's not something that you need just to get your foot into the door just to get your product be paid for and be bought. It's needed for every single feature you build. It's needed for every single feature you launch. And it's also needed for every single feature you go from MVP to full scale.
Akriti Agarwal: So it's not just something you do one time. It's a constant exercise as a PM to keep these personas and stakeholders in mind as you are launching your products. Great. So now we've spoken about building for customers. Let's talk about growing for customers at blend. We saw our customers go from a really small handful, number two fifties and sixties customers within a very short amount of time. And what was great was that our customers were obviously growing, but a really big pain point was that our people were not scaling as quickly as our customers. We're scaling, and it's funny, the scaling of the product was the easier part. It was scaling of teams, which was extremely hard, so at blend what we did was we divided our customer journey into three different parts and thought about how we could enable our customer facing teams to tackle that more effectively.
Akriti Agarwal: So what we did was we had the first phase called pre sales and sales. So everything that the sales team does until the contract with the customer is signed. The next phase was implementation and launch. What that means is from the day the class, the class, the contract is signed until you have your first live user. And then the last phase was post launch, which was going from one user to 100% users. Also maintenance of existing relationships and also continued rollout of newer products and newer features that were coming in the early days. What we did was we had a roll called deployments lead, which is one single person who's responsible for everything after the first step, so everything from launching to the way of full roll out and continued newer futures. It was great for some reasons, the reasons where it meant extremely high touch customer service and a lot of contexts for that customer was sitting in this person's head.
Akriti Agarwal: So we knew that all edge cases were covered. It also meant that we were able to have people work on one or two deployments and scale them pretty effectively. However, it had a lot of problems. The first biggest problem was that these people were working in silos. They had no idea what two other customers and to other deployment leads were doing, and that also meant that they were reinventing the wheel every time a customer was requesting something because there was not much sharing of knowledge. So what we did is what I call the law of increasing returns instead of diminishing returns. What we did was we brought that deployment, Reed lead role into three different roles. We had a team now comprised of a deployment lead of an account manager and a customer engagement manager. What do we do? What do those roles mean? Deployment lead is someone that is responsible again for implementation.
Akriti Agarwal: The day the contract is signed until the first live loan or the first launch with a user account manager then comes into the picture and is responsible for increasing adoption of that product and rolling out the product to the entire country or the entire world if it is a global product and then customer engagement managers were these people who were extremely well versed in the mindsets of the users and could step in and step out where they were needed for training purposes and the beauty of that model was that these teams, especially the last one, only had to prepare content once and now they could start using it across different customers rather than having to reinvent the wheel every single time. It also had many other benefits. By having this model, we really made sure that the people who were working on these deployments in these roles had a machine out of it.
Akriti Agarwal: We were aligning their skillsets the best with what they were good at. It helped us ramp new people really quickly and it just had better employee happiness because their skill sets were very well aligned with what their phase of the project was. Secondly, it also helped these deployment leads and account managers work on not just one or two but four or five deployments. So now they had more sharing, more context and they also knew how an edge case with one customer could actually surface as an edge case in the second customer. And how do they apply these shared learnings across customers. And the third best part of this was we could measure each of these phases very, very effectively. So we had metrics to say time to contract, time to first user time, 200% users, and we could start to predict how fast we actually roll out deployments.
Akriti Agarwal: That enabled us to have a better idea of our recruiting pipeline as well because now we knew how and when we might need somebody to be ramped up on our deployment. So it really, really helped our team scale very effectively. In a short amount of time by just clicking the roles and responsibilities into three, three distinct roles and responsibilities. Great. So now we've learned about building and growing for customers. Let's talk about our favorite part, which was as pms users, right? PMS, as pms, we are required and love to have most empathy for our end users. We, especially in the B to B space, we are really lucky because we get to have easy access to our customers. We can set up time with them, we can understand what they're thinking, we can also iterate with them very effectively on features and as a PM at blunt, I travel a large to spend time with my customers and my users.
Akriti Agarwal: One thing I've learned with all these travels is that their geographies might differ, their work habits might differ, but some things are very consistent. Firstly, users love to tell you the solution. How many of you had had instances where they tell you, can you just put one button here which does this, this, this, this, this, and the story will be over. Or I've also had many instances where users have told me, hey, how could they, if you just build this one thing, I promise we'll all, we'll start using your feature or your product, but that doesn't generally happen, right? Because then the list just keeps growing. And also one thing I've learned in the enterprise space is changing user behavior is really, really hard. Even though these users don't actually have a lot of choice in what products they could use. Sometimes your product is mandated by the company or they might just have one or two other solutions.
Akriti Agarwal: They have a very strong muscle memory and a lot of users have extremely high aversion to change, which is why it's really, really difficult to change user behavior. I actually think of it as being harder than being in the B to B to c space. So what can you do to solve that problem? Couple of typical questions. A second one is my favorite I'll come to that is the first question you could ask is why is this important? When you're talking to your users, it's obviously possible that they'll tell you all the a hundred reasons why it's important. But what really makes the point tip for me is when I asked them for data and sometimes they are surprised because they don't know or sometimes it actually makes them paying as to what they're requesting could be as very specific edge case or a customization.
Akriti Agarwal: As an example, recently I was with a customer, I was with a user and he kept insisting how this specific workflow is absolutely required for him to do his job in plant. And then when I asked him how many of his loans were getting affected by this workflow, and then when I looked at that number across the entire customer landscape, it was 7% loans. Definitely not enough of a compelling reason for me to have an engineer spent of time on that feature versus another feature which was affecting 70% loans. So again, sharing that, asking for that data, first of all from the user gets them insight into how you are thinking about the features and also empowers you to tell them no. In a way that seems very reasonable because you have data that proves out why you should not be building that specific feature.
Akriti Agarwal: Second question is my favorite. You know a lot of times we ask, okay, let's let's build this. It'll be great to build this, but when you ask users what would happen if you don't build what they're requesting for, you will get really amazing answers. I use this as my secret weapon because what happens are two things. Firstly, it really challenges them to think about possible workarounds, which they might not have thought about because they were so fixated on asking for that feature for you to build it. So this are thinking, oh actually yeah I could, I would do this or I would do that and it's not that bad so I could actually get my job done. It also helps them understand that you don't, especially at Blend, we don't customize our product. It's a SaaS product. We allow our customers to configure it by our feature flags to allow for different workflows, but we don't customize it and especially in the enterprise finance space, a lot of users are used to custom build stuff for them.
Akriti Agarwal: So by asking this question, it really removes that layer of customizations. They get really creative with what they could be doing and it starts to separate the must haves from the nice to haves. So it makes my job easier by just asking this question of my users. And actually one thing that we've learned over time by asking this question is also empower our sales team and our client facing teams to ask this question for any requests they get from their users. So although the almost like a filter that gets in place before it comes to a PM. So I don't have to then go ask this question of all the different features that are coming my way, my way now we've spoken about building for users, let's talk about growing users and as I mentioned, enterprise space, it's, it's hard to change user behavior even though they are actually, it's probably also a big reason for that is we kind of accept the fact that enterprise products can be pretty shitty to use and we'll tolerate that.
Akriti Agarwal: We would not tolerate a five second download time in our, on our consumer apps, but we will be okay to go get a coffee while we're waiting for this application to load or for this thing to upload. Right? So we have extremely high tolerance for shitty things in our work life, which should not be the case. So still it comes back to the point that it, that actually acquiring and retaining users in the enterprise space is very, very hard. So what things have have been learned at blend in the last couple of years as we've grown from three or four customers to hundreds of customers, the first thing we learned was for acquisition of users. What we did was when you were launching our product in the earlier days, we were just ask our customers to be like, Hey, can you choose a random bunch of people who would pilot our product?
Akriti Agarwal: Random selection just told our customers, hey, can you choose a group? They would choose based on time zones, on locations, on their familiarity with their teams on oral and just people saying, Hey, I want to help out with this project. What we saw over time was that with this model we saw very different results of success across different customer pilots. Some pilots were going amazingly well and some we just saw them crashed to the ground and obviously as an enterprise product, your foot into the door is one thing, but getting adoption is extremely important. Otherwise, next year when the contract is over or if there's an outage clause in the contract, you will be out in no matter of a time. Right? So just having done all the work to get through your get to the door, it's gone. It's gone, wasted. So what we learned was that we saw some of our customers do really well in their pilots and some of them do not.
Akriti Agarwal: Over time we realized that there were a couple of really big reasons for that. The first one was that the pilots, which did well had extremely vocal users who were very good at highlighting the concerns and also the wins. So what we learned was that we need to find these people not just by a random selection, but by a couple of things. Firstly, these people need to have be the highest producing loan officers. And I use one officers because that's the users that I build products for. If they have a very high volume of business, they would be interested in trying out new features to help them have more volume. So they have equal stakes in the product as you because they want to make more money as well. Secondly, these people should be excited about technology and should also have an appetite for change.
Akriti Agarwal: They should be okay here and there. If there's a bug, they should be okay with us reaching out to them and iterating with them on a specific feature or product. So that was again, something that we highlighted as a requirement for us to choose this pilot crew. And then last thing is if these users start to love your product, they become great spokespersons for your products. And actually it's not a great job for of me as a pm if I go tell all loan officers in America how they should do their job. But if another loan officer is telling them how they can make more money, have more business and do their job better, they are more likely to listen to that loan officer then this tech person who just think things technology is gonna save the world. Right? So we've also seen that by having these people be very vocal and become spokespersons for our company, the adoption of the product was way better.
Akriti Agarwal: What about retention? Acquiring is one game, but retention is equally hard, right? People might use your product and then this pilot group might say, actually we do not like the product as much and then you're out of the tower. You have to keep making sure that you get your foot into the door but actually stick around for a long time. As we saw in the growth of plant, we saw that even though users would say, hey, our blend is great, we love the product. We did not see the numbers actually matched the words that they were saying. When we looked at data, it only showed 10, 20, or 50% of usage versus you were expecting it to be 80, 90% what we realized after digging into that is a lot of these users come into the product but then they'll lose leave soon after it because again, muscle memory, muscle memory is hard.
Akriti Agarwal: They in their mind, they know that they should use this new product, but everyone around them is using the old one. They're alone. Teams are using the old one, so their behavior change is not that easy. Now what we did to change that was again, law of increasing the terns loan officers. I assume like a lot of our users are pretty competitive people. They are salespeople at the end of the day, so what we leveraged was their psyche by actually make me fine. The usage of the product as part of our roll out, we had made sure that we had these leaderboards at every single customer, very, very. We were doing a pilot to enable them to see who has done the most volume in plant, who is capturing the most numbers, whose time to close a loan is the shortest. So these boards displayed around the office really inspired these people to be like, Hey, I need to get up there.
Akriti Agarwal: I need to see how is that person doing a hundred loans a month where I can only do 15 loans a month. There must be something here. Also I think in Silicon Valley we are spoiled with all the fancy swag, right? You probably don't take the tee shirts that out there because we have way too many t-shirts, but these users absolutely love the swag. They will do anything to get that power user t-shirt or we, what we also did was we sent out a bunch of mouse paths with keyboard shortcuts on the mousepad so they could start to use a product more intuitively because it's sitting right there as a reminder on their tasks. So just leveraging swag actually was a great way for us to get adoption from these users to. Another thing we did was data. Everyone loves data and it's hard to argue with data.
Akriti Agarwal: What we did was we didn't have comparative analysis as to what their loan volume was and what their time to close the loans was before they started using planned and then after they started using blend and again share that across the entire customer base. So that way again, it was very, very clear as to how they were saving time and generating more business for themselves and their employers and that scope pretty easily again, incentivized us to incentivize other users to start trying the product and actually sticking around in the product. And then the last thing we'll share learnings. This one is actually really, really interesting, especially in the mortgage industry and the consumer learning space. It's so regulated that you start to see overlaps between every fourth or fifth customer that you signed. They start to have similar workflows and what we learned was that aren't share our learnings and best practices from one customer started to apply across customers.
Akriti Agarwal: So we were able to share with our customers how this costs, how this anonymous customer makes a whole lot of money and how they can learn from some of the best practices that these people have over and apply those. So it was collective learning and also enable them to make more money. We also lastly introduced something called customer advisory panels where you would have these highest performing loan officer users. Our power users come into a discussion. It could be virtual, it could in person and again, share what they saw the industry doing, what they learned from their workflows, what were the best recommended tools and practices going forward. So very, very effective. And again, increasing the retention of users and scaling effective usage of the product. Great. So now that we've spoken about customers and users and we've spoken about how do we build for them and how do we scale them, I hope that for each of these four sections you've learned at least one technique that you can go apply in your jobs tomorrow and start becoming more effective and building and scaling. Thank you.
Speaker 1: [inaudible]
Akriti Agarwal: Any questions? Comments?
Speaker 1: Yes. Yeah. [inaudible]
Akriti Agarwal: Yeah, that's a really good question and actually one way that we've crowded at blend is I will also have a call right before I start on string that I would say that change management within our companies is really easy to add because we all move really quickly, but when we come to rolling out these features with our customer base, it's hard. What we've done is we've actually categorized our customers just like the crossing the chasms curve of early adopters, the late adopters, et cetera. We've categorized our customers in four different buckets as well based on their appetite for absorbing these changes. So if you look at medium size enterprises, so there are four categories. The first one is early access. These guys are good with us sending them half broken features. They are okay with bugs and such. The middle category is they want things that have already been figured out by the early adopters and they have been sort of like tested a few rounds.
Akriti Agarwal: And then the last one is the most risk averse, the most risks. Um, the least risk taking category, which is big enterprises like the wells Fargo's in the u s banks of the world where everything has been perfected by the time it reaches them. So as a pm we all pms at blend. We think about change management differently for these three or four buckets. And we know beforehand how long it takes for us to roll out features with them. For example, if we know that anything that we are changing in our product needs to go for a review by legal and compliance at this big customer, we will start engaging them three months before we roll out the process or the project. If it's a very small change, we will tell them a month in advance. So what we've done is we've made our release cycles from one week to four weeks, depending on how big the changes are. So we can preemptively define what needs to be done for different types of customers and engage the relevant parties much sooner in the process. Does that help answer your question? Any other questions? Okay. Seems like no. Great. Thank you.
Keep me posted on Empower 2019.