Career Journey 4: Product-Led & Customer-Obsessed | Bhavini Soneji

0:00Hi, I'm Scott Carey, Editor-in-Chief at LeadDev, where we help software engineers become more effective technical leaders. The tech industry is going through some major changes right now, and the skills that engineering leaders need to navigate this shift will be fundamentally different to those that you've mastered over the last decade. LeadDev is here to help you identify emerging best practices and keep up with the pace of work in a world where you're going to have smaller teams and fewer resources to throw at problems. Our carefully curated conferences in Europe and the United States support engineering leaders at all levels of seniority, helping them adapt to the new normal, sharpen their leadership and management skills, and be more impactful in their roles.

0:36Join us in Berlin on the 4th, 5th and 6th of December to supercharge your career and improve the velocity of your teams. As we take over the Estrell Congress Centre for three days of world-class talks, practical learning and lots of opportunities to meet other engineering leaders and troubleshoot your biggest challenges. On the 4th and 5th, we'll be hosting Lead Dev Berlin, which helps engineering managers learn from the best in the business. And then on December 6th, Leading Engine Berlin will bring together senior engineering managers for a day of practical, hands-on learning and networking.

1:05Visit leaddev.com for more information and tickets are available now. Last year was a sellout, so get them before they're too late and I'll see you there in December. Welcome back to Dev Interrupted. I'm Dan Lyons, Linear B co-founder and COO, and we're thrilled to be continuing our series on the career journey of an engineering leader with Bhavini Saniji, former VP of Product Engineering at Cruise, also doing some amazing stuff on the consulting side now. Bhavini, awesome to have you on the show today. Thank you so much, Dan. First of all, I just wanted to say thank you for, you know, Glini and you for bringing this amazing outreach and helping all us engineering leaders and engineers to get better at our craftsmanship and to remove all the voodoo from driving execution efficiency by having it backed with data and tooling.

2:08So I really appreciate what you and your team has been doing and continuously saving me at it. Well, thank you so much for saying that. And right back at you, appreciate you being here because you're the perfect person to have on the show as part of our career journey series. You have over 25 years of experience in the software industry, an amazing track record of architecting these highly scalable software solutions that have reached literally billions of users. Before arriving at Cruise as the VP of product engineering, you've held roles at some of these really well-known companies like Headspace, which I was using all the time in LA, Heal, Microsoft.

2:56You have various positions ranging from CTO to VP of technology. And of course, through these roles, you've become an expert at building these customer-obsessed product-led companies. And that's the type of stuff that we're going to dive into today. So, of course, we really appreciate having you on the show. And I will move us into our first topic, which is like, I love the title of this. I'll just read it word for word. It says, Understanding Customer Obsession and Building It from the Ground Up. So Bhavini, what does that mean to you when you're thinking like engineering to be customer obsessed?

3:42For me, customer obsession in this context means a relentless commitment to solving customer problems and providing delightful experiences. It's all about understanding the customer's pain points, desires, and needs so deeply that then you can use those insights to drive the execution towards business outcomes. And Dan, it's both, right? It's quantitative as well as qualitative measurements of impact. And the key over here is to avoid biases and be aware about the know-it-all bias, the conformational bias, the favoring of shiny technologies? And how do you be aware about those while keeping the customer in the forefront?

4:32I totally think you nailed it there. And one of the things, like I've worked for a few different engineering companies where some of them, I think, on the engineering side were more customers like obsessed. Some of them, I felt like it was really hard. I felt like disconnected, I guess, on the engineering team from the customer. Like we would never talk about it. What are some of the ways to bring that customer obsession culture into an engineering org when sometimes it's like engineering is like, yeah, just go build this thing. But do you have any like tricks that you use or when we can bring it into the lifecycle for engineering?

5:12Yes, I think there are two parts to your question, Dan. One is, you know, how do you weave some of this customer obsession into various stages of the development? And the second part is, what are the more specific ways when the customer or the user for that scenario is not directly, you know, mapped to the persona that an engineer can relate? So let me go into the first part. So I think customer obsession should be embedded from ideation or the day to post launch. Sometimes people just think, oh, PM has to do that customer at the start and then we forget about it. No, this is weaving it at every base.

