Early in my career, I started out in a product-facing team, working on user-visible features, collaborating with design, thinking about experience and usability. It was rewarding, fast-paced, and full of feedback loops.

After a while, I knew I wanted to push myself further.

I didn’t just want to design interfaces. I wanted to understand the systems beneath them. I wanted to write code that was resilient under load, optimize for throughput, and work at scale. I wanted to build the kind of technical judgment that only comes from shipping real infrastructure.

So I shifted toward working in infra. Not as a rejection of product, but as a deeper investment in it.

Infra isn’t “Not product”. It’s just a different kind of product

There’s often an artificial divide in engineering: you’re either a product engineer or an infra engineer. One cares about UX and polish. The other, performance and scale. Frontend versus backend.

The longer I’ve worked across both, the less I believe in that split.

Infra is product. It just solves a different kind of user problem.

Sometimes it’s about saving seconds. Sometimes it’s about saving incidents. Sometimes it’s making sure thousands of workflows run without a hitch. Invisibly, reliably, silently.

In my case, that looked like:

  • Building an adaptive token bucket system to keep fast workflows fast, even under load
  • Designing Redis failover logic to handle unexpected outages without data loss
  • Shipping robust improvements under the hood so operations are faster and more resilient leading to an improve UX.

All of these changes were deeply technical and infra, but they were still about product quality. About user experience. Just with different constraints and different surfaces.

Even while going deep on systems, I found myself constantly asking questions that felt product-y:

  • “Who’s this impacting the most?”
  • “How does this feel for a user?”
  • “Can we make this faster, cleaner, or more intuitive?”

Product-mindedness is for everyone

Being “product-minded” doesn’t mean you work in Figma or obsess over button spacing (though I’ve done that too). It means you:

  • Care who you’re building for
  • Think in terms of use cases, not just systems
  • Prioritize outcomes, not just architecture
  • Optimize for clarity, not cleverness

and that mindset is just as valuable in infra as it is in product.

Some of the best engineering decisions I’ve made came from asking, “What would be the simplest, safest thing for the person using this system?”, whether that person is a customer, a teammate, or another engineer working late on a Friday.

Why I chose to go deeper

I didn’t leave product behind. I just zoomed out.

Part of it was technical growth. I wanted to become a better engineer, and that meant understanding performance, systems design, reliability, and scale.

The other part of it was also preparation. I’ve always had the long-term goal of becoming a founder, and to me, that means becoming a generalist with depth. Someone who can build, debug, communicate, and lead across many layers of the stack. I’ve always believed that the best founders, PMs, and product leaders have a strong grasp of the technical side too. Code, systems, tradeoffs. It helps you ship smarter, collaborate better, and avoid wishful thinking disguised as vision. If you want to lead great products, you should understand how they’re built.

So I chased problems that would challenge me from infrastructure bottlenecks to internal tools to small user-facing polish, and treated all of them as product work.

Final thought: what you build is the product

You don’t need to be on the “product team” to think like a product person. You just need to care about what gets built, why it matters, and who it serves.

The best engineers I know don’t define themselves by layers of the stack. They define themselves by what they ship, how they think, and who they’re building for.

Infra or product - it’s all product, if you treat it that way.

I’m glad I didn’t choose between them.