Ashraf Karim is VP, Product Management at Cisco. Before that, she held S/VP and leadership positions at household-name tech companies as ubiquitous as Affirm, PayPal, Google, and Verizon.
As an engineering leader during the infancy of cell phones, she parlayed her flair for solving customer problems and knack for scripting into a product management role before that was really a thing. Today, with over two decades of experience transitioning high-growth, colossal enterprises toward a customer solutions-led culture, Ashraf is an expert in bridging the gap between business and technology.
In our conversation, Ashraf talks about the importance of honing both your product sense and technical aptitude, whether you’re an engineer or a product manager. She also discusses the distinctive demands and challenges of operating in a massive enterprise and the advantages of having the resources to dream big, push boundaries, and approach product management as an art form.
I grew up here in Silicon Valley and, naturally, found my way into engineering. I polished and developed my skills at Cisco and Agilent. But I’ve always been curious about technology, curious about what we’re building and why. That led to me learning and growing in different ways.
Eventually, from working on JavaScript, Perl, C++, and C code, I ended up finding my niche in scripting. I spent a lot of time and solved a lot of business problems using scripts, and Perl became my go-to thing. I was like, wow, this is pretty amazing — things can be solved very quickly and there were a lot of different shortcuts you could build. The rapid nature of scripting was what intrigued me.
What I fell in love with when I went to Verizon was working on problems for the customers. I thought, well, with my engineering background, my ability to script, my ability to code, I can be really effective. I spent over eight years there and I grew up there. I got to really dive into different aspects of software development — not just from support, scripting, and engineering, but also product management.
What was always interesting about me, even as an engineer, was that I was always thinking about what I was building, for whom, and why. That curiosity needs to exist because, really, that’s a transferable skill no matter what field you’re in.
I found that the best engineers were those who think about not just the first use case, but the next 10 use cases that would be built off of it. This is important in product management as well; you are defining a product vision that could be a few months to few years out, so you need to know where you’re going and how you’re going to get there.
At the end of the day, product is responsible for delivery. In the engineering world, engineers are responsible for both execution and delivery, and it has to be timely. I think that is also a very transferable skill. You’ve got to act like an owner of what you’re doing. If you’re building something as an engineer and you need resources from another team or cloud storage, you’re going to need to coordinate and plan ahead on the allocation you need.
Similarly, as a product manager, you need to understand the end-to-end build out of your product, which teams and partners you need to work with, and reach alignment early on to avoid any bottlenecks. Don’t leave it for somebody else to do. The ability to think about that stuff end-to-end is important, and I think those coming from an engineering background tend to have a distinct advantage in this area.
Finally, as Michelle Obama would say, there are things you do that you have to be good at, and there’s a lot of things you can do that you’ll love to do, but then there’ll be certain things that you may not want to do, but you still have to be good at it. To me, that is program management — that requires you to get into the details and, if you’re not careful, you can lose the bigger picture easily. I tend to undervalue this skill since it comes naturally to me but, frankly, this is so important and critical to your success and your team’s success — it’s essentially your ability to execute. Most engineering leaders have mastered this skill, which makes them very successful as product managers.
I didn’t even know there was a discipline of product management. When I first landed in a product management role, they asked me to build a workflow management tool. The idea was to build a tool that would allow each region to customize its own process for building cell sites.
We had 12 to 13 regions across the country, which I realized later worked so differently from one another. I tried to understand how each of the regions operated. Much of my time went into creating alignment between the regions to smooth out their processes, as well as learning how and why each region needed to operate so differently. This forced me to develop strong listening and negotiating skills and gave me experience in my first buy-versus-build decisioning process.
Back then, over 15 years ago, the workflow process was a brand new thing because cell phones were just becoming popular. I thought, this is super interesting. I get to work with people who are actually building the mobile network and I get to contribute to some aspects of the technical architecture and design, even though I didn’t know how to do it or where to start. Someone said to me, “Well, engineering needs requirements.” So I tried to figure out what requirements look like.
I found my way into writing waterfall requirements. I think my first requirements document was over 50 pages; you’re building an enterprise tool and you want to make it customizable and, gosh, you can just dream big at this point. You can spend a lot of time doing that. But over time, I learned that discipline is important in product. This is where I started to build the muscle around platform product management.
I’ve launched several zero to one products in the enterprise and consumer space, from internal tools such as CRM systems and data-rich analytical tools, to PayPal Assistant and new features for Buy Now Pay Later (BNPL).
The rollout for these is very different. For the CRM system, you want to offer as many usable features as quickly as possible. The rollout for a product like a CRM is gradual, largely because you have to build a ton of features upfront, get it right the first time and do the right amount of testing. The challenge with enterprises is they often have too many tools. You have to think about whether you’re adding value or just adding to the problem.
With consumer-facing products, like BNPL or PayPal Assistant, you have more users to test with so you can learn and adapt quickly. Having a strong, data-driven approach is extremely important here; you have to know your KPIs extremely well and make sure you’re not negatively affecting other areas of the business. That’s where you can iterate fast, and why A/B testing is so important.
Customer focus and innovation is key. It’s about delivering the best customer experience, being innovative, and considering how your product can be a competitive edge. You aim to be the best, to differentiate and deliver value in a growing environment. In these companies, there is also a strong culture of building, which is greatly valued, but you have to be cautious about what to build versus what to buy.
Time to market is crucial, and building takes time. Even with strong momentum from engineering and product teams, who are eager to build because they believe we can do it better, you need to sometimes temper that urge. You must ensure it aligns with the company’s strategic direction because, when the growth period ends, you’ll reflect on whether you invested your resources wisely. Did you build the right things?
If buying off the shelf gets you to market quicker and is the best, then sometimes it’s the better option. Be creative, use what you buy as a stepping stone, and then build your competitive advantage from there. That’s where a deep technical understanding is vital.
I believe in embracing simplicity, which means reducing the cognitive load of the customer at every interaction.
When I think about user experience, I think about, how do I make it super easy, simple, and effortless for the customer? And how do you achieve that? That’s a nuance of its own. How do you provide simple and delightful experiences?
Technology has a lot to do with it. How can you leverage technology to provide a personalized experience, and how do you create trust and comfort? You want it to be simple, but you also want to make sure that, visually, what the customer is seeing is also instilling trust.
It’s an iterative process, and it depends so much on the customer’s intent and mindset. For example, if I have a customer who’s very focused and knows exactly what they want, they’re going to want a different experience than a customer who is still exploring. You really have to think about the customer’s mindset and then tailor the experience to adapt to what they would expect.
I would emphasize the importance of grasping customer value. Formulating a compelling business case involves questioning the purpose and significance of a project. It’s not solely about financial gains or business expansion; prioritizing customer value takes precedence. It’s really important to understand how a product or service is going to transform for the customer experience. It’s about identifying what you aim to disrupt and the value you intend to add.
And, of course, your ability to execute. Having some sort of technical understanding of how something’s going to be built, how it’s going to work, is important because you may have to make trade-off decisions. For example, am I going to build a very reliable product, or am I just going to build a quick prototype, validate, and test? You may not want to go and build the most reliable thing the first time when you’re still trying to learn whether it’s going to have product-market fit.
The last piece is just to be very creative. Don’t set boundaries for yourself because the development process involves collaboration — you can hire good engineers to build whatever you can dream up, so dream big. Think about the problem you’re aiming to solve. What would delight the customer? What would make it irresistibly simple?
What’s your form of art? Product is a very creative element, and every PM brings something unique to the table in terms of what they value about what they’re building.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
