Side hustles in the age of AI
She landed an AI product role in two weeks without ever sending a resume — because she had built the thing the company needed instead. A working method for turning side projects into a career.
Watch the full episode on YouTube
Executive summary
Our guest is an AI product manager, previously a founding PM at a startup, an Amazon best-selling author on side hustling, and a mentor to more than a hundred aspiring product managers. She spent four or five years as a traditional PM before moving into AI — and is firm that the distinction is smaller than people assume:
"AI product management is also a subset of product management. A lot of times people mistakenly feel that maybe it is something very different. It is not — you have to be a product manager to be an AI product manager."
Three ideas run through the conversation.
First, and the one with the most immediate practical value: she got her AI product role in about two weeks, without submitting a resume or a cover letter. She built two AI agents as side projects, messaged a founder directly on LinkedIn with the links, and received a Calendly invitation in reply. Three or four interview rounds followed. Her projects did the work a CV usually attempts.
"The resume is sort of the theory of what you can do. But if you want to market yourself very well, you have to show it in a practical way — and the best way of showing that is actually doing that thing."
Second: the barrier that used to sit between an idea and a working product is gone. As a PM, every project she led required finding a developer first. "When AI came into the picture, the barrier of me finding a developer was no more there."
Her formulation of what that means for everyone else is the sharpest line in the episode:
"AI is not going to take your job. Anyone who is using AI is definitely going to take your job — because they will do your job in 10x less time and maybe 5x more effectively."
Third: pick a domain, get genuinely good at it, and then have the courage to leave. Her own path runs through a Formula Student racing team, a Google fellowship, and a Google interview she cancelled.
The story
She grew up in Uttar Pradesh and describes the start of her career as almost entirely unchosen. She went to the first engineering college that came up at counselling. Asked which branch, she asked her father — an electronics engineer — who said take electronics.
"I was like, okay. Because I didn't know anything back then."
What follows is the interesting part, because she treated the accident as a starting position rather than a sentence.
First year: she started a Formula Student racing team, building the PCB for the race car's steering. The team was selected to present in Germany. "It was like a peak moment for me." And then, coming back:
"I realised maybe I'm not enjoying it anymore. Even though I'm at the top 10, 20 percent... I cannot do this for a very long time."
So she left the team.
Second year: software development was the thing everyone said to learn, so she self-taught coding — and won a Google Women Techmakers fellowship, one of only five or six selected from a non-software background. She worked there two years and loved it. But the same honest assessment surfaced:
"When I was doing software development, I realised I might not be at the top 10 percent out there. This doesn't come naturally to me... I'm more of a people's person."
Then the decision the episode keeps returning to. She had a Google interview scheduled, and she cancelled it.
"My parents were very sad for that, and I think that's something you have to live with. But then I had the courage to say no."
Marketing came next, then — in her fourth year — product management, which she recognised as "an intersection of technology, design, marketing, business." That one stuck.
Key decisions
Decision 1 — Treat your job search as a product problem
The method behind the two-week hire, and it is a genuine framework rather than a lucky break.
"If you are applying for a job, you are the product. You are something you want to market yourself... and the target audience will be all the people who are looking out for someone like you."
The steps:
Niche down first. She picked the industries she had already worked in, on straightforward reasoning: "the industries you have worked with before are highly likely to hire you compared to some very different industry out there."
Build the direct use case. Targeting AI marketing, she built an AI copywriter and an AI competitive analysis tool — the exact things those companies do.
Reach the decision-maker directly. Not the job portal — "LinkedIn jobs is not basically the right portal to apply, if you would ask." A direct message to the founder with the projects attached.
She also points at where hiring is heading: Perplexity, Google and LinkedIn have moved away from resume-first processes toward "just submit your work, tell us what all you did." Her reasoning for why is neat — "everyone is applying to jobs via AI, and people are also evaluating [them] via AI." When both sides are automated, the artefact that survives is the thing you actually built.
Decision 2 — Build what you would use
Her first rule for choosing a project, and the one she says most people get wrong:
"Build something that you will use. There should be at least 100 people exactly like you in a similar domain — you know your pain points very well, you know how this works. Rather than picking a random industry, random product."
Her writing tool came from exactly this. As a writer she looked at Jasper and Writesonic producing SEO-optimised blogs, and found the same flaw every time: "they sound very robotic." Digging into why, she landed on neuromarketing — writing to a person's emotions rather than listing features — and trained a model on those principles instead.
She is also honest about what it was: "it's still like a wrapper." The point was not to build a defensible company. It was to solve her own problem, learn the process, and end up with something to show.
The second rule is even simpler: "if you are finding something paid, you can just build it yourself. That is very easy." Her competitive analysis tool came from exactly that.
Decision 3 — Write the book because you are repeating yourself
The trigger came from a podcast she cannot name: "if you have to explain a query more than twice, write a blog. If these queries are more than 10, write a book."
She was explaining the same journey individually to everyone who asked. So she wrote it in 90 days, self-published, with her own illustrations — deliberately not waiting six or seven months for a traditional route.
"That is also the thing with experiment. If you are experimenting with something, you need to have a timeline."
Decision 4 — Keep the nine-to-five
An unusual position for someone who wrote a book on side hustling, and she makes the case well:
"You get a lot of ability if you are already having a corporate job. You can experiment more, you can fail more, you can actually do things which are not very high paying."
She loves writing but chose not to make it the income. Being a highly-paid writer "would have to go a very different route, and the chances of me being successful are also very different." Product management pays; the rest is exploration.
Mental models
The three decisions
Quoting Naval Ravikant, and the frame she credits with organising her own choices: what you are doing, who you are with, and where you live.
She emphasises the tense on the first — "something that you are doing at this very moment, not something you will do five years from now."
On the second, she rejects the separation people usually maintain: "a lot of people take career and personal life very separately. I personally don't think this is how it works." Friends, partner and family directly shape motivation.
The third is the one she thinks gets ignored: "where exactly are you living directly impacts the kind of opportunities you will get."
And the corollary, which is uncomfortable and useful: "if you are the smartest person in the room, you are definitely at the wrong room."
Top 10%, then decide
The framework her whole career demonstrates, and it has two failure modes it is designed to prevent.
"Pick anything that comes naturally to you... try to be the best at that one thing. Do not pick something for say one week and say this is not working out — that is not how it should be. Always reach to a point where you are at least in the top 10 percent, top 20 percent out there. And then take a decision."
The first failure mode is quitting before you know anything. The second is staying because leaving would waste the effort. Racing and software development both passed the competence test and failed the honesty test, and she left both.
The Mom Test
On building something people want rather than something they say they want:
"If someone is just saying yeah, this is a nice product, I will use it — they are not going to use it. That is for sure. They are just saving your feelings."
She pairs it with a line from Naval Ravikant: "you cannot fool mother nature. You can fool your parents, you can fool your friends" — because those people are protecting you. An MVP in the market is the only place the feedback is real.
Never be loyal to a tool
"There is no concept of loyalty in terms of AI."
Her actual debugging order when output is wrong: change the prompt first, reason with it properly, and only if that repeatedly fails conclude "maybe that's not the right tool for you." Then go find what is.
She also makes a point most tool comparisons miss — competing products are often identical in capability and differ only in who they are built for. Lovable and Replit both build full-stack applications. "Replit is a tool for developers more", speaking the language developers already know, while Lovable serves non-technical builders. "Same tools, same platform... all of these platforms are more or less about one particular persona."
The possibility mindset
The thing she names as her single takeaway if a listener remembers nothing else:
"You have to believe that you can do everything. You just have to stay in the game and optimise for as long as it takes to get the results."
Her grounding for it is refreshingly unmystical: "everything is learnable. If there's a software developer out there, you can also become a software developer. All of these things are skills." Public speaking, writing, publishing a book were each once a dream and are now done.
Frameworks
Framework 1 — The four sections of the book
Idea. Start with your own life. "There is a reason you [are] in that life, with these circumstances, with these challenges... If you can solve for your own self, you are actually solving for a lot of other people who are exactly like you."
Two additional filters: what you are naturally good at, and what you never find boring. Her own test is precise — across ten years of writing she has often said "maybe I'm not able to find time", but never once "this is boring." And a good external signal: notice what your friends come to you for.
Ideal audience. "A same solution can be very different if you just change the audience." Entertainment for a newborn, a young adult and an elderly person are different products entirely, even when the goal word is identical. Her standard for specificity: "25-year-olds, working in corporates, living outside their home."
Product. Build the MVP small, for a narrow community, and launch it fast to get feedback that is not politeness.
Launch. Find the channels those particular people use, scale what works, and — the part she flags as personally hard — "do not feel very bad to let go of ideas that have not worked out."
She gives her own example: two projects inside a female-focused community, an idea she believed in and "clenched for a very long time, longer than I should", before accepting it was not going to scale.
"Do not be blinded with your opinions. Experiment, take results, be aware of your biases."
Framework 2 — Jobs to be done, applied to your colleagues
Her method for communicating the same work to different people, which she uses in place of traditional PRDs — "more or less we are communicating in terms of prototypes rather than PRDs."
The question is always: what job does this person need done?
- A developer needs to know why you are building it and what exactly you are building
- A salesperson does not care what you are building at all — "they will just care about how is it beneficial for them." Is it more sellable? Is it a unique proposition for existing customers? Does it open new ones? Which metrics move?
"If I just explain this marketing strategy to a developer, they do not care — that's not their job, they're not being paid for that. If I explain the tech details, a salesperson will not care."
Framework 3 — Context engineering
Why the first answer from any AI tool is generic, and what to do about it.
"There is a section of project in ChatGPT, spaces in Perplexity, or whatever tool you use. Create a new project, give all the information you have — I'm a product manager, I do this, these are my projects, this is the company, these are our competitors."
Then every conversation inside that project starts already knowing the situation. "To get better results, you have to provide as much clear and as much context as is possible."
Framework 4 — The stack she actually uses
- ChatGPT — general research, keeping up with what is happening
- Perplexity — deeper research and infographics
- Lovable — building without writing code; "it creates very good UI"
- Supabase — the backend Lovable pairs with, though she prefers Google Firebase
- Cursor — once a project needs to scale; "hands down best tool out there"
- GitHub, Vercel — still the foundation, because "AI is just helping people to do what they used to do"
Lessons
Her own role has changed shape three times in three jobs, and the trajectory is the clearest evidence of where the industry is going.
Job one: write the PRD, brief a designer, hand the designs to a developer, test the result.
Job two, at a startup as AI arrived: no designer, so she was the designer — building prototypes in Lovable and presenting them to developers, and, notably, to clients for validation before anything got built.
Job three, AI-heavy: also a front-end developer, because Lovable produces the front-end code.
"So I was a product manager, then a product manager and a designer, and now a product manager and a designer and a front-end developer."
The roles are converging. Her reading of the data — and she admits she went looking because she was worried about her own job — is that PM, design and development are merging into something called a product engineer or AI builder, with those postings rising while traditional PM roles decline.
"If you stay in your very traditional ways... anyone who just says this is how the work used to be — that's the very first sign that you will lose your job."
Vibe-coding rounds are now standard. She has been through one. Microsoft, Google, Shopify and most startups now include them — and she frames it as a gain rather than a hurdle: "it is also empowering to product managers to build something of your own, rather than putting just a theory out there that we can do this."
On what AI actually is: "AI is also a tool that is helping you to do the existing job in a very better way." The barriers are what changed — you don't know how to code, there's a tool; you don't know how to find the right people, there's a tool. "The barriers of doing the same thing you used to do are now gone."
On starting out with no idea what to do: "just experiment as much as you can. Whenever you are experimenting, you will realise that maybe this is something I do not want, or maybe this is something I can scale."
Actionable advice
If you are job hunting: build the thing the company does, and send that instead of a resume. Message the founder directly rather than applying through the portal.
If you are choosing a side project: solve your own problem, and check that at least a hundred people are enough like you to share it. If a tool you want is paid, build it.
If you keep explaining the same thing: write it down. Twice means a blog post; ten times means something longer.
If you are stuck deciding on a career: get to the top 10–20% of something before judging it, then be honest, then be willing to walk away from the sunk effort.
If you are working with AI tools: fix the prompt before you blame the tool, and abandon the tool without sentiment when the prompt is not the problem.
If your AI output is generic: stop prompting cold. Build a project with your context loaded in, once.
If you are talking to a colleague about your work: ask what job they need done, and lead with that. The developer and the salesperson need different halves of the same sentence.
And if you take one thing: believe it is learnable, and stay in the game long enough for the results to arrive.
Final thoughts
The most instructive thing here is not the two-week job search, impressive as it is. It is the Google interview she cancelled.
By every conventional measure she was winning. She had taught herself to code, won a competitive fellowship as one of a handful from a non-software background, worked two years, and had the interview most of her peers were optimising their entire degrees toward. Her parents were, in her words, very sad. She went anyway — in the other direction.
What makes that defensible rather than reckless is the framework around it. She did not quit because it was hard. She quit having reached a level where she could see clearly what being excellent at it would require, and having concluded honestly that she would not get there, and would not enjoy trying. That is the difference between the top-10% rule and simply following your interests: it insists you earn the right to your own verdict.
The same discipline shows up everywhere else in the conversation. Build what you would use, so the feedback is real. Launch small, because compliments from friends are not data. Drop the idea you have been clenching too long. Never be loyal to a tool. Each is a version of one instruction — get close enough to know, then be willing to be wrong about what you find.