5:57It means using customer feedback to refine ideas and validate solutions at each stage of the product development lifecycle. What does that mean? So let's go into kind of, you know, some of the phases and what are some of those levels that I have seen and that my teams have seen to keep in mind. During the research phase, right, identifying the target persona and customer and defining the problem is important. That time, you want to talk to the customer with the intent to understand the problem and its impact. Next one is the requirement phase where we are defining the what, defining the KPIs. and at this stage, talking to the customer with the intent to validate the problem, its prioritization and its measure of success.

6:47The third phase, which is the design phase, prototyping the solutions for the problem. During this stage, you want to talk to the customer with the intent to validate the ideas, prototype, validate the hypothesis. The sooner you can get this feedback, the more your ideas can be adopted in more faster iterations with least investment. And the fourth phase is implementation phase when you're talking to the customer with the intent to validate the solution. And the post-launch phase is ensuring that, you know, your quantitative and quantitative KPIs are being met with the specific persona, but also outside of that specific persona.

7:30Because now your outreach is much broader. So you might see some of the patterns that were not visible when you were looking at a small segment. And so shadowing the customer to learn whether it's being used the way it was intended, what are the new problems that are surfacing, as well as how is the discovery coming about? Is that intuitive? I know while at Microsoft, we would have a customer ask coming through for feature requests. And this was, I think, for Office Products Week. And then you wouldn't believe 90 % plus of those feature asks were already in the product. But the challenge was the discovering for people to discover and use it.

8:17And so it's not that you've just built a feature and that's done. It's how intuitive it is to discover and drive the adoption. You mentioned a few really good opportunities. I think one of the nice takeaways that I had when you were talking is there's actually a lot of phases where you can start building in this customer obsession. You started with requirements. There's some design. There's an implementation. And for me, what I found is actually kind of during that requirements phase, especially if you're like an engineering leader, like kind of like pay attention to this, start baking in the right questions that your team leaders should be asking.

9:04And I saw that the best engineering teams, they ask questions like, how are we going to measure if the customer is using this? What does doing a good job look like? So for example, does it have to do with increasing our user retention for this feature? Like you said, do we have a problem that we think we have a great feature, but no one's discovering it? That's a different issue. Is this a feature that has to do with like an onboarding flow? So are we measuring the different stages of activation? when you start asking those types of questions in the requirements phase, now your engineering team, I think, can have the right mindset of, okay, why am I building this thing?

9:53What is important? So when you were saying the different phases, that's the one that I would take away the most, those KPIs. Do you agree with that? Is that like a good? Plus one to that one, because you won't believe how many times, right? Just the KPI itself, getting alignment on those KPIs is the first thing because most of us in our journey would have seen this at some point or the other. We launched something and then we realized, okay, how's the KPI say? And then everyone is talking about the KPI and you realize each one has a different interpretation of the definition of the KPI. as well as the KPI was not well understood.

10:36So the KPI itself is buddy. So now you have to rerun the experiment with redoing some of those KPIs. And getting the right KPIs itself is a big journey in itself. And if you are not obsessing about that both quantitative and qualitative aspects and being true, you won't be able to adjust and refine it. So a plus one to making sure that, you know, we are validating some of these KPIs as well along the phase, not just the product capabilities. That's really true. I mean, anytime that I, sometimes you might think, okay, I'm going to set this KPI for the engineering team, or maybe the KPI is related to the product again, like user retention.

11:24And I'm so happy that you brought up the journey of it because that's the same experience that I have. But the journey is actually, like they say, I think there's some saying, the journey is the reward. And what I mean by that is, let's say that you set up a KPI around a successful look at a feature, whatever the KPI is. I like user retention. So how often are users coming back every 30 days or seven days? But what you'll find if you're doing a good job is your team will start asking questions. Hey, how are we measuring this? Why are we measuring it this way? Should we measure it a different way?

12:02And it actually sometimes doesn't even matter if the measurement's perfect. If you can start that conversation, now you know you're thinking in the right direction. Cool. They're thinking about this. They want to know what the metric is. They want to see, is it going up or down? Now you're cooking. That's good. And then there's so many times that even the, how do you provide that structure to the teams, right? So that you get into this repeat fashion because when you're going fast, you just get to that bias and you go on like, oh, we've done this, we know it. And so how do you templatize some of the requirements to know what are the KPIs and everyone being on the same page on reviewing not just the feature capabilities, but also the KPIs.

12:45And one of the other things that you mentioned, right, is some of those KPIs, you would have to start expanding beyond your product. In one of the product when we had launched, we were seeing that we were not having the clarity of the top of the funnel. And that was a big aha moment that there was friction over there. So we started kind of following that and we saw the friction and we drove some of the improvements there, which led to 30 % update. So it's not just, so that's where you have to start seeing some of the bigger picture and expand your boundary or horizon to make sure the dependencies are connecting as well.

13:28Yeah, that makes sense. You know, the only other tip that I have here, so if you're more so like a CTO or a VP of engineering, one, I think, really interesting request. Usually, if you're in that role, like you might be reporting to the CEO or someone that is helping to set top-line company goal. oftentimes a CEO will set top line company goals of like net ARR, you know, dollars retained, pipeline generation. So it's usually dollars based total company growth and things like that. But one thing that you can do, and I've actually seen CEOs be really receptive to this is say, hey, could I partner with you?

14:12And for this quarter of this year, could we have one of our company-wide KPIs be based on usage of the product, or if it's even like an engineering, like speed of the product or making that activation flow better. I think it's really nice when in those town hall meetings or in those goal meetings from the CEO, you're helping them say, hey, measuring this stuff in the product for the engineering org is like a top line goal. and having the engineering team hear that, then they're like, wow, like the company's really listening to us. And I've done that a few times and it goes pretty well. Yeah, and to build on that, Dan, there are two aspects to it, right?

14:57One is how do you make sure that every work that you're doing is tied back to the bigger company goal? And that is really important. So even if someone is having a tech dip, How are you quantifying that, that with this, it will mean that, you know, the latency that the user is seeing will improve by X amount, which means that, you know, the drop-off that we are seeing will be better or the customer experience will be better, which means you will, you know, be able to drive this other engagement, customer engagement or customer acquisition. So there is a way to connect the dots. So it's really important to make sure that every investment is quantifiable and tied back to the bigger goal.

15:47And the second part is how do you make sure that there is shared accountability across different functions towards meeting that customer value prop, right? Because customer value prop is not just new feature. But if that feature is going to have downtime, if that feature is buggy, if that feature is going to be having too much latency, then it ties back to the customer trust. It ties back to the value of the brand being impacted. And this is where I see sometimes, you know, the silos happening that product is like, I'm just caring about the features. And if there is something else that you guys are doing improvement on the engineering side, you can do it if time permits.

16:29But that's not the case. And as leaders, how do we bring this forefront and bridge this gap up front on the drive, on the shared accountability and ownership? And the last one I would say, which kind of is one of the tactics that has worked is, I suppose we believe in this alignment triangle. So what it is, it talks about from the top level, what is the company's mission, vision? What are the key values for the company? What are the stakeholders? What are the not-starved looks like for the company? What are the priorities and goals for the company? And so then you translate that at every level down to your organization and how this ties back to it.

17:14And this can be then brought down more and more distilled at different team level. So you can now see the bigger KPIs as well as you can see the more finer secondary KPIs that each team is doing to tie it back. And bringing this in the forefront during all hands, during team meetings, during quarterly plans or strategy discussions, helps people to bring that collaboration and cohesion towards everyone growing in the same direction. I think let's dive into this because this is actually, I think, a full topic within itself. So oftentimes the engineering organization or a CTO, VP of engineering can feel disconnected from the business or some of the people that you would consider to be a business leader, the CEO, head of sales, customer success, those type of roles, marketing.

18:13and you're sitting at that weekly CEO meeting, and you might feel, okay, the stuff that I am working on, nobody ever talks about, that type of thing. And there's this art that you're talking about, which is, I'm an engineering leader. How do I relate all this amazing work that the engineering team is doing with product back to business goals. So that's kind of like the context. Let's dive in there. What are some of the things that you have done? Because you kind of talked about this hierarchy of taking the business goals and then like translating them down. Is there certain ones that you usually do?

19:05Is it like things that have to do with like revenue or retention? or like, how do we do this? Can you give us an example? Yeah, I think there are a couple of ways to do that. One is ensuring what are the key KPIs for the business. And even over there, Dan, the business might have certain aspects, but working from product and engineering and technology standpoint to help refine that or slice them out is very crucial. So it is a joint partnership to help inform what are those things. And based on the nature of the business, Dan, it could be different, right? If you're driving the consumer business, then, you know, in all of them, the common piece is revenue, right?

19:54Now, the revenue would be coming from different aspects. So how are you driving the revenue through your customer income, right? which is in consumer, it's subscriptions, in enterprise, it's the partnerships and some of the repeat sales that you're doing. And how are you watching out for attrition? The technology investment on attrition as well, right? Attrition doesn't, customer attrition doesn't come out free. You have to then focus on making sure and building the tech to make it easy for them to get discounts during attrition, etc. So it's being in partnership with the finance to model what is, you know, how do you break that big revenue down to see where we are, which levels we are getting and how are we using technology to help in that area.

20:45The second aspect is around the whole operational efficiency, right? The investment on back office. Dan, so many times I have seen where people shy away. They're just looking at the end user, but they're not looking at the internal operators and the tools that are needed for the internal operators. At Heal, we had this need to explicitly influence the need for that internal operations and the product that we built for that, because that was actually the core IP, which enabled to drive the ROI and the efficiency. And that piece doesn't come out easy. People always forget about the investment that is needed there.

21:32So as a leader, how do you look at which are the stakeholders for that? What is the ROI they are spending? How can you partner to build the technology to drive that ROI and efficiency? And the third aspect is the operational costs, right? How do you bring some of these operational costs? And this is similar to what you mentioned at the start, is investing in where is the efficiency for engineers going down? How can we drive that efficiency? Because that means that you're using the assets to the maximum possible. How are you having wasted cycles on features that are not getting used and being able to pressure test them early on with least investment?

22:17How are you seeing where the cloud spend, et cetera, is and which one is having the feature is consuming it, but the feature is not being used, then deprecating. But there are various ways and detect that, et cetera. So having this clarity and as a leadership, bringing this to the table to translate the language of using technology to serve the customer and the business needs rather than just for the sake of technology, it's very crucial for all the leaders to have that shared view of where and how the investment is and where it is needed most. I love the way that you described it with the investment and relating the investment back to what the business cares about.

23:05Actually, one of the most exciting and newest views that we now have in Linear B is called resource allocation, and it shows like your investment carving. And I'll describe what that means. So we now have this view that engineering leaders are using where you can come to the executive team or the CEO and say, okay, I understand that we need to increase our revenue. Are we in alignment? Alignment is the key thing that these two features are the gaps, for example, that we have in order to sell to the enterprise. That's like a common example. We're trying to go up market, sell to the enterprise. And we're going to invest 30 % of our engineering effort there.

23:49And they will visualize it. And then you can say, are we on the same page on that investment level or not? Yes or no. Then you can say, okay, I understand, for example, we have a new demand generation goal. And in order to do that, we need to improve. I'll keep going back to like the sign up flow. Let's say that you're in a PLG motion. we are going to put 15 % of our engineering investment, which by the way, salary, salary wise costs X millions of dollars. It'll show it there. Are we on the same page of that investment? Okay. Yes or no. And the cool thing that we found is you kind of brought up this idea of efficiency because a lot of the times you'll get asked from your CFO or like a finance person, And, you know, Bavini, we have$20 million worth of salaries under your control.

24:44What's the efficiency? I can't give you more headcount unless you show me. And that's where some of these engineering metrics come into play. We actually created this thing called an efficiency pool, which measures waste in the engineering cycle. So you can measure that from like cycle time. There's all these different metrics that go into it. But you can actually come to the business and say, hey, we have about 12 % wasted effort right now. And I have a goal to get it down 8 % to 8 % to give us back a million dollars worth of salary. That is a business alignment conversation that's going to gain you trust, get you connected to the business.

25:24So that's the way that I've seen the Linear B community doing it now. I wanted to run that by you because I think that's exactly what you're saying. Totally, totally. I think it's as you mentioned, Dan, right? What are those levers? And you pointed out really well, right? Again, it goes back to data can overwhelm you if you are not knowing what are the key things. And more and more with LinearP and such communities and tools, it's helping bring that more light into what are the ways to measure and drive that. And having this quantifiable, because I know even when driving operational and engineering excellence, right?

26:08People are like, what should that KPI be? This was a few years back when some of the things were still not completely structured. And at every stage, you might be having certain things that surfaced and for you to go drill into, to go, when we were doing some of the cycle time aspects to get the metric, we realized how, you know, As we dug further into, oh, our PRs are taking too long. How can we bring that cost down? Or one of the other things that we were noticing is the blocks, just like how many times people were getting blocked, training people to start using that because then people would not even use it consistently.

26:48So we wouldn't be able to measure it. So start using it and then we can see, OK, how can we get better at unblocking people and being more proactive in asking and coordinating those dependencies and handoffs? But last one to you on the investment and the value prop, because one other thing that going back to your question around the other stakeholders, sales and marketing business needs to be in tight collaboration with tech and product and engineering. because if they're doing something and if a tech is not brought in, then they're not having the right signals and metrics to drive that impact.

27:32It will just be a halfway rather than a full continuum end-to-end flow. And so having those discussions that, okay, wait, if you're doing this launch with this, can we do this work that will help more? And how do we prioritize the investment in that front versus the others? So it's so much about, especially in companies and more so in startups, your resourcing is always going to be short of resources. I have never heard a leader say, oh, I'm not short of resource. And so how do you make those? And how do you make that trade-off decisions and keep transparency for everyone that this means this is going to be at a pause and we are okay with it so that, you know, you don't have to just play flip-flop constantly in shifting resources.

28:19and prioritization. Yeah, I think we've kind of nailed it here. And I'll do my best to bring it back to the career journey. And I'll try to say it bluntly. I think the difference between an okay VP of engineering or CTO, and an elite or great VP of engineering or CTO is what we just said, aligning the business outcomes to your investments and being able to have that conversation back with your business leaders, that's when everyone's going to say, oh, this person gets it. They are like speaking our language. They know what, and you're going to gain that trust. They're going to give you more. Everyone wants more engineers.

29:04Usually they're going to be excited because they're going to say, oh, this person, I have this open conversation with them. Are we investing in the right things. They're visualizing it for me. They're measuring it. I feel good about that. So yeah, I just wanted to call that out because it's a career journey thing. Now, we've touched on two topics. We started out with when you're planning the next feature and setting success criteria for it. Then we jumped to the business alignment. But I do want to make sure that we round it out because we had a second topic, which will be the third in this discussion, but the second on our topic list was after you get that feature out.

29:48So I'm going back to, okay, we have our success KPIs. Maybe we're measuring retention. Maybe that's that activation flow. Maybe, you know, whatever it is. Now that feature is released first time, how do you keep that customer obsession going? Let's drill into a little bit more here, right? And after launch, customer feedback becomes even more crucial. And regularly engaging with users, analyzing their interactions, and using data-driven insights helps maintain the obsession. And this focus must remain intact during subsequent updates and iterations. Because if we are not staying true to it, our subsequent features might become a Frankenstein because we are seeing it in a silo versus connecting it back to the bigger product vision or to the bigger product strategy.