Transitioning from engineering to product with Adobe’s Anjul Bhambhri

Many roles inside of startups and tech companies are clear: marketers market, salespeople sell, engineers engineer. Then there are the roles like “product manager” that seem obvious on the surface (product managers “product,” right?) but in reality are very fuzzy roles that can be highly variable across different companies.

A few weeks ago, TechCrunch editor Jordan Crook interviewed J Crowley, who is head of product for Airbnb Lux and was formerly at Foursquare. Crowley came up in the consumer product world without a technical background, and he spoke to overcoming some of his own insecurities to become a leading product thinker in the Valley.

This week, I wanted to offer another perspective on product from Anjul Bhambhri, who is Vice President, Platform Engineering at Adobe, where she and her team conceived Adobe’s new Experience Platform for real-time customer experience management.

Across Bhambhri’s more than two decade career straddling the line between software engineering and product, she has worked on deeply technical, enterprise projects at Sybase and Informix as startups, big data infrastructure at IBM, and now at Adobe.

We discuss the challenges and opportunities of moving from an engineering career into product (and management more generally) as well as the ways she thinks about building compelling products that are sold B2B.

This conversation has been condensed and edited for clarity

Scaling out product after product

Danny Crichton: Anjul, thanks for joining us. One of the major initiatives that we’ve been doing as part of Extra Crunch is to interview experts in their fields, talking about how they go about doing their job, and how you think about the decisions that come up on a day-to-day basis in the work that you do. So to start, I would love to talk a little about your background.

Anjul Bhambhri: Very nice to meet you, and happy to share my journey, Danny. I have been in the software industry now for really almost 30 years. I’m an electrical engineer, and basically, my entire career has been in data, databases, and big data analytics.

I worked at Sybase [a relational database company that sold to SAP in 2010 for $5.8 billion] when it was a startup. I was there for almost five years I want to say, and then I moved to another database company, which was Informix.

At Sybase, I was working on the SQL server as an engineer, so still pretty much writing code even as I moved to Informix. Informix had the concept that you could stay a very hands-on technical baseline manager, so I became a tech lead there. Within six months of joining, I never thought I would go into management, but I did as long as they allowed me to also keep writing code. That was always my passion.

I had a small team, but Informix became almost like a $900 million business. It wasn’t that when I started. Then Informix got bought by IBM, and that’s how I ended up there. So, I went from working in smaller companies to now being in one of these really big companies.

Crichton: Across all those different positions, how did you determine what products to work on?

Bhambhri: I think three or four times in my career I’ve gone from running big teams to then becoming an individual contributor, proposing something, and then growing that team and the segment. Then after three or four years, taking on an individual contributor (IC) role again to figure out what the next strategy needs to be.

I guess I’ve joined companies when they were re-architecting or rebuilding what they had built. I have been very close to the metal because in those days, there were no frameworks that you could just go use. You couldn’t Google for an API and then use that API. Everything had to be built from compilers to parsers, and you had to have an in-depth understanding of operating systems and how they function to really build the database system.

I was in IBM for 14 years, taking one year at a time to see if I was still having fun. I ended up building really three new marketing segments for IBM in the field of data, big data tooling, and big data analytics. Then I was pinged by Adobe around 2016. A lot of times we always say no to these things, but I came by. I talked to the folks here. I really liked the people. I felt that they’re really poised for something even bigger and I wanted to be a part of that team to take it to the next level.

Transitioning from engineering into product and management

Crichton: Great. Let me go back in time and let’s talk a little bit about your transition from the pure engineering coding world, which is also my background, into both the management track as well as the more product-oriented track. How did you make that transition? How did you learn the new skills that you needed for the new job? Was there anything from the old job that was helpful or not helpful in that transition?

Bhambhri: Danny, to me it was always very important to understand what we are building, like how is the customer really going to use this? Even after three or four years of experience in Sybase, I remember there was one time where one of our tech leads was explaining a problem which would have required some very fundamental changes into how our database system was built.

It was fascinating for me. You can imagine when you’re two, three years into your career, you’ve not really been exposed to customers — you’ve really been exposed to technology. You’ve done your courses in school, so technology is really what you know and you’re prepared for that. At two, three years into your career, when you start getting exposed to customers who are having these problems, to me that goes, “Wow, this is good to put some faces and names to who is experiencing these problems.”

Crichton: And how did you start meeting customers as an engineer?

