Stanford Engineering in an Indian Startup: How Signal Processing Intuition Shapes How I Think About Product Problems

Everything is signal and noise

The most fundamental idea in signal processing is that you're always working with a mixture of what you want to know (signal) and everything else (noise). The discipline is about building techniques to separate them reliably.

In product work, you're doing exactly this constantly.

Your user research produces noise: people say what they think you want to hear, describe solutions instead of problems, conflate frustration with frequency. Your analytics produce noise: click events tell you where users went, not why; funnels tell you where people dropped off, not what was in their head when they did. Your team discussions produce noise: the loudest voice is rarely the most informative one.

Signal processing taught me to be suspicious of raw data. Not dismissive of it — the data is telling you something real — but suspicious of the first interpretation. The useful signal is almost always one transform away from what you're looking at directly.

Concretely: when a user says "I want a search feature," the raw signal is a feature request. The actual signal — what they're really trying to tell you — is usually that they can't find something they already know is there. Those are different problems with different solutions.

The SNR question I ask at every product review

Signal-to-noise ratio is a way of quantifying how much useful information is present relative to interference. A high SNR means the signal is clean and you can trust what you're seeing. A low SNR means you need more data, better methods, or a different framing before you make decisions.

I ask a version of this question at every product review I run: "What's the signal-to-noise ratio on this insight?"

The question forces people to be honest about how they know what they think they know. Is this based on interviews with 20 users or a conversation with 1 loud customer? Is this a pattern across segments or an outlier in the data? Is the person presenting this insight close enough to the original source to be reliable, or has it been through three layers of telephone?

Most product teams don't make bad decisions because they're bad at analysis. They make bad decisions because they don't track the quality of their evidence carefully enough. The SNR framing gives teams a vocabulary for that conversation without it feeling like an attack on anyone's judgment.

Systems thinking as a product superpower

The other thing engineering at Stanford gave me was a thorough grounding in systems thinking — understanding how components interact, where feedback loops exist, and how instability propagates through a system.

When I look at a product, I see a system. Not just the features, but the relationships between them: how the onboarding flow shapes the first-week habits that determine 30-day retention; how the notification strategy either trains users to pay attention or trains them to tune out; how the pricing model creates incentives that shape which users you acquire and what behavior they exhibit after they arrive.

Most early-stage product thinking is component-focused: "should we build this feature?" Systems thinking asks: "if we build this feature, how does it change the behavior of every other part of the system, and are we ready for that?"

The answer is sometimes yes, let's build it anyway. But the systems question changes the quality of the decision.