In a world where products are plentiful but genuine customer focus is rare, how do you build an engineering org focused on customer needs?
Embark on the 4th chapter of our series on the Career Journey of Engineering Leaders as Dev Interrupted host Dan Lines sits down with the talented, Bhavini Soneji. With a wealth of experience spanning over 25 years and pivotal roles at places like Headspace, Heal, and Microsoft, Bhavini has meticulously honed her approach to creating engineering orgs that prioritize both product innovation and a deep-rooted customer focus.
Listen as Dan and Bhavini unravel what it truly means to be 'customer-obsessed' as well as the secrets to maintaining that fervent customer passion well beyond a product's launch.
Episode Highlights:
- (3:30) What does it mean to be customer-obsessed?
- (5:00) Fostering a culture of customer obsession
- (12:00) Aligning KPIs
- (19:00) Translating business goals to the eng team
- (23:00) The importance of resource allocation
- (30:00) Sustaining customer obsession after product launch
- (37:00) Bhavini’s advice for engineering leaders
Episode Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Dan Lines: Welcome back to Dev Interrupted. I'm Dan Lines, LinearB co-founder and COO, and we're thrilled to be continuing our series on the career journey of an engineering leader with Bhavini Soneji, 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.
Bhavini Soneji: Thank you so much, Dan. First of all, I just wanted to say thank you for LinearB and you for bringing this amazing outreach and helping all us engineering leaders and engineers to get better at a craftsmanship and to remove all the voodoo from driving execution efficiency by having it backed with data and tooling. Really appreciate, what you and your team has been doing and continuously, paving the way at it.
Dan Lines: 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, you have various positions ranging from CTO to VP of Technology, 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 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?
Bhavini Soneji: For 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?
Dan Lines: I 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 where more customers, obsessed. Some of them, I felt like it was really hard. I felt disconnected, 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 yeah, just go build this thing, but, do you have any like tricks that you use or when we can bring it into the life cycle for engineering?
Bhavini Soneji: Yes, I think there are, two parts, to your question, Dan, one is, 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, 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. all the way 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. It means using customer feedback to refine ideas and validate solutions at each stage of the product development life cycle. What does that mean? So let's go into kind of, the, some of the faces and what are some of those levers 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.
The 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, your quantitative and qualitative KPIs are being met, with the specific. Persona, but also outside of that specific persona, because 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 to customer, 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 Suite. And then you won't believe 90% plus of those, FeatureRs were already in the product.
But it was, the challenge was the discovering for people to discover and use it. And 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.
Dan Lines: 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 during that requirements phase, especially if you're like an engineering leader.
Pay attention to this, start baking in the right questions that your team leaders should be asking. And 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 an onboarding flow? So are we measuring the different stages of activation? When you start asking those types of questions in the, like requirements phase, now your engineering team.
I think can have the right mindset of, okay, what, why am I building this thing? What is important? So that like 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?
Bhavini Soneji: So plus one, to that one, because, you won't believe how many times 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 saying? 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, so the KPI itself is buggy. 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, we are validating. Some of these KPIs as well along the face, not just the product capabilities.
Dan Lines: Yeah, that's really true. Any time 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, and I'm so happy that you brought up the journey of it. Cause that's the same experience that I have, but the journey is actually like they say, I think there's like some saying like the journey is the reward.
And what I mean by that is let's say that you set up a KPI. around, like a successful, look at a feature whatever the KPIs, 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? And 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.
Bhavini Soneji: 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 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? And one of the other things that you mentioned 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 following that and we saw the friction and 30% uptake.
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.
Dan Lines: Yeah, that makes sense. 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 requests. So 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.
DollarsRetained, PipelineGeneration. 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? And for this quarter, 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 CEO you're helping them say.
Hey, measuring the 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.
Bhavini Soneji: Yeah. And, to build on that, Dan, there are two aspects to it, right?
One is how do you make sure that every work that you're doing is tied back to the, 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, the latency that the user is seeing will improve by X amount, which means that, the drop off that we are seeing will be better or the customer Be better.
Which means you will, be able to drive this other, engagement, customer engagement or customer acquisition. So there is a way to dive, connect the dots. So it's really important to make sure that. Every investment is quantifiable, and tied back to the bigger goal. And 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, the silos happening, that product is I'm just caring about the features. And if there's something else that you guys are doing improvement on the engineering side, you can do it if time permits. But 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 strongly 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 north star 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. And 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 up 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.
Dan Lines: 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 types of roles, marketing. And. 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 engineer, engineering leader. How do I relate all this amazing work that the engineering team is doing with product back to business goals? So let, that's like the context. Let's dive in there. What are some of the things that you have done?
Cause you talked about this hierarchy of taking the business goals and then translating them down. Is there certain ones that are like, that you usually do? Is it like, things that have to do with revenue or retention or like, how do we do this? Can you give us an example?
Bhavini Soneji: 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, in all of them, the common piece is revenue, right? Now, the revenue would be coming from different aspects. 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 iteration as well, right? Iteration doesn't, customer iteration doesn't come out free.
You have to then focus on making sure building the tech to make it easy for them to get discounts during iteration, et cetera. So it's being in partnership with the finance to model what is, 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?
The 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. So 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 then third aspect is the operational cost, right? How do you bring some of these operational costs? And this is with, 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? How are you seeing where the, cloud spend, etc.
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 the tech depth, etc. So having this is. Thank you. 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 become, 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.
Dan Lines: I love the way that you described it with the investment and relating the investment back to what the business cares about. Actually, one of the, most exciting and newest views that we now have in LinearB 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. And 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 the signup 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 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 brought up this. Idea of efficiency, because a lot of the times you'll get asked from your CFO or like a finance person, Bhavini, we have, 20 million worth of salaries under your control. What'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. And 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's, that is a business alignment conversation. That's going to gain you trust, get you connected to the business. That's the way that I've seen the LinearB community doing it now.
I wanted to run that by you. Cause I think that's exactly what, how you, what you're saying.
Bhavini Soneji: Totally. I think it's, 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're not knowing what are the key things.
And more and more with LinearB 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 in when driving operational and engineering excellence, right? People are like, what should that KPIs 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 surface 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, 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 people would not even use it consistently, so we wouldn't be able to measure it. So start using it and then we can see, okay, how can we get better at unblocking people and, being more proactive in, asking and coordinating those dependencies and, handoffs, but, plus one to you on the.
on the investment and the value prop. Yeah. 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.
It 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 don't have to just play.
Flip flop constantly in, shifting, resources and prioritization.
Dan Lines: Yeah, I think we've nailed it here and I, 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 and 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. Usually 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 cause 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 settings, 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, so I'm going back to, okay, we have our success KPIs, maybe we're measuring retention. Maybe that's that activation flow. Maybe it, whatever it is. Now that features release first time, how do you keep that customer obsession going?
Bhavini Soneji: 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 you're 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.
At the same time, as new things come about or new capabilities, It might tie back to, the old feature might get impacted and how do you take a look at those existing other KPIs as well to see what's the impact and how things should be, cross corrected, moving forward. And at the same time, the big piece, after launch, which you might not see immediately until there is enough momentum picked up on the usage is how is the discoverability?
How is the user education looking like? How is it being used as we had intended to see it used? As well as, how is it performing at scale and speed? Because it might be that as the volume picks up, a feature might, start seeing cracks that we hadn't tested enough or, that we are now seeing bogged down.
So all of these things are important to keep that metrics and view to see that the feature, you can't just say done and forget and, let's move on to the next thing. All of these pieces needs to be continuously looked at, and, making informed, decisions accordingly.
Dan Lines: You know what I think the hard part is thinking back to when I was an engineer and it's like you're, you've worked so hard to get that first release out.
Usually, so you get the first release out and then you're iterating, but usually that first one, there's that activation energy. Because you're creating something from scratch and you get it released. And there's almost, at least for me, sometimes a feeling, and I'm not saying it's a good one, but it's like, Oh, my job's done.
Like I got this release out. But really that's when the first time you're going to start getting that customer feedback. So do you have any tips of how to keep engineers engaged after that first launch and excited? I think that's tough.
Bhavini Soneji: Yeah, and I think, Dan, I am starting to see more and more the industry has shifted, right?
There used to be that waterfall model where you work for so long and then you get the launch out. And nowadays, that's the whole mindset shift, right? Where... We want to start smaller and build on that, so it should be that ideally, again, I'm not saying that there are cases where you need some of the, all the pieces in place before a customer can see the, and feel and get to use it, but more and more, what is the most minimal investment and most minimal viable product capabilities?
That we need to get out because this is exactly what to your point that the first idea is not what shapes the product or the first release is not what shapes the end product. So many times we've seen things morph into something else because as you get it out, as you get input, as you ideate, You realize sometimes the problem scope changes, you realize sometimes the solution needs to be adapted.
And that's where keeping that curiosity, keeping that, open mind becomes very critical. And to your point, some of the tips... That workout is A, actually shadowing the customer, right? And sometimes it's not easy. I'll tell you some of the tips on when you can't completely dog food yourself.
What does that mean? But, shadowing the customer, we used to, uh, do it , in some of the cases at Heal where, the doctor, persona, we had the engineer shadow the doctor persona at the field trips and how the things were getting used. And then the engineers would come back and fix bugs on their own because now.
They know how things are being used, what are the challenges in the field versus the pristine, it's not reproducible on my dev environment, and being able to apply that learnings proactively. So big on that customer shadowing, and this has to be as a process, as a repeat activity that the team weaves into it.
And this way you're not just seeing the shadowing for one particular feature, you're seeing. What the customer is doing, how they're using the overall product, at which pieces, at what decision making, etc. And doing that every quarter or based on your, pattern that is flexible is very important.
The second aspect is also around, the customer, tickets, right? Shadowing and seeing what is the analysis from the customer support team. And this, as we expand in today's day and age, it's not just the customer support tickets, but it's also app reviews, in case you have an app review, or feedback mechanisms, or a community groups.
So basically seeing what is the voice and feedback that we are hearing from customers, being able to present that in all hands settings or being able to, bring that at each of the quarterly planning meetings, et cetera. And then, the other one is, around, you mentioned.
What if, the product is not something and in today's remote age, people are far away, they might not be closer to the customer, et cetera. So what is, what can be done for that is what we do is we, broadcast the thing. And that way, whoever is shadowing is broadcasting all of that. So the other people, even if they're not physically there, they can see the things and they can ask questions.
And this way, when we are broadcasting, people see, oh, this tool they're using with this particular other. And oh my gosh, they have to use five tools to stitch up this particular, use case of theirs. And this way people can see the ecosystem, they can see where the frustration or the, how the usage is versus what it was, intended to.
And that becomes, very helpful. Making sure that some of this is weaved into, the life cycle and day to days of your, rituals of the company becomes, very crucial.
Dan Lines: Bhavini, thank you so much for sharing all of that. We hit many topics here and the time has went by super fast. for the leaders of engineering listening, if you had to summarize either one main point or one piece of advice out of everything we talked about for them to take away, what would you like to call out for engineering leaders that's most important from this conversation?
Bhavini Soneji: Thanks Dan for, having this, amazing and, very engaging discussion. It's definitely very close to heart for both of us. In summary, I would say as Peter Drucker quotes, right? The result of a business is a satisfied customer. So why not start with the customer and make the customer the hero of your story and have resilience to innovate in delivering their needs to meet the business outcome. Stay curious and open to continuous learning.
Dan Lines: Bhavini, thank you so much for coming on the pod today. Now, I know you have a consulting gig going on. You're available to work with, companies, engineering organizations, that type of thing. If people listening want to get in touch with you about that, what's the best way to do it?
Bhavini Soneji: Yeah, so I love nurturing teams and companies and helping them become force multipliers and to scale through the different growth phases. And so taking that passion, I've started my consulting, as a advisor, executive coach, as well as, Fractional, Interim, CTO, VP. And so they can find me at the most common place that people go to LinkedIn/bhavinisoneji, as well as I have my website, https://www.bhavinisoneji.com.
Dan Lines: Awesome. We'll be sure to include those links. If you want to get in touch with. Bhavini. And also before we go, don't forget to check out the Dev Interrupted sub stack for more insights and discussions from top engineering leaders. And if you found this episode valuable, please share it with your network.
Thanks everyone for listening. Thank you, Bhavini.
Bhavini Soneji: Thank you, Dan.