[PM Talks] From Software Engineer to Product Manager: A Career-Shift Story with Akshay Bhalla (Stripe)

If you're an engineer who loves building things but is also eager to understand the why—the problems users want to solve and how your product helps—you’ll enjoy this episode, especially if you’re already considering a move into product management.

As we learned from this inspiring talk, a strong technical background can be a major asset in a product management career, though it may come with a few challenges.

What does the path from software engineer to product leader look like? Stripe’s Akshay Bhalla shares key lessons from his transition—and how his engineering background shaped his product mindset.

‍

About Akshay Bhalla:

• Product Lead, Reliability at Stripe
• Software engineer-turned-product manager with experience working for Meta, PwC, and EY
• Follow Akshay on Linkedin

What first motivated you to become a software engineer?

So I started my career as a software engineer. I was primarily working for fintech clients, building insurance products for them. The reason I got into software engineering in the first place was because I loved building things and really enjoyed seeing them work. That meant different things at the time—I did my engineering in instrumentation and control, where I built both hardware and software. But I naturally had more of an inclination toward software products, and it really brought me joy.

When I transitioned into my first job out of college, I really started enjoying building things from zero to one. That’s how I got into software engineering. The biggest validation I got back then was when I built something that actually worked, and the client really appreciated it—since it was a services company, that meant a lot. That’s when I realized what really drives me: when something I’ve built is actually delivering the value it was intended to.

That made me start thinking: I should probably get more involved in understanding what the users I'm building for are actually looking for. That’s when I started talking to people, asking questions like, “What are you looking for?” Because early in your career, most things are top-down—your manager tells you, “We’re going to do this. Can you take this module and build it end to end?” But very rarely does a new software engineer get to understand the why behind things.

And I found that the why was what really excited and motivated me. So I started talking to users to really understand, “Hey, you're looking for this XYZ feature—can you tell me more about the problems you're facing? Why do you need this?” That’s how I started thinking more about product-related stuff. It was my first foray into product management—without even realizing that’s what I was doing. So that’s how it all started for me.

What was your first experience working with a product manager like?

So, the way it worked was—when you’re just starting out as a software engineer—a lot of times, you get direction either from the product manager or your engineering manager to build something. You’re usually looped into the conversation once everything has been finalized and the vision is already laid out.

That’s when you hear, “Hey, this is exactly what we want to build—can you do the technical design?” And more often than not, it’s not super complicated, since you’re just beginning your software engineering career.

In my case, the collaboration with product managers in the beginning looked like this: I’d receive the PRD (Product Requirements Document) after the vision and requirements were already set. Then my job was to take those and translate them into a technical design first, and eventually into code.

One interesting example I can share—there was a time I worked with an insurance client where I had to build a predictive algorithm that automatically sorted insurance applications into different risk categories. So, if you were applying for insurance, you’d be categorized as high, medium, or low risk based on different parameters. That’s how insurance companies assess a person’s risk to their business.

I was tasked with building the entire backend system for this, based on the requirements. But when I received those requirements, the first natural question I had was: “Yes, we need this, but why are we building it from scratch? Can’t we procure something off the shelf? Doesn’t this already exist? How are other companies solving this?”

These conversations with the product manager helped me dive deeper into understanding the product. The collaboration was great—the product managers were really helpful. But I also noticed that some of them weren’t very technical. That’s when I realized I had a bit of a unique advantage: coming from a technical background and having a strong interest in the product itself.

That combination—technical depth and product thinking—felt like a superpower. It really helped me as I moved further into the tech industry.

Long story short, that’s how my collaboration with product managers began. I tried to understand how they operated, how they interacted with users, and how they uncovered user problems—the “why” behind things. And over time, instead of just being handed work, I started co-creating work with the product managers.

Those brainstorming sessions became a two-way exchange: I could educate them on the technical side, and they could teach me about the product side. That collaboration worked really well and helped me build the skills I needed to move toward product management.

‍

Did you ever feel frustrated working with less technical product managers—like when you saw better solutions they didn’t? And were there any other frustrations you experienced as an engineer?

I wouldn’t call it frustrating, but it was definitely a friction point with some product managers. A lot of times, when I suggested a solution, the product manager’s main concern was, “Can we get this done faster?” I often found myself having to explain why it couldn’t be delivered faster, what technical challenges we were facing, and what the best options were.

In hindsight, I realized that if I could educate the PM on the technical side—help them understand why we’re struggling to deliver quickly and what trade-offs would be required—it would lead to better decision-making. So it wasn’t frustration, but more about learning how to bridge that gap.

Especially as a junior engineer, another challenge was that I hadn’t built up credibility yet. So when I made architectural decisions, I often had to earn the confidence of my team and my engineering manager to support those choices. I had to clearly articulate the trade-offs and why cutting corners for speed wouldn’t serve the user well.

Those experiences really shaped me as a product manager. Now, when I think about solutions, I don’t dictate what should be done—I ask how it can be done and what the fastest path might look like. That early exposure helped me understand how to work closely with engineers, and how important it is to build a basic understanding of the technical domain rather than relying solely on the engineering team.

When I’m in the room with engineers now, we can have a healthy debate—figuring out short-term vs. long-term solutions. But that only works if the PM has a solid technical foundation. Especially today, with everything moving toward AI, it's even more important for PMs to understand how their product’s backend works.

That’s something I learned early in my software engineering career, and it’s a skill I now use to build impactful products while minimizing technical debt. That early experience helped me a lot.

When you decided to move from engineering to product management, was it a sudden aha moment where everything clicked, or more of a gradual realization over time?

It was definitely not an aha moment—it was a gradual realization. I worked as a software engineer for the first three years of my career, and at that point, starting right out of college, I had very little knowledge about the various roles that exist in the product world. I didn’t really know what a product manager did. There are also many adjacent roles—like technical program managers, PMMs, and others—but I had little to no understanding of what those roles required.

The realization came over time, as I worked on backend systems, built products on the technical side, and collaborated closely with product managers. That’s when I started to understand the complexity, the impact, and the challenges of the product management role—and that’s what really drew me to it.

I didn’t think I could just jump into it right away. I knew it required a whole range of skills I hadn’t yet developed. It’s not just about being technical—you need to build strong product sense, understand how to think about ideas, stay close to users, and really understand their pain points. Then, you need to know how to translate those into product opportunities.

I was very clear that I wanted to get into product, but I also wanted to do it methodically. So, after my software engineering stint, I decided to pursue a master’s degree, which brought me to the U.S. I studied Information Systems, and that really laid the foundation for my product journey. It taught me the basics—what’s required to build a product from zero to one, how to work closely with users, how to understand their mindset, identify their problems, and turn those into opportunities.

After my master’s, it was all about applying what I had learned. That’s when I got into consulting, which turned out to be a fortunate step. I worked closely with clients, including many C-level executives. That experience taught me how leaders think about company strategy and problem-solving at a macro level. It helped me see how individual user issues can often be generalized into broader patterns that impact more people—shifting my thinking from micro to macro.

All of those experiences—my time as an engineer, my master’s, and consulting—really prepared me for transitioning into product management at Meta. So yes, it was a gradual journey of learning and growing. And honestly, that learning hasn’t stopped. As a product manager, I’m still discovering new user problems every day, getting fresh feedback, and brainstorming ways to build solutions. The journey continues—and I take pride in that. I hope to keep finding more complex and meaningful problems to solve in the future.

What would you consider your first real product management role? Was it at PwC, or were you more in a consulting capacity there?

My first foray into product management was at PwC, right out of college. Interestingly, firms like PwC don’t really have specific titles in the way tech companies do—a “consultant” could mean a lot of different things. My official designation was “consultant,” but what I was doing aligned closely with product management.

My job was to go out and speak with clients in the financial services sector, understand the problems they were facing, and figure out what goals they were trying to achieve. For example, a client might say, “We’re facing latency in our business productivity, and we want to improve efficiency for our users.” That would be the starting point.

From there, I’d dive deeper—talking to users, observing their day-to-day workflows, identifying friction points—and then using that feedback to shape a product strategy. These strategies could span anywhere from six months to three years. That entire process gave me exposure to how products are built from the ground up.

A lot of the time, we had to decide: should we build something new, or should we procure an existing solution? And more often than not, due to the custom nature of the business problems, it made more sense to build from scratch. That’s how I became involved in the full product lifecycle—translating problems into opportunities, shaping those into solutions, measuring impact, and then developing long-term strategies to sustain and improve the product.

So, while my title was “consultant,” that experience at PwC was definitely my first real product management role, where I saw what it meant to build a product end-to-end to achieve tangible business impact.

From your time as a software engineer, what were the most valuable skills you carried into your first product management role at PwC?

It definitely brought a lot of leverage when I transitioned into product management. I’ll actually present both sides—it was beneficial, but also a bit disadvantageous at times.

On the plus side, having a technical background helped me understand the challenges involved in building solutions. It allowed me to dive deeper into the weeds with engineers, explore more optimal solutions, reduce infrastructure costs, and figure out faster ways to get to market. That was a huge advantage.

But the downside was something I realized pretty quickly. Because I had that technical knowledge, I started becoming more of a hindrance than a help to the engineers. And that’s not a good sign. When you work with engineers, it’s really important to give them the space to innovate, to come up with solutions on their own, and to contribute to the overall vision.

What I found was that I was guiding the solution too much—more than I should have. And in hindsight, that actually slowed things down. Because even though I understood the technical side, I wasn’t in the trenches the way the engineers were. They had deeper context than I did.

So yes, I carried a lot from my software engineering background. But I also learned—through experience—that you need to give engineers the trust and autonomy to do what they’re best at. That’s something I still practice today. I’m involved in some of the solutioning, but if an engineer comes back and says, “This is the best route forward,” I trust them. I’ve made peace with letting go and trusting the right people to do the right jobs.

That shift in mindset has really improved not just my collaboration with engineers, but with all cross-functional partners. I’ve come to believe that when everyone understands the vision, shares the same goals, and is working with good intentions, you can trust them to do what’s best. That’s been a big learning for me over the years—though I’ll admit, I was a little shaky on that front early on, coming out of my engineering role.

‍

Do you still keep up with the engineering world? Would you say you’re still technical—and could you imagine going back to engineering if you ever decided to?

That’s a loaded question, so I’ll answer it in two parts.

First—yes, I still keep myself up to date with the engineering world. But not because I plan to go back to engineering. The reason is that my goal now is to build the best possible products to solve real problems—and many of the products I’m working on at Stripe are deeply technical. You really can’t build strong technical products without having a solid grasp of the underlying systems, because that knowledge directly impacts your ability to make good decisions. If you want your product to do its job well—and it's technical in nature—you need to stay informed about what’s happening in the market, what competitors are doing, and how the landscape is evolving. That gives you an edge.

As for the second part—whether I’d go back to software engineering—I don’t think that’s likely. The landscape has changed a lot, and while I’m still technical enough to be dangerous, I’m not technical enough anymore to be an effective software engineer, especially in today’s complex environment. Over the years, my engineering skills have faded as I’ve built up my product skill set instead.

What are some of the key skills you’ve developed as a product manager, and how do they differ from the ones that were important during your engineering career?

As a product manager, I think one of the most important skills I’ve developed over the years is learning to work backwards from the user. It’s critical to start with the why behind a problem, not just the solution. I’ve learned to question more deeply, to read between the lines when talking to users. Often, users will tell you what they want, but that doesn’t always solve their actual problem.

What I’ve really picked up is how to dig into the full user journey—understand where the friction points are—and then craft solutions that address the real need, rather than just building what was asked for. For example, a user might say, “I want a product that provides audio,” but that doesn’t necessarily mean they’re envisioning something like Spotify. It’s about getting to the core problem.

Another key skill I’ve honed—and am still working on—is strong communication, both written and verbal. As a software engineer, you’re usually on the backend, and you rarely get the chance to present ideas to senior leaders or articulate a product vision. But for a product manager, communication is absolutely critical. You need to be able to clearly sell your vision—not only to leadership to secure funding, but also to your team. If you're leading a team of 200 engineers, they need to be fully aligned and inspired by that vision. They become your partners in bringing it to life, and they need to believe in it as much as you do.

The third skill is related to measurement—something engineers already think about, but from a more micro-level. As an engineer, you measure things like latency, throughput, compile times, and overall app performance. But as a product manager, you have to think about metrics on a macro level. Is the product discoverable? Are users adopting it? Are we able to acquire users efficiently—what’s our customer acquisition cost? Are users coming back—what’s our retention rate? Are they willing to pay for it? And beyond that, is there a system in place for continuous feedback and improvement? Having that end-to-end view of product performance is something I learned after making the transition.

So overall, the product mindset shifts you from thinking about systems to thinking about impact. And if anyone is considering transitioning from engineering into product, I’d encourage them to zoom out and start thinking more holistically—about acquisition, retention, monetization, and the full user journey. That’s what really helps build strong product intuition.

‍

What advice would you give to engineers thinking about moving into product management? And how can they tell if it’s the right path for them?

I’d suggest engineers start by working closely with product managers. A lot of times, as engineers, we focus so much on the backend and technical execution that we don’t fully understand the why behind the product vision or the PRD. So first, get involved—understand the problem the product is trying to solve. That’s a great entry point to see if product management is something you're genuinely interested in.

If you do feel that pull toward product, the next step is to start building foundational PM skills. Look for opportunities outside your engineering scope—join user interviews as a fly on the wall, observe how product managers and UX researchers uncover user problems, and sit in on brainstorming sessions to develop product sense.

At the same time, don’t let go of your technical strengths—build on them. Product managers need to be data-driven, and engineers often have access to valuable data through logs, telemetry, and instrumentation. Use that access to run analyses, build dashboards, write SQL queries, and uncover patterns that reflect user behavior. This kind of quantitative insight is incredibly valuable, and being able to do it yourself is a huge advantage.

Finally, once you’ve developed these skills, reflect them clearly on your resume. Highlight where you’ve driven user impact or helped shape product decisions. If you’ve built that foundation, it can absolutely open the door to your first product management role.

Are there any books, courses, or other resources you found valuable during your transition to product management—maybe ones you still revisit or recommend to others today?

Yeah, a couple of books I’d recommend for anyone looking to transition into product management:

First, Lean Product—it’s a great book that teaches you how to operate with minimal resources and still build a successful product. It’s a really powerful starting point.

Another one I highly recommend is Zero to One by Peter Thiel. It offers great insight into how to build a product from the ground up. A lot of times, we look at successful products like Spotify or Amazon and admire what they’ve become, but we rarely think about their early beginnings. Zero to One walks you through the mindset and principles behind taking an idea from nothing and building something impactful. It helps you work backward from the user and truly understand the genesis of great products.

A third book I love is Start With Why by Simon Sinek. It’s not product-specific, but it’s incredibly powerful in shaping your mindset. It helps you realize that everything—whether in product, business, or life—should start with why. Understanding that foundation gives you clarity and purpose in whatever you’re building or doing.

In terms of courses, I haven’t personally taken formal product management courses, but there are excellent free resources online. YouTube, for example, has tons of great content. I often do webinars with Product School, which is another fantastic resource. They have a lot of free sessions featuring experienced product leaders from different companies. Listening to their experiences and lessons can be incredibly valuable.

So between those books and free content like webinars and talks, there’s a lot out there to help anyone get started in product.

Let's get to our favorite fives: questions we ask every product manager who joins us on this podcast. First, what is your biggest challenge as a product manager?

I’d say the number one challenge in my work is taking the whole village along with me when I’m building something. And I know that’s a big statement, but what I mean is—you can’t build in isolation. I need to bring in my cross-functional partners and other teams across the company to build something meaningful.

While that can introduce friction and slow things down, I’ve found it’s absolutely essential. When you bring others in early, their input and feedback make the final product stronger. So yes, aligning everyone and getting buy-in is definitely the most challenging part—but it’s also one of the most important.

‍

If you could choose one key metric, your North Star, to define your success as a product leader, what would that be?

I’d say the North Star of my product management career is the number of times I’ve successfully delivered the user impact I originally set out to achieve. If I started with a vision to create a specific impact for users, and I was able to deliver on that by the end—that’s my North Star metric.

So for me, it's really about asking: how many times have I actually done that? I’d like to believe it’s a lot, but the reality is there have been plenty of failures too. There were times I couldn’t deliver the right level of user impact—and those experiences brought important learning.

But ultimately, that’s the metric I keep coming back to.

‍

How do you collect feedback from your customers? What processes or tools do you use?

Typically, I do it in two ways. The first is qualitative feedback, which I gather through user interviews or by speaking with user-facing roles—people like support teams, technical account managers, and customer success managers who have a strong pulse on the user experience.

The second method is quantitative data. Whenever I put together a PRD or product brief, one of the most important sections is: How do we measure success? I always outline the key data points I want to capture across the user journey. That data helps me understand how users are interacting with the product, and when you look closely at it, it can offer a lot of insight.

So between qualitative conversations and quantitative analysis, I use both to understand user feedback and continuously feed that back into the roadmap for future iterations.

When it comes to 'build versus buy', how do you decide?

I think it really goes back to the user problems you're trying to solve. For example, if you’ve identified three key user problems and there’s already a solution in the market that effectively addresses them, then it’s probably not worth building something new from the ground up. In that case, it makes more sense to leverage the existing product and see if it can be customized to better fit your users’ needs. An out-of-the-box solution is often sufficient in those scenarios.

But that’s not always the case. Often, you’ll discover a unique user problem—and with it, a gap in the market. If the opportunity is large enough—meaning a significant market segment is affected by the same problem—then building a product becomes much more compelling.

In that case, you’re not only solving the initial user problem, but also tapping into a meaningful growth opportunity. It can also open up monetization potential, where you can turn user adoption into a sustainable business.

So, those are the valid reasons to build: solving unmet user needs, seizing a clear market gap, and creating opportunities for scale and monetization. But if there’s already a solid solution out there, building something new just means competing for the same users—and that’s rarely the best move.

What role do integrations with third-party products play in your product?

Third-party products can be incredibly helpful—it’s the same logic as the classic build vs. buy decision: why build something in-house if there’s already a solid solution available?

In general, third-party tools have simplified a lot of things. For example, we use Splunk dashboards extensively to track and understand how systems are performing. Building an internal tool for that wouldn’t be nearly as effective. I also use AI tools and apps like Balsamiq for wireframing. If I had to build those capabilities myself, it wouldn’t be efficient or practical.

These tools have definitely made my job as a product manager easier and more efficient—especially compared to earlier days when I had to do everything manually with little support. That said, not all third-party tools are helpful. It’s important to be thoughtful about which ones we adopt, ensure they’re approved internally, and use them with care.

Closing remarks

In this conversation, we explored one product leader’s thoughtful journey from engineering to product management, highlighting how a technical foundation can be both a strength and a challenge. We heard how user-centric thinking, cross-functional collaboration, and data-driven decision-making became core to his evolution as a PM.

From navigating build vs. buy decisions to leveraging third-party tools and staying close to customer feedback, his insights offer a clear roadmap for anyone making a similar transition.

Whether you're an engineer curious about product or a PM looking to sharpen your craft, this episode is a reminder to always start with why—and let the user lead the way.

You can contribute to the topics we prepare for our PM talks. Post your desired question or topic below, and we’ll happily consider it for future episodes!

You’ve just read an interview from our podcast, where we speak with product leaders who share their experiences. Follow us on Spotify or YouTube for more episodes.