Leader Spotlight: Developing product sense through technical product management, with Nilesh Singh
Nilesh Singh is Head of Product – Backend at Unicity International, a wellness company that develops innovative nutritional products. He began his career as a software engineer at DXC Technology before moving to Microsoft, where he worked as Tech Lead. He later transitioned into product management at Cognizant and went on to hold senior product leadership roles at Global Payments Integrated and Amazon Web Services, where he was a Senior Manager of Product on the DynamoDB team. Today, at Unicity, Nilesh leads backend product strategy across a global platform serving more than 50 markets.
In our conversation, Nilesh talks about how developing product sense is not only about technical expertise but also requires skills like judgment, systems thinking, AI adoptability, and more. He discusses why AI is raising the bar for PMs rather than replacing them, as well as how organizations can adopt AI responsibly. Nilesh also shares his perspective on balancing speed with governance.
Bringing technical thinking to product management
You’ve spent most of your career in deeply technical roles in product management. How do PMs with engineering routes tend to approach the role differently?
The real advantage isn’t what most people assume. It’s not that technical PMs are better at building — they’re better at understanding that a solution will take three sprints, not three days. That’s the asymmetry that matters.
When you’ve written enough code — as I did early in my career at Microsoft — you develop an intuition for how systems age. An API contract written for the feature in front of you rather than the feature you’ll need 18 months from now doesn’t look like a problem on day one. It becomes a problem later, when another team is trying to move fast, and the architecture is working against them. Without that lived experience, you understand the risk intellectually, but you don’t feel it. Product decisions get made at the level you feel, not at the level you understand.
I watched this happen at AWS. I saw a connection management architecture that was sound at 20,000 nodes hit a ceiling as the fleet scaled — all because API contracts had been designed for the problem in front of the team rather than the one three years out. By the time it surfaced, it was baked into a system that tens of thousands of businesses depended on. The technical fix was possible, but the cost was measured in engineer-years, not sprint points. A PM asking what this would look like at 10x might have changed the design decision. Nobody did.
At Unicity, we manage backend systems across more than 50 markets, each with different regulatory requirements and currency environments. Design decisions made today compound across every team that touches the system.
A technical background doesn’t make you a better builder in this role. It makes you much more expensive when someone brings you a feature idea that hasn’t been thought through past the demo. Since you understand how much effort it takes to implement a feature, you can push back much earlier. You understand the backend, the technical implications, and can explain why something isn’t feasible within the expected timeline.
With the AI tools your teams are using today, how has the PM playbook changed over the last year, the last few months, and the last few weeks?
It’s not just the playbook that has changed, but the expectation baseline. We used to evaluate product managers on their ability to write BRDs and PRDs, launch products, understand product-market fit, and build go-to-market strategies. Today, AI can produce a solid BRD in 45 minutes. That doesn’t mean you’ve saved a day and a half — it means the baseline for “ready to share” has moved.
Stakeholders have calibrated to that, whether they realize it or not. They think, “AI can write your documentation. What are you busy with?” The compression is real, but it’s unevenly distributed. Discovery has also become much faster. AI is excellent at synthesizing research, generating first-cut frameworks, and helping structure a problem space.
With that said, stakeholder alignment hasn’t gotten faster. The conversations where you’re figuring out whether legal approves, finance supports it, or engineering agrees on the trade-offs still take just as long. If anything, faster documentation has exposed how much alignment was happening during the process of writing the document together rather than in the document itself.
Today, I think PMs need two things. First, they need curiosity. Ask questions, even if they feel naïve. AI isn’t judging you. You can ask as many questions as you want. And second, they need to implement. We used to say ideas are cheap and implementation is hard. Now you can take an idea, use AI to prototype it, bring it to customers, demo it, gather feedback, and iterate much faster than before. Your ideas no longer have to die in a boardroom.
We recently migrated hundreds of endpoints from a legacy framework to a modern architecture. The work required translating enormous amounts of existing behavior into structured, testable contracts. That translation was necessary, but not intellectually demanding, and AI handled it well. We completed the migration in two months. Without AI, it would have taken years.
Building AI into product organizations
What are you most excited about with the way that AI is transforming the PM role, and what are your biggest concerns?
What excites me most is the collapse in the cost of being wrong early. I’ve spent years working in domains like order management, healthcare, and backend infrastructure, where validating a hypothesis required a meaningful engineering investment before you had anything to show a customer. We’d spend two weeks on a spike before discovering we’d misunderstood the problem. That cost shaped everything: which hypotheses we tested, how many we could test in parallel, and how reluctant teams were to abandon something after investing so much to build it.
What concerns me is a specific failure mode that I’m already seeing. A PM generates a spec with AI. An engineer implements it with an AI assistant. A reviewer scans it, it looks polished, the structure is right, and the edge cases appear covered, so we ship it. Every individual acted reasonably, but the system failed.
An underexamined decision travels much farther and much faster because the friction of manual production, which used to create natural review checkpoints, is gone. In complex backend systems, by the time you catch the mistake, it’s already in production, and the blast radius is real. The answer isn’t to slow everything down. It means creating explicit review gates instead of relying on “this looks right” as a proxy for “this is right.”
At Unicity, we’ve embedded automated compliance checks into our CI/CD pipeline. We operate in more than 50 countries with different currencies, GDPR requirements, PCI compliance, and other regulations. Before a human reviewer even sees the output, automation validates those requirements. The automation doesn’t replace human judgment. It creates a workflow where human judgment can actually be trusted. When everyone is moving ten times faster than before, “this looks right to me” is no longer a reliable standard.
How are developers responding as PMs gain more direct access to production? What’s the path to making that relationship work?
We’ve definitely had pushback from developers. At Unicity, we held a hackathon around this idea. The message wasn’t, “PMs can write code now.” It was, “We want to help the engineering team increase its velocity.” I used an analogy from healthcare. In the US, there’s roughly one provider for every 857 patients. Nurses have taken on responsibilities that used to belong exclusively to doctors because physicians should be spending their time on the work that requires their expertise. The same principle applies here.
We want developers focused on architecture and the most complex engineering problems. If PMs can safely handle configuration changes or other low-risk tasks with AI, developers have more time for the work only they can do. We’re not trying to replace engineering — we’re trying to become better partners.
One concern developers raised was legitimate. They said, “If you start creating pull requests with hundreds of lines of AI-generated code, why should we be responsible for reviewing code that you didn’t actually write?” That’s fair, but my view is that this has to happen gradually. Start with configuration changes. Build trust. Show that you can safely make small improvements. Then maybe you move to a single line of code, then small functions, and gradually expand responsibility as confidence grows.
The goal isn’t for PMs to own engineering work. It’s to ask, “How can I help?” If I can take low-level work off an engineer’s plate, they can spend more time acting as architects — deciding how AI should be implemented, what standards we should adopt, what security requirements matter, and how the system should evolve. That’s where developers create the most value.
You come from a background in healthcare payments, cloud infrastructure, domains where cutting corners is not an option. How do you think about that tension of moving fast with AI and maintaining the standards that those environments demand?
I would actually push back on the framing that this is a tension between speed and quality. The real tension is between knowing your risk surface and acting as if you do when you don’t. At Unicity, we tier our backend systems by consequence rather than technical complexity, and that distinction matters:
Tier 1 — Where an error creates an embarrassing result, such as a display issue or a minor data inconsistency. We move fast, and AI tools operate freely
Tier 2 — Where an error is expensive, such as a failed payment, a duplicate transaction, or an issue that requires someone to wake up at 2 a.m. for manual intervention. Those systems move with structured reviews and specific guardrails
Tier 3 — Where an error affects customer access, creates regulatory exposure, or introduces legal risk. Every change receives deliberate human review before it reaches production
We operate in 56 countries, so systems move into Tier 3 very quickly. An architectural pattern that seems harmless in one market can become a regulatory issue in another. We experimented with AI-assisted pull request reviews, but we found they weren’t sufficient. Every pull request is still reviewed by at least two engineers before it’s released.
The important thing is that the risk model reflects business and regulatory consequences, not just technical complexity. That’s how we balance using AI while maintaining the standards our environments demand.
Helping teams become AI-native
Not every PM adopts AI at the same pace. What’s your strategy for closing the gap?
The approach that consistently doesn’t work is leading with the tool. If you tell someone, “Try this AI tool, it’ll save you hours,” the response is usually, “I don’t have hours to learn something new.” That’s not resistance; it’s an accurate prioritization call. What works instead is making the output visible first.
I’ll have someone who’s already comfortable with AI produce a first draft of a specification or analysis, then hand it to someone who hasn’t adopted AI yet with one simple ask, like, “Find what’s wrong with this.” This is an invitation to do something they excel at, and, in doing so, they engage directly with both the AI product and where it falls short. The moment someone catches a meaningful mistake in AI-generated work, they stop thinking about being replaced. They become the editor of a very fast first draft, and that’s an identity that fits naturally.
At Unicity, we’ve also created a secure AI sandbox for product managers. They have access to approved enterprise AI tools, demo data, and a controlled environment where they can build prototypes without depending on engineering or production systems. The goal is to let PMs validate ideas with customers before asking engineering to invest in a full implementation. Once we’ve demonstrated product-market fit, the engineering team takes over and builds the production version.
That has dramatically increased adoption. One of our PMs came from a design background and had never written production software. Using the sandbox, he’s built multiple applications that customers are actively using and talking about. Seeing that success has encouraged other PMs to experiment as well. We also run an AI Guild where PMs, TPMs, and engineers share what they’ve built, whether it’s a customer-facing product or an internal workflow improvement. We even reward impactful AI projects because we want experimentation to become part of the culture.
At the end of the day, I come back to the same two principles: be curious, and act. Ideas are valuable only when you put them into practice.
There’s a version of the future where the PM becomes a generalist who does everything (discovery, design, code), and a version where specialization wins. Where do you foresee the profession going?
My prediction — and I’m willing to be wrong about this — is that within three or four years, a full-stack PM who can run discovery through deployment will become the baseline. The interesting question won’t be whether you’re a generalist or a specialist, but what you know that nobody can replicate simply by prompting AI.
The backend systems we manage, like order management, payments, distributor compensation, authentication, and regulatory workflows, take years to understand. Good documentation helps you understand how a system works, but it doesn’t teach you how to make judgment calls. That comes from watching things break, analyzing why they broke and understanding the downstream consequences two quarters later. AI can’t tell you why an architectural decision was made, what alternatives were considered, or which pieces of tech debt are actually carrying the system. Those things live in experience.
I’ve seen both sides of this. When you’re the person who made the original architectural decision, you understand the constraints that shaped it and the alternatives that were rejected. Someone equally intelligent but new to the domain simply doesn’t have that context. Not because they’re less capable, but because the relevant context doesn’t live in documentation. It lives in institutional memory.
When those people leave, the context leaves with them. The PM who captures that institutional memory is creating something that compounds over time. I think the combination that becomes genuinely valuable is broad operational capability as a PM, including discovery, design, code, and data, combined with deep expertise in a specific domain. Generalist skills become the entry requirement, and domain depth becomes what you compete on.
If you’re early in your career, build that broad range now, but also choose a domain and go deep. By the time you realize that expertise matters, you’ll already be behind the people who started earlier.
What advice would you give a PM to stay current in the AI era?
There are three things I’d focus on. The first is organizational memory. Why did we make this architectural decision? What did we try first? What happened? Which stakeholder objections are real blockers, and which are signals that something else is going on? AI doesn’t have access to that context unless someone builds a system to preserve it, and most organizations haven’t.
In cloud infrastructure, I’ve seen decisions made in one year continue shaping roadmaps three years later. By then, the people who made those decisions had moved on, and the reasoning had left with them. Engineers were forced to reconstruct that history from code that couldn’t explain itself. The PM who preserves that context becomes incredibly valuable.
The second is understanding the political economy of the roadmap. Every roadmap has a visible version and an actual version. The visible version is what the roadmap says. The actual version is who agreed to it, under what conditions, what trade-offs were made, and what happens to stakeholder relationships if priorities change. AI doesn’t have relationships with your VP or your CTO. It doesn’t know that the same concern means something very different depending on who’s raising it. Understanding those people and those relationships takes years, and better tools don’t compress that experience.
The third, and probably the hardest, is developing product judgment. It’s the ability to look at a specification, a prototype, or a feature proposal and know that something is wrong before you can explain why. That intuition comes from years of watching products succeed and fail, developing a feel for the gap between what looks good and what actually works. That’s the hardest skill to build, and the hardest one to fake.
PMs who invest in that judgment now, while everyone else is trying to outsource it to AI, will have something genuinely scarce five years from now.
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.