Leader Spotlight: Building a sustainable product ecosystem, with Anub Maheshwari
Anub Maheshwari is CVP & Head of Engineering at AMD, where he oversees product and system software development, program management, and customer engineering. He began his career in software engineering at Texas Instruments, where he spent 12 years working in various business units, including mobile computing and smartphones. Anub joined AMD in 2014, serving in director-level roles before his current position as CVP.
In our conversation, Anub talks about how a product ecosystem — specifically in an industry like semiconductors — needs to work seamlessly to deliver a great customer experience. He also shares the importance of pivoting and incorporating changes quickly.
Defining success across product components
Looking back at products that you’ve worked on, what are some of the key inflection points on the product journey that have shaped their direction?
My career spans more than two decades in the semiconductor industry, and I have had the opportunity to build several products from the ground up. I believe in early customer engagement and feedback, which is paramount to the success of a product.
As a product leader, you are constantly working on the multi-parametric bounding box problem — to build a leadership product that brings out the best technology, has the right development timeline, fits the market requirement, falls within your R&D budget, and meets the right cost structure. From the time the product idea starts to take shape to when it launches, PMs are constantly talking about internal and external curveballs. They stretch and challenge the bounding box and all the decisions around it.
For example, when I was working on a processor some time ago, the PM wanted to add features to capture the different market segments. Some of them were non-overlapping or orthogonal, and that bloated the cost structure. I decided that we need to keep market adjacencies in mind and not push orthogonal features into the same product. I asked the product manager to choose the two largest market segments, and they forked the road map into two swim lanes.
For one swim lane, they took one of the largest market segments as the primary driver of the market requirement, defined the bounding box, and then added features from an adjacent market segment. They did that for the second swim lane and market segment, and the end result was products that were tailored to their primary market segments. They became quite successful, as they hit all the aspects of a leadership product.
A lot of what you do spans software, hardware, firmware, customer engineering, and other segments. Does that scope change how you’re defining success for the products?
Since I’m in the semiconductor industry, many people assume that our products are always silicon hardware, like chips or processors. That’s not actually a complete picture. A piece of hardware is useless without the right firmware and software to enable it, so our products have all of those components to them. There’s a motherboard, firmware, software, device drivers, and SDKs for customers to use and build on top of.
For example, we have bleeding-edge graphics hardware, which is used by game developers to run their top-notch games. But the developers can’t use the graphics computer directly — they need software, firmware, and programming interfaces as well. And if we don’t create those, it won’t work for them.
Given all these different pieces, success depends on how well they all work together from day one and how easy it is for customers to build their products on top of ours. The mantra to this success is internal co-design. You need to have chip designers work hand in hand with firmware developers, who then work hand in hand with software developers. That collaboration needs to happen from the beginning. There’s no room for any silos here. Once this co-design happens, you can see the product definition continuously evolving and becoming more and more compelling.
Building a systems engineering organization
How do you distinguish between technical issues that come from the development process vs. product-market misfits or a strategic misstep?
The way your customers get your product deliverables mirrors your organizational structure. This can often lead to dissatisfaction if it’s not done right, because if your customers are buying a vertical solution, you cannot deliver them horizontal pieces.
Products nowadays are very complex — there are many different building blocks and elements to them. To build an enormous product, engineering competency is at the center of the building process. But as soon as the engineering organizations start thinking that their work is the totality of the product, misalignment comes in. This misalignment shows up to customers, and it ends up burdening them. If two elements are not compatible or don’t integrate well, that leads to a pretty bad customer experience.
One example of this is when we had a recently fabricated chip leading up to release. Customers were eagerly waiting for it, and there was a lot of pressure around the deadline. Teams were moving at a feverish pace, and in doing so, there was a communication gap. One of the important feature enablements in the software was missed, even though it was in the hardware. We ended up doing an off-cadence software release and made a diving catch to fix the problem, but it was a good lesson.
I adapted to this challenge by building a systems engineering organization. Now, systems engineering organizations oversee the full product, not just individual building blocks. They’re also, internally, our day zero customer. They make sure all the pieces are working together to enable the committed features, and we deliver a vertically integrated product to the customer every time. A systems mindset is really important to us.
Especially with so many different teams touching various aspects of the product, what early signals do you rely on to determine if something is wrong?
When we’re putting the high-level product definition together, we’re synthesizing the requirements, talking to customers, and inserting our own thought leadership. But the idea is not to stop there. Even though we may feel that we have put the most compelling product definition out there, we need to be continuously engaged with our lead customer — who I call lighthouse customers — and continuously seeking their feedback. The second step is for our marketing team to generate enough anticipation in the market for our product so that the sales pipeline starts growing.
Once this is done, we enter the alpha phase of product development, and if we see an anemic sales pipeline or that our lighthouse customers are providing negative feedback, those are signals that there’s something wrong.
A good intervention strategy starts from a mindset. It has to be about learning and adapting. Product managers cannot be defensive — they need to have high capacity to adapt or change.
Once we are in this mindset of learning and adapting, we need to evaluate each piece of customer feedback, ask questions, and listen to understand. We discuss with our field teams to understand the problem, and that’s how we can truly understand, unbiasedly, what went wrong.
Pivoting quickly and implementing AI
You work on co-development with customers. Can you talk about how that works on your teams at AMD and how it changes the product roadmap or approach to execution?
I mentioned our internal co-designer approach, where all internal teams work together to achieve a holistic product. But internal co-design alone isn’t enough. To avoid crisis moments of misaligned expectations or schedule mismatches, we take one extra step: deep customer co-engineering.
On my teams, we identify key lighthouse customers who are disruptors in their own industry and establish deep co-engineering engagements with them. This prevents surprises or last-minute gotchas that are often too late to fix. I can’t overstate the impact of this approach.
For example, at AMD, we develop automotive infotainment software. We initially had a roadmap for native software, but when we engaged early with a lighthouse customer, we discovered their priority was delivering an exceptional user experience through parallel use cases and virtualized software. Thanks to this insight, we quickly pivoted our roadmap from native non-virtualized to a virtualized, open-source software stack — a strategic shift that would never have happened without early customer engagement and would have led to failure later.
How do you see AI factoring into the work that you’re doing?
AI increases the pace of everything we do. Some things that previously took us a year to develop now only take six or eight months. The change in pace of development on our side, as well as on the customer side, is drastic.
When the pace is so rapid, it’s easy to collect new requirements or change requests from customers. We feel like we have to quickly adapt to these new requirements, but engineering teams tend to hate never-ending change. Especially when requirements come from PMs, frustrations grow and friction builds between product and engineering.
Our products are enormously complex, so all these building blocks and organizations have to come together. If they get disconnected, the problem becomes severe very quickly. With AI, I’m seeing the engineering and product relationship evolve to become nimble, agile, and more nano-aligned than macro-aligned. We have a large body of work, but we break it down into smaller chunks, and then product managers check in with engineering after each chunk is complete. This helps ensure that changes can be incorporated fast, and we avoid wasteful work.
Focusing on progress over perfection
Do you foresee the future of product management in general embodying more of this ecosystem mindset?
Yes, absolutely. I believe that the third pillar of success is ecosystem readiness. This perspective applies to other industries as well, not just semiconductors. While the overall product offering in our space has many elements, a large systems solution needs to come together to build the end product the customer creates.
When customers put this complete system solution together, they often face challenges — software from one company may not work inside the hardware of another, or the software may not be ready or performant enough. These compatibility issues can derail entire program or project plans. This is where product managers need to think of a system solution and proactively partner with key ecosystem players early on.
The overall AI ecosystem is huge. Many companies are training and building AI models. And as a chip company offering AI accelerator solutions, we need to partner with these software players so that when our customers are building their systems, they have a choice to work with. Whatever the customer is trying to do, we need the right ecosystem in place from day one to help them get to market faster.
If you’re looking to scale a business, ecosystem readiness and working together to provide reference solutions with your ecosystem are critical. Product managers should advertise these partnerships and reference solutions because they help enable and scale the business. A strong, healthy ecosystem is a must for scaling your business and accelerating time to revenue.
Lastly, are there any lessons you would share with someone looking to lead this type of ecosystem?
Potential product leaders or engineering leaders need to focus on progress rather than perfection. You can whiteboard internally all day to play out different scenarios and get the perfect product definition. While what you’re thinking may feel perfect, it won’t be impactful. What actually moves the needle and results in hugely successful products is partnering with lighthouse customers and ecosystem partners, and co-engineering with them from day one. This not only builds the product leadership you’re aiming for but also accelerates time to market for your customers and creates faster time to revenue for your own company.
Also, when you have global teams, always over-communicate and be transparent. With AI, the pace of development has become very fast. With such quick development and tight timelines, mistakes happen. As a leader, you have to be very clear in your communications and provide clarity of direction. That doesn’t just mean explaining what we’re going to do, but also outlining the risks, how we might fail, and how we can mitigate those risks early.
If there are mistakes or failures, take them in stride, adapt quickly, and change course. Failures are part of success. Navigating and coming out on the other side of failure should be celebrated as a mini success.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.