Building Nasscom’s 10,000 Startups
A director of product, author and angel investor on why he bets on founders rather than products — and the one mistake he has watched almost every founder make, including himself.
Watch the full episode on YouTube
Executive summary
Two decades in, our guest wears an unusual number of hats: director of product and operations, mentor at Nasscom's 10,000 Startups in Bangalore, angel investor, and author of a book on design thinking. He spent seventeen or eighteen years on the technical side before an MBA reorganised how he saw the work.
His own description of the shape of that career is the best opening image in the episode:
"My career journey has never been like a straight corporate ladder that I climb all the time. It's been more like a jungle gym — I've been swinging sideways, going down to be able to climb up again."
Three arguments run through the conversation.
First: you cannot get to the truth from data alone or customers alone. The principle he works from is compact — "data gives you the what, and the customer gives you the why." Follow only the dashboards and "I'll just be optimising for the clicks." Follow only the feedback and "I'll be chasing opinions." Neither produces a product. The answer is to triangulate, strip out the noise, and find the pattern where both agree.
Second: the biggest myth in customer-centric design is that the customer knows what they want. He reaches for the two canonical examples — nobody asked for an iPad ("I have a phone, why would I need a notepad?"), and Ford's customers would have asked for faster horses. The obligation is still to listen. It is just that "customers will not be able to articulate the requirements exactly", and your job is to give them the thing they could not put into words.
Third, and the one he applies to his own money: back the founder, not the product.
"If the founder is good, then even if the product is not doing that well, he can go to the market with another product and still be a winner. But if the founder is bad, you give the best product and you can sink a ship — Titanic also."
The story
Each company taught him one thing, and he names them cleanly. Dell taught customer obsession. Juniper and Ericsson taught global strategy and scaling. Startups taught something else entirely:
"In startups, you just have to put on your parachute and jump into the unknown. You just don't know where you land."
What was constant across all of it was position rather than title. From the very beginning he sat between the customer and the technology — "being the bridge between the two" — and found that the interesting problems lived in the gap.
The turning point was the MBA, taken after nearly two decades of technical work. He is precise about what changed, and it was not skills:
"That gave me a complete paradigm shift into the holistic view of how a business runs — not only from the technology point of view, but the money. Where the money comes from."
The claim he draws from it is worth pausing on, because it is the argument for business literacy among technical people: understanding where requirements originate lets you "build better products which are closer to what the customer needs." Not different products. Better ones.
Mentoring began almost incidentally — guiding juniors during the MBA, then a group of three continuing pro bono consulting beyond the academics. That group got listed as mentors at Nasscom's 10,000 Startups in Bangalore, part of the K-Hub incubation centre.
What he found there was range. Freshers, dropouts, people with ten and twenty years behind them — "an interesting mix, and everybody who are at zero." All of them needing the same thing: how to get from zero to one. He has since helped solopreneurs find co-founders and take companies forward.
His framing of why he keeps moving: "to be able to predict the future, you should create it."
Key decisions
Decision 1 — Treat reinvention as a muscle, on a schedule
He does not wait for disruption to force a change. Every few years he deliberately picks up something he has never done — most recently SaaS growth models and AI, after eighteen or nineteen years without touching either.
"It's easy to settle down in some area and then get complacent and get into your comfort zone. But I need to get uncomfortable to be able to learn something."
The method is not to chase novelty but to combine: "blending the foundation skills — like customer focus — with the latest tools." Three or four years ago machine learning was not in his forte; he has since put in enough hours that "I can converse with the new kids about AI."
Decision 2 — Reframe the product before you rebuild it
The most useful war story in the episode. He had a lightweight SaaS product — easy to install, easy to use, affordable, few features. Startups loved it. Enterprises would not look at it.
The reason had nothing to do with quality. Enterprises wanted certifications, audit logs, integration with legacy systems, and without those "they will not even bother to have a look at the demo. We will not be called for a product demo in the first place."
The fix was not to change the product. It was to split it: a light version for startups with minimal features, and a secure enterprise-grade version with the certifications and audit logs. "The traction was immense. The product also skyrocketed."
His generalised lesson:
"Instead of looking at changing the product, if you're not seeing the right kind of traction, you just have to consider reframing the product."
He is careful not to oversell it as a universal answer — building the enterprise version costs real money, needs a boardroom decision, and lands on a roadmap whose timing depends on demand and finances. Their approach was to run both: keep the lightweight version earning in its segment, and fund the enterprise build from it.
Decision 3 — Start with the repetitive, then move up to judgment
On where AI belongs in a product, his sequence is unglamorous and practical. First, repetitive tasks — "that is my first low-hanging fruit for AI." Then workflows that need decisions, which is the genuinely new part:
"Earlier only automation was possible. Today we can have these machines think and decide also."
In sales he sees this working across lead generation, follow-ups, closures, demos and POCs — with a supervision layer and notifications that surface the moments the agent cannot decide, so a human can step in and course-correct. In post-sales support, he draws the line between old chatbots that escalated to a call centre when they ran out of data, and current systems that search their own domain, go back to RAG, and return with an actual answer.
Mental models
Data gives the what, the customer gives the why
His antidote to both failure modes. Optimising purely for dashboards produces click-chasing. Optimising purely for feedback produces opinion-chasing — and "you don't have to build a product based on one person's view." Triangulation is the discipline of taking both, removing the noise, and finding the convergence.
AI is fire
His answer when asked about the blind spot for product leaders deploying AI:
"It's like a fire — you can use it to cook food, or it can burn the place."
Biases, hallucinations, governance and compliance are not optional extras. A product leader who deploys "in haste, without having any guardrails" has created the blind spot themselves.
The product leader as translator
Asked how he keeps engineering, business and customers aligned when all three speak different languages:
"Engineers talk code, the business talks revenue and money, customers talk pain points. You try to be the common point of contact and talk in a common language that is understood by all."
That common language is impact. It is the one currency all three parties can price.
Stay with the problem
His answer on what separates good product thinking from fast product thinking:
"As a product manager, you stay with the problem long enough and then arrive at the solution. Don't jump to the solution."
The pushback in the conversation is the obvious one — surely more questions means reaching the solution sooner? His correction is the sharpest exchange in the episode: "You can reach the solution sooner, but it might not be the right solution." Living with the problem is what makes the eventual answer correct, not merely quick.
Frameworks
Framework 1 — The four-metric hype test
The cleanest filter he offers. Any AI initiative must move at least one customer-facing metric:
- Cost — is it cheaper?
- Speed — is it faster?
- Accuracy — is it more correct?
- Experience — is it better to use?
"If it doesn't help in any of these customer-facing metrics, it's hype."
He then sequences the returns, which is the part most teams get backwards. Efficiency is immediate — "instead of having eight people work for you for three months, you can have an agent work for you for eight hours." Experience is lasting, because once deployed it persists across versions. Revenue growth comes last, and only if the first two are solid:
"That is where you need to make sure these two are rock solid — the efficiency and the experience — and only then you try to see some growth. Otherwise it'll all be a facade."
Framework 2 — What he looks for in a founder
Not the product. Everybody is enthusiastic about their product; that carries no information. What he listens for is whether they can explain "why anybody cannot ignore it" — the solid why.
Underneath that, one trait: curiosity. And one disqualifier that no amount of coaching fixes. A weak go-to-market or muddled positioning is repairable — "we have many people who can guide them towards the right GTM strategies" — provided the founder arrives with humility.
"The thing is, we cannot fix his arrogance."
He extends this to how founders should think about pitching at all: the pitch is not about the product or the company. "You yourself is the product." Attitude, aptitude, and whether people can work with you.
Framework 3 — Hiring a product manager
One signal, stated as a test you can run in an interview:
"More than answering your questions — the kind of questions he is asking you. If he's asking you more questions than you are, then he is the right fit."
The reasoning connects back to staying with the problem: asking many questions is how someone covers every angle of a situation before committing to an answer.
Framework 4 — Build right, listen wrong
The most quietly useful idea in the episode, and his stated antidote to founder self-deception:
"When you're building something, build it thinking that you're right. But listen with the approach that you are wrong. That brings in the balance and sanity."
Conviction while building, humility while listening — held simultaneously rather than alternately.
Lessons
The mistake almost every founder makes, and he includes himself: "falling in love with the product, then trying to find whether there is a need for this product." You overlook market validation, and — the specific trap — you mistake encouragement from a small group of peers for validation from a market. "That is not feedback, that is encouragement." His own biggest learning came from a startup investment that went wrong for exactly this reason: "a lot of enthusiasm, which was confused to be market validation."
Founders come in every shape, and all of them are at zero. Freshers straight out of mass communications degrees show up with ideas as strong as people with twenty years behind them. What differs is energy, not the need for 0→1 guidance.
Angel investing requires actual homework. He describes peers who pool capital and bet on what will be relevant in five years rather than what is trending now, and is candid that he prefers "safe bets and known devils." Either way the requirement is the same: pick a niche, follow it closely, and do the technical analysis. Without it "you'll be shooting in the dark."
Storytelling is the most underrated skill for a product leader. His examples: Steve Jobs pulling an iPod out of his jeans pocket and naming the number of songs it held; Netflix trailers, where "some of these trailers are better than the movies." The blunt version — "if you have a very good product backlog and you don't build a narrative, you won't be able to sell."
Simplicity is the harder discipline. Asked what he would do if he were not in product, he says teach — and the thing he would teach is "make complex things simple." His example of failure is domestic and perfect: bathroom taps that have become impossible to operate because three different lines feed into them.
What he would change: start sooner. "Until you dive into the swimming pool, you will not learn swimming." He thought he was assembling the skill set, mindset and tool set for entrepreneurship. In hindsight the assembling was the delay.
Actionable advice
If you are building a product: triangulate data and customer conversation rather than picking one. Then remove the noise and look for the pattern.
If your product is not getting traction: before rebuilding it, ask whether it needs reframing — different versions for different segments, same core.
If you are introducing AI: take the repetitive tasks first, then the decision-bearing workflows, with supervision and an escalation path. Test every initiative against cost, speed, accuracy or experience.
If you are pitching an investor: be able to say why the world cannot ignore this. And bring humility — the strategy gaps are fixable, the arrogance is not.
If you are hiring a PM: count their questions.
If you are a founder in love with your idea: go and validate it in the market. Your friends' encouragement is not data.
Reading: Inspired by Marty Cagan — "like a thesaurus for product managers... read it every year, it gives a new angle." From his own book, three lines he keeps: "Design is not just what it looks like and feels like — design is how it works" (Jobs); "the real act of discovery consists not in finding new lands but in seeing with new eyes" (Proust); and the one that ties the whole episode together — fall in love with the problem, not the solution.
Final thoughts
The jungle gym is the right image for this conversation, and not only as autobiography. A ladder has one direction and a fixed set of rungs; you can be good at it by never letting go. A jungle gym rewards something else — being willing to drop a level, move sideways, and give up a position you had already earned.
Almost every piece of advice here has that shape. Reframe the product rather than defend it. Hold conviction while building and assume you are wrong while listening. Stay with a problem instead of escaping into a solution. Fall in love with the problem, not the thing you built to solve it.
It also explains why he backs founders over products. A product is a position — it can be right today and wrong in eighteen months. A founder who can let go of one and find the next is the thing that survives the change. Which is, in the end, the same reason he keeps flexing the muscle every few years, and the same reason his only regret is not having jumped into the pool sooner.