← All writing

From founder to product manager: lessons from building inside enterprise SaaS

Nikunj Thakkar4 min read

#product management#saas#lessons#whatfix#plivo

Illustration: a compass resting on a roadmap next to a tall tower of stacked building blocks

When our team was acquihired by Whatfix in 2020, I went from running a small company to being a product manager inside a fast-growing enterprise SaaS business. Later I led product for Contacto, Plivo’s omnichannel contact center product.

Being a founder and being a PM look similar from the outside. Both are about building the right thing. From the inside they feel very different. Here’s what those years taught me.

Small features are never small

In enterprise software, a steady stream of small enhancement requests comes your way. Usually it’s a salesperson or a customer success manager, and the pitch is always the same: “It’s a small, low-effort change, so let’s just do it.”

I’ve watched many PMs say yes. Here’s why I learned to be careful.

  • Adding is cheap. Removing is almost impossible. Once even one enterprise customer uses a feature in a particular way, changing or removing it becomes a project of its own.
  • Tech debt compounds. Each small enhancement adds a little complexity that nobody wants to touch later. Over time it becomes a mess.
  • Low-hanging fruit runs out. At some point the fruit-picker has to bring out a ladder. If your roadmap is all quick wins, you never build the ladder.

What helps:

  1. Group similar requests and prioritize by how many customers they affect and how much value they create.
  2. Look at long-term impact, not just effort. Many small requests disappear into a bigger planned upgrade anyway.
  3. Learn to say no. It’s the most important skill a PM has.
  4. Explain the better answer. If something relevant is already planned, show the customer why it will serve them better.

The best validation a PM can get

One of the most satisfying moments as a PM is getting a feature request from a customer for something you’re already building or about to ship.

It tells you two things at once: you picked up the customer’s pulse early, and you’re on the right path.

Constraints make you better

Most engineers and designers love greenfield projects. I get it. But in my experience, the real test of skill is bringing something genuinely new into a legacy product.

A lot of my Whatfix work was exactly that: revamping the analytics platform that 600+ enterprise customers already depended on, migrating them onto it, and then building a new no-code product analytics line on top of it. Constraints force ideas you’d never reach with a blank page.

Sell solutions, not software

In early 2023 I spent time with early-stage founders, and one conversation stuck with me. A founder was struggling to stand out in a crowded market. They had decent early traction but kept asking “What should we build next?” instead of “Why are customers having this problem?”

My advice was to stop thinking of the business as Software-as-a-Service and start thinking of it as Solution-as-a-Service. Customers don’t buy software. They buy an outcome. When you see yourself as the solution provider, you tailor the product to real needs, help customers implement it, and stay with them until it works. That’s also what makes you hard to replace.

Read your earliest data carefully

I’ve watched many SaaS teams misread their first days of user data. The pattern is familiar: a launch-day surge of curious users, promising early engagement, then a flatline two weeks later and a scramble to understand why.

Early behavior tells you a lot if you know what to look for. The three signals I pay most attention to:

  1. Return rate. Not sign-ups, but how many people come back after day one. If fewer than about 20% return, I treat that as a warning.
  2. Core action completion. The one action that delivers your product’s value. If fewer than about 30% of users complete it, there’s a relevance problem.
  3. Time to value. How fast someone experiences what you promised. Every extra step between sign-up and value is a chance to lose them.

Spending a few days obsessing over these before building more features can save months of building in the wrong direction.

Build teams with context, not rules

A common debate in product orgs is whether to hire from within or bring someone in from outside. I don’t think there’s a universal answer.

  • If you need stability and execution, look within. Institutional knowledge and trust matter.
  • If you need a transformation or a new capability, look outside.
  • If you need a culture shift, mix carefully.

The real skill is knowing when to lean on existing understanding and when to bring in new DNA.

What I took with me

At Whatfix, the no-code product analytics line we built grew quickly in 2022, and the analytics team won the company’s Outstanding POD award. None of that happened because of one person. It took engineering, product, customer success, marketing, and sales pulling in the same direction.

At Plivo, I saw something rare: a company that was efficient, customer-obsessed, and full of people with an entrepreneurial streak. It reminded me that discipline and ownership matter more than headcount.

The biggest lesson from those years is simple. Being a founder taught me to care about the whole business. Being a PM inside larger companies taught me how to make that care scale: through clear priorities, good judgment about what not to build, and teams that trust each other.