What I had to unlearn going from project manager to founder

From 2020 to 2026 I was a Technical Project Manager at Vagaro, a global software company for salons and spas. Before that I spent years as an Assistant Project Lead. Then in 2026 I started Bolo Media. The move from technical project manager to founder looks natural on paper, and in many ways it is. But some of my best habits turned out to be the wrong ones for the new job.

Why a technical project manager to founder move looks easy

A technical project manager already does a lot of what a founder does. You plan work, weigh trade-offs, talk to engineers and to the business, chase blockers, and keep many moving parts in view at once. You are used to being accountable for outcomes you don't fully control.

So it's tempting to think the jump is small. Same skills, new title.

It isn't quite that. The skills mostly transfer. The instincts behind them often don't. A project manager's instincts are tuned for an environment that already exists: a company with a product, customers, a roadmap and people whose job is to decide. A founder has none of that on day one. You are building the environment, not working inside it.

I won't share anything about Vagaro's internal work here. That isn't mine to publish. What follows is about the role itself, which is common across many companies.

Five habits I had to unlearn

1. Waiting for the decision

In a good project management role, a lot of your work is getting the right decision from the right person. You frame the options, lay out the trade-offs, and take them to whoever owns the call.

As a founder, there is nobody to take it to. The person who owns the call is you.

That sounds obvious. In practice, I think the habit shows up in small ways: wanting one more data point, one more opinion, one more round before committing. In a large company that care is valuable. In a tiny one it just slows you down. Most early decisions are reversible, and a reasonable decision today usually beats a better one next month.

2. Predictability as the goal

Project management prizes predictability. Good estimates, steady delivery, few surprises. A project that lands on the date it promised is a success.

Early-stage building is the opposite kind of work. You don't know yet what the right thing to build is, so being predictable about building the wrong thing is no help. The goal is to learn fast, which means running small experiments whose results you can't predict, and being comfortable with that.

I still plan. But I plan differently now. Instead of "deliver X by Y", it's closer to "find out whether X is true, as cheaply as possible, before spending on it". The plan exists to put a gate after the cheapest step that could prove me wrong.

3. Process as protection

Process is a project manager's friend. Templates, reviews, sign-offs and status updates keep a large team aligned and stop expensive mistakes.

For a very small team, most of that is weight. Every review step you copy from a larger company costs time you don't have. I've had to ask, of each habit, "does this protect something real here, or am I doing it because it's familiar?"

Some process is still worth it. Writing things down. Checking your assumptions before you build on them. Keeping a record of what you spent and why. Those stay. The ceremony mostly goes.

4. Done means shipped

In many project roles, "done" means delivered: the feature is built, tested and released. The project closes, and the team moves on.

For a founder, shipping is where the question starts. Did anyone use it? Did it help a real business make a better ad? Would they pay for it again? Those questions don't have a closing date.

Measuring status (on track, at risk, done) is a project manager's daily language. Measuring outcomes (used, valued, paid for) is a founder's. It took deliberate effort to stop counting tasks finished and start counting whether anything changed for the customer.

5. Someone else watches the money

In most companies, a project manager tracks a budget, but the money is the company's. Someone else worries about cash.

As a founder, every rupee spent is a decision I own. I have become strict about it. Before I spend on anything with a meter running, I want to know what it will cost and whether the assumption behind it has been tested. I've written about the AI side of that in self-hosted GPU or API: how I decide.

What I'm glad I kept

Not everything had to go. Some project management habits are a quiet advantage for a founder:

That last translation point matters most to me. At Bolo Media we make video ads for small and local businesses, with natural voices in Gujarati and Hindi. Understanding what a shop owner means, and turning it into something a system can produce, is translation work. Project management trained me for it.

The honest summary

Going from technical project manager to founder is less about learning new skills and more about retuning old ones. The planning stays, but it serves learning instead of predictability. The writing stays, but the ceremony goes. And the decision you used to escalate is now yours.

If you want the full path that led here, I've laid it out in from Android developer to founder. I'm still early in this, and I expect to find more habits worth unlearning. That is probably the point.