Bhambhri: Well, I raised my hand, aware our head of professional services was going to visit British Petroleum in Alaska [to discuss why they needed these fundamental changes to our database]. He was going to visit them because he felt that this was not just a problem of BP, that this was a broader problem.

I don’t know what led me to do it. I just raised my hand and I said, “I want to come with you. I want to hear from the customer directly what is the challenge because we are interpreting things. We are making some assumptions. So, I want to talk to the customer. Do you mind if I also come with you?”

That was the question. My manager was like, “Fine. Go.” They were like, “Are you sure you want to go visit BP, or you want to go to Alaska?” I said, “A bit of both.”

Crichton: Laughter

Bhambhri: I loved that visit. I mean I loved Alaska too, but I loved hearing from the customer and what their problem was.

When I came back, I remember I gave a presentation to the team where I said, “This is how we were thinking about the problems that they have. But when I talked to the customer, here are the other things that are going to come to us in six months, a year from when they deployed it that we did not understand before. So, this is how we need to approach this. This is how we need to build for it, so that we’re going to solve for their needs for the next two to three years.” I think the team appreciated that.

Crichton: What did you bring to the table that the other members of the team did not?

Bhambhri: I think what I brought to the table was that I was able to distill it too. I kind of felt I was put more in those situations along with product management where they were trying to figure out if there’s a pain point, where they felt they needed some engineering presence in those meetings.

What does this mean from a requirement standpoint? What does it mean from a design and architecture standpoint? Because sometimes customers describe their immediate pain point, but you have to be able to extrapolate from that to what do they really want. I think I was able to bring that to the table.

I’m also a people person. There are people who just enjoy being in their world and writing code, but I just felt that these interactions helped me bring out the best for the products that we were building. That just kept multiplying.

Those experiences helped me transform from being just an engineer to an engineering leader who is also focused on the product requirements. And not just the immediate needs, but really able to understand where the puck is going to be.

How to carefully take product feedback from customers

Crichton: When you talk to a customer, and they’re like, “Well, I want these 30 features,” or there are features that only they need, or they’re like, “We need this,” and you sort of think that they need something else — how do you cut through all that?

Bhambhri: You’re absolutely right that with customers, they will give you very specific feedback because it’s a very tangible thing for them. They’re using it. They know exactly what works, what doesn’t work, what are the other things that they can do with it. That feedback is always pretty specific.

But then I think, at least I have felt with my experience, that as you develop trusting relationships with them, they will also start telling you about their other pain points.

As I meet customers, I spend time afterwards reflecting on the whole thing. Then if there are obviously patterns that emerge, that is when you get ideas about, is there a market segment here that we are not addressing? Then you can always go and talk to more customers in that space to validate or see if this is just a five customer problem or is it a 500 customer problem.

Obviously, I always share with the team very openly all these customer interactions, the good, bad, and ugly that came up, and some things that came up which are like “we should be watching out for this to see if this becomes a pattern or is it a one-off.”

You need to validate your data points, not just from what you’re hearing from the customer, but also looking at what else is happening in the industry because generally if you get an idea, there are other people who are getting this idea too.

Building momentum for new products

Crichton: Let’s say you find a new market segment or a new feature that you think should be added. How do you build credibility in your own engineering team who might say, “Hey, I just implemented this feature. Now you’re telling me it has to be something else,” or “I don’t agree. I don’t think we should go that direction.” How do you build momentum, particularly at a larger company, for these new features?

Bhambhri: A lot of this is that you have to go where you have conviction. With my teams, there’s ongoing discussion and sharing. Are they going to come to a similar conviction or whatever as you?

I encourage them to spend time with customers. They could be the same, they could be different. That way, there isn’t just one point of view which is my point of view. You need different people’s point of view. Everybody will think differently. Then see what are the similarities, what are the different things because we have those ongoing discussions.

I have this 80/20 rule, that 80% of the energy at the time has to be on the things that we are doing which is bread and butter for us. We have to meet our commitments there to the business, to the customers because ideas cannot be time-boxed.

But at least 20% of the time, people should also be thinking of what else, what is the next, where is the path going to be? That way, getting buy-in from the team is not a top-down mandate, but they’ve been on the journey with you. That it’s an ongoing thing, so that it doesn’t come as a surprise on where did this come from.

By the way, not everybody agrees or everybody is going to have the conviction. Then you as a leader have to really make the call. Once they have seen that you’re making the right calls though, and I’m not saying every call is going to be right, but more right than wrong, then you get people that will pay attention. When you say this is what we have to do, then you have earned their trust. They have seen that you are more right than wrong, and they have heard it from the customers themselves.

Finding the next great product

Crichton: Going back, you mentioned how you scale up these teams and then go back into an IC role where you find your next project. How do you time that? How do you know you’re at the end of this process and I want to go back and try and find that next project?

Bhambhri: I think typically when I have made those moves, they have been at times where there was a different trend starting in the industry. You have to have the passion to say, “You know what, this is so interesting that I’m going to get into this and then figure out what we can do here.”

It could be that you learn about things and you say, “Nothing needs to be done here,” but sometimes it could be this big opportunity. This is going to disrupt certain industries. So, really keeping up with what’s happening in the industry. I would say that when I have made the moves, it has been a combination of that and what I was hearing from the customers.

I think it goes both ways though that not only you learn yourself, you share it with your team. You share it with your senior leadership so that we’re all in this together. This way, as you are sharing with your senior leadership what you are seeing, they will also see that and they also keep providing advice and guidance. If they see that somewhere else, they’ll say, “You know what, what you told me, I heard it from these five customers too. So maybe there’s something there.”

Crichton: Do you have an example of this thinking in one of your moves?

Bhambhri: When I was in IBM, I was in the data warehousing space. I worked on databases, both transactional OLTP as well as data warehouses.

As I was visiting customers, I was starting to see that they were looking at a lot of technology white papers written by Google and then Yahoo and others. They were turning to open source and democratizing big data. To me, that was the time where, I think it was around 2009 or so, when I felt that one has to look at these new technologies because the scale of data, the latency that is needed, all those big data, how are these different companies going to deal with it? The traditional technologies will not get them there and they’ll also be very cost prohibitive.

At IBM, I was like, “You have to think of this different thing.” Those things are never easy because there will be enough people who will say, “Well, we have billions of dollars of business running on this technology that you think is going to be disrupted. Why do we believe you?”

In the end, you have to be passionate about solving the problem and have the conviction. You have to be willing to find your own way to solve that problem if nobody else is going to support you.

Product is always listening and selling

Crichton: You’ve sort of done this “intrapreneur” route. I think that’s a huge debate for a lot of people who read us is, do I fight the good fight internally? You’re working at a large company. I’m not getting the attention I want. How did you think about that? How did you stay internally and feel good about that?

Bhambhri: I got advice, that I have to attribute to one of my mentors because it’s a genuine question that a lot of us have had. “If you can’t convince the people that you work with, that you know that hopefully you have a good track record, if they cannot be convinced then that means either the idea is bad or you don’t have good communication skills.”

So how will you convince someone when you are on your own with no support because even then you have to convince people. You’re just convincing different people. You could be convincing VCs. You still have to advance your budget. You still have to convince customers that what you’ve built is what they need. So, this mentor of mine, his advice was so spot on that you can’t just back off. The first “no” that you get, if you have conviction, bring back more detail.

You often don’t get “yes” the first time around, especially if you’re trying to propose something very radical, very different, people will say, “Where did this come from?” If you haven’t taken them along in the journey, or even if you have, the first time you talk to someone about an idea, people listen. They may or may not gravitate. But my mentor’s advice was that unless you’re just in some wrong place or something, but if you’re surrounded by good smart people, then you have to think of how you are going to convince them and make it happen because having those skills is needed whether you do it inside a big company, or you want to do it on your own.

Advice for future product managers

Crichton: That’s great. As a final question here, you’re talking to someone who’s an engineer, who wants to go into the product world or maybe a budding product manager in any kind of context. What’s your advice to them? What should they be focused on right now?

Bhambhri: If you look at it, being in technology has always been fantastic. There are still so many obviously unresolved problems where the technology is there and that if that’s their passion, there’s nothing to stop them. Whether they want to be a part of a big company or small ones, do things themselves and make an impact, I mean there’s tons of stuff to be done.

My own daughter just graduated with a computer science degree. I gave her the same advice: understand what problems have to be solved and build the right solutions for those.

Love the problems and go build solutions for the problems that you love because not every problem is going to be attractive to everybody. There are people who love to do data engineering and there are those who don’t like that at all. I follow that advice for myself that you have to know what your DNA is, and you know that the best. Take things that are natural to your DNA because in the end, this is not a job. We do all this because we love technology. So, you have to feel energized about it and happy about it every day. So fun is the most important thing.

Crichton: Hopefully you’re having fun every day. I have fun most days, although usually when I go into my inbox, it’s less fun.

Bhambhri: I think, yes, that would be my other advice: do less email.