“Who do you think can become a product manager?”

I didn’t have a polished answer ready. So I just said what I actually believe.

It Starts with Noticing Things

Not big things. Small, silly, everyday things.

Your grandmother forgetting to take her medicine. Your mom struggling to track expenses. You, sitting in the middle of a job hunt, with no real visibility into what is actually working and what is not.

Some people notice these things and move on. Some people cannot let them go.

Share

I Built Something for Myself

I am job hunting right now. I realized I had no data. I was doing things, but I had no idea which things were helping.

So I built a simple tracker for myself. Every day, I log:

• How many applications I filled

• How many HR calls I received

• How many interviews I gave

• My sleep that night

• My anxiety levels

• My confidence and energy

I have more than a month of data now. When I look at it, I can actually see patterns. On days my sleep is poor, my confidence scores are lower. On days I have back-to-back interviews, my anxiety spikes but my energy stays steady.

I still do not have a new job. But I have data I did not have before, and that feels like something.

I Also Had a Problem with Interviews Themselves

Early on, I was underconfident. I knew the answers but could not get them out clearly in real time, under pressure, on voice.

So I built a system. I set up Claude to generate four mock interview questions every single day. I used Wispr Flow to answer them by voice, not by typing. I gave myself a time constraint.

After a few weeks, something shifted. I could process my thinking faster. My answers became cleaner. I stopped freezing.

I did not take a course. I just kept trying things until one of them worked.

Subscribe now

The Medicine Tracker Question

During one of my mock interviews, I was asked: “How would you design a medicine tracker for diabetes patients?”

The first thing I did was stop and define the user. Not a category. A specific person -

I am a 45-year-old woman. I take diabetic medicine twice a day, morning and afternoon. I can navigate a basic mobile app. I understand simple English, not complex workflows.

I face three problems:

1. I need a family member to remind me to take medicine. Without that nudge, I forget.

2. After taking medicine, I sometimes forget whether I took it. That leads to overdose.

3. Every three months, I need to report my medicine consumption to my doctor. Right now, I have nothing to show.

Once I had those three problems written down, the features almost wrote themselves.

A simple app to log intake, just yes or no. Notifications so the app becomes the nudge, not the family member. A dashboard for the doctor’s visit.

Each feature existed because a problem existed first. Not the other way around.

The Structure That Made Sense to Me

I am not sure when exactly this clicked, but at some point I started approaching every product problem the same way. I believe this is how it is structured:

1. Define the user and their profile clearly

2. List the problems they actually face, specifically

3. Map every feature back to a problem on that list

4. Prioritize what is foundational before what builds on top

5. Flag what can go wrong, honestly

6. Define the metrics that tell you whether it is working

7. Connect those metrics to real impact

I did not learn this from a course. It is just what started making sense when I began taking problems seriously.

Share

What I Told Her

I told my LinkedIn connection that I think the people who become good PMs are the ones who cannot stop noticing problems and cannot help trying to fix them. Not because someone asked them to. Just because that is how they move through the world.

I do not think it starts with a course or a framework or the right job title.

I think it starts much earlier, when you notice something broken and your first thought is not “someone should fix that” but “how would I fix that?”

I am still figuring out a lot of things. But that part I feel fairly sure about.

Thanks for reading, more soon :)

Cheers,
Apoorva 🖇️

WHAT IS SPOTIFY

A platform to listen to music, discover new songs and podcasts. Simple as that.
The north star metric: Monthly active listening hours.

WHAT SPOTIFY GETS RIGHT

The first thing I do after opening Spotify is head straight to a top album or a Blend playlist with a friend.

Blend is my favourite feature on the platform. And I think it’s underrated. It doesn’t just play music. It uses music as a social connector. It calculates a match score based on both users’ listening history and liked songs, then builds a mixtape mixing both parties’ favourites. It updates every single day based on real-time listening trends.

I’ve used it as an icebreaker with strangers, cousins, and new friends. Works every time.

My only question for Spotify: why stop at two people? This could easily be a group activity.

The second thing I recently noticed is the mood-based filter under Liked Songs. My friend claims it’s old, but I noticed it this year. Either way, it’s genuinely useful. For someone with 550+ songs, creating separate playlists for every mood was time-consuming. This filter cuts that entirely.

Share

3 INSIGHTS

1. SMART SHUFFLE - right intent, wrong execution

Smart Shuffle was built to solve music discovery. The intent is good. The execution is not.

Here’s what actually happens: I’m listening to soft pop. I turn on Smart Shuffle. Spotify throws a high-energy Punjabi song in between, completely shattering the mood and tone of what I was listening to.

Discovery should feel like a natural progression, not an interruption.

2. MOOD FILTER- solves sorting, misses language

The mood filter is genuinely useful, I said that above. But it’s incomplete for multilingual users.

I listen to Hindi, English, Kannada, Bengali, Telugu, Nepali, and Spanish. My liked playlist has songs across all of these. The mood filter doesn’t account for language at all.

This isn’t just an Indian problem, though India makes it extreme given the number of regional languages. Countries like Spain, with co-official and immigrant languages, face the same gap.

3. RECOMMENDATION ALGORITHM- the data is there, the dots aren’t connected

Spotify’s algorithm fails to connect language preference, mood patterns, and social signals, even though it has access to all of this data.

People often say YouTube’s recommendation engine is better because it has Google’s data behind it. Here’s my counter: I don’t use Google to search for songs. So Spotify actually has almost everything it needs: search history, liked songs, language patterns, and Blend social data. It’s just not using it well.

WHAT I’D BUILD

Fix the recommendation algorithm, and fix it properly.

The algorithm should graduate through genres gradually. If I’m listening to soft pop, recommend pop next. Then pop-rock. Then rock. Then maybe something more energetic. Don’t jump straight to Punjabi.

This one fix cascades into everything else. Smart Shuffle becomes usable. Discovery feels natural. Listening hours go up. The north star moves.

One fix. Multiple problems solved.

WHAT I’D NOT BUILD

Short-form video content.

Instagram Reels owns that space. Spotify’s strength is audio — the immersive, uninterrupted listening experience that nothing else does as well. The moment it becomes a visual platform, it loses that identity.

I noticed Spotify has already started experimenting with short clips. I hope it pulls back. Stick to music and podcasts. That’s the moat.

Share

This was my attempt at a product teardown. Follow along if you want to join me on my job hunting journey!

Thanks for reading, more soon :)

Cheers,
Apoorva 🪩

Who is Substack for?

Substack serves three distinct user segments:

• Creative writers like me - using it as an outlet, not yet monetizing

• Solo entrepreneurs - building community and staying in touch with their audience

• Professional writers - for whom writing is a livelihood and monetization is critical

What is Substack?

Substack is a marketplace for readers and writers. Unlike Beehiiv or Ghost, which are content management systems built for marketers, brand managers, and solo entrepreneurs to own and grow their brand. Substack connects writers directly to their readers on a shared platform.

Share

The North Star Metric

After analysing how Substack makes money, I understood the north star metric of the platform -

Active paid subscriptions spread across writers

Substack earns a platform fee for every transaction that happens between a writer and their paid subscribers. This means the more writers monetize and the more readers pay, the more Substack wins.

Three Core Insights

1. Identity Crisis

While I understand the platform, the revenue model, and the north star metric, I realized there’s a core tension — an identity crisis.

Substack is built for articles, newsletters, and long-form content. Yet the platform is increasingly emphasizing short-form content through the Notes feature, which works a lot like Twitter.

While Notes helps with visibility and platform engagement, it is also deviating from the north star. Short-form drives engagement. Paid subscriptions require trust, depth, and long-form value. These are not the same thing.

“Substack’s business depends on paid subscriptions, but the product is increasingly optimized for short-form content, which risks conversion rate.”

Share

2. Monetization Friction

There is significant friction in setting up a monetized account, especially for writers from non-Western countries. Substack’s dependency on Stripe means writers without a business registration or GST number — like most independent writers in India — cannot easily monetize their accounts. This directly limits the growth of the north star metric.

This is not a product fix. This is a business and partnerships call — and needs to be prioritized by the respective teams.

3. Writer Retention Paradox

There is a writer retention paradox on the platform. Writers on Substack don’t own their audience — unlike Beehiiv or Ghost where writers have full control. If a writer decides to leave Substack, they cannot take their readers with them.

This works in Substack’s favour as a retention mechanism. But it also indicates concentration risk — if a few big writers leave, a disproportionate share of paid subscriptions leaves with them.

What I'd Build

Getting to what’s under the product scope, I would work on resolving the identity crisis first.

Add long-form articles to the home feed that surface content based on a reader’s search history and interests, to drive paid subscriptions towards the north star.

This keeps Notes alive for discovery and engagement, but ensures long-form content gets equal, if not more, prominence on the home feed for readers who are most likely to convert to paid subscribers.

What I Would Not Build

• Do not make Substack short-form first. Notes should remain a discovery tool, not the identity of the platform.

• Do not compete with Beehiiv or Ghost by becoming a CMS. Substack’s strength is the marketplace model, readers and writers finding each other. That’s defensible. Becoming a brand-building tool is not.

• Do not over-engineer user segmentation early. The marketplace model works precisely because it serves all writer types on one platform. Fragmenting the experience too early risks diluting the network effect.

This was my attempt on product teardown. Follow along if you want to join me on my job hunting journey!

Thanks for reading, more soon :)

Cheers,
Apoorva 👍🏻

Every single company has AI in its name, or its pitch, or plastered somewhere on its homepage. AI-powered legal research. AI-driven accounting. Logistics, but AI. Trading, but AI. Agriculture, but make it AI. I’ve seen “AI” in front of industries I didn’t even know still existed as standalone businesses.

My first reaction was a very tired, very Gen Z sigh. Sure. AI everything. Of course.

But then I stopped and actually thought about it. And I went from eye-rolling to genuinely curious. What’s even more interesting than the pattern itself is why every sector is rushing toward it right now.

Let’s do a quick tour. Because “AI is everywhere” is a claim that deserves some receipts.

I could go on. Real estate, agriculture, retail, education, and construction. The pattern is consistent.

But here’s the more interesting question: WHY NOW?

Legal has existed for centuries. Accounting has existed for centuries. Why is every industry suddenly waking up to AI in the same five-year window?

“Commerce directs science.”

I keep coming back to this line. It’s not a new idea, but it feels very fresh right now. Science doesn’t just advance in a vacuum because researchers are curious. It advances when there’s money and urgency behind it, when industries need it, when the pressure to compete is high enough.

The models got good enough. The computer got cheap enough. And suddenly every sector saw the same opportunity at the same time: what if we could automate the expensive, slow, error-prone parts of our work? They’re not tagging AI for the aesthetic. They’re tagging it because their investors, their competitors, and their customers all started asking about it simultaneously.

Now, is everyone doing it well?

Absolutely not.

There’s a version of “AI company” that means: we put a ChatGPT wrapper on our old SaaS and rewrote our homepage. There’s another version that means: we’ve actually rethought the workflow from first principles because the underlying technology genuinely changes what’s possible.

Those are very different things. And from the outside, from a job listing, from a LinkedIn post — they all look identical. Both will say “AI-powered.” Both will use the same buzzwords. The difference only becomes clear when you dig into the actual product.

This is actually one of the more interesting parts of job hunting right now. You have to read between the lines. Is the AI core to the product or cosmetic? Are they solving a real workflow problem or just repositioning? Has anything actually changed about how their customers work, or are they just selling the narrative?

Everyone wants to be relevant

None of this is new, by the way. We’ve watched this happen with “mobile-first” in 2011, “cloud-native” in 2015, and “blockchain” in 2018. Every wave brings genuine innovation and a lot of noise. The signal-to-noise ratio is always terrible at the beginning.

What’s different about AI is the breadth. Mobile and cloud changed how software was delivered. AI is changing what software can do. That’s a wider surface area, which is why every sector, not just tech, feels the tremors.

And so everyone wants to be adjacent to it. No one wants to be the company that said “AI isn’t relevant to us” and got disrupted two years later. That fear is rational. The herd movement makes sense, even if individual execution varies wildly.

The companies that actually stand out are the ones solving real problems with it — not just wearing AI as a badge. But right now, in this moment, everyone is wearing the badge. And watching that happen, sector by sector, is oddly fascinating.

Commerce directed the science. And now the science is directing commerce right back.

Still job hunting. Still scrolling. But at least now I’m scrolling with questions instead of just fatigue.

Share

Thanks for reading, more soon :)

Cheers,
Apoorva 💬

The simple answer? It’s chaotic. Ambiguous. Unstructured.

And not always comfortable.

The reality

Most days look like this:

• Too much work

• Multiple roles at once

• No clear structure

• Constant ambiguity

• Prioritisation becoming hard

• A general lack of stability

You’re often figuring things out as you go. Sometimes you’re unsure if you’re solving the right problem. Sometimes everything feels urgent.

That’s the reality.

Subscribe now

What chaos actually brings

That said, chaos is stability work in progress. It means motion. It means problems are real and visible.

And most importantly, everyone’s figuring things out here.

There’s no one playbook. No one has all the answers.
And that pushes you to try, learn, and step up.

With that comes:

• Exponential learning curve

• Space to experiment

• Exposure to many kinds of problems

• Passionate people who care deeply about the work

• Opportunities to build from almost scratch

You think, learn, fix, break, and rebuild.

Ownership and accountability

Ownership isn’t optional here.

If something works, it’s clear.
If something fails, that’s clear too.

You’re accountable.
And over time, that builds confidence.

That’s one of the reasons I wanted to work in a startup.

To learn by doing.
To build.
To solve real problems.

Share

I’ve completed a year working in a startup a few months ago. It hasn’t been smooth or easy. But it has been chaotically nice so far.

I know that as I grow, my priorities might change. I might look for bigger companies, more structure, or more stability.

And that’s okay.

Thanks for reading. More soon :)

Cheers,
Apoorva ✨

For us, that moment came when our weekly payment cycle began to look like a mini war room.

• 400+ daily installations

• Dozens of vendors

• Hundreds of invoices

• And a finance team stitching everything together manually

You could feel the process breaking before it actually broke.

🚩 When Manual Processes Hit Their Limit

Our finance team was spending hours every day on tasks that scaled linearly with growth:

• Chasing vendor invoices

• Verifying every WCR manually

• Processing hundreds of payouts

• Manually entering everything into Tally

• Sending UTR updates one vendor at a time

• Handling 30–40 queries daily asking, “Payment ho gaya kya?”

And the cracks were loud:

• Duplicate entries in Tally

• WCR mismatches

• GST/TDS manual errors

• Delayed payments affecting vendors

• A team constantly catching up, never getting ahead

Everyone was working hard.
But the system was working against them.

💡 The Turning Point: The Data Already Existed

The breakthrough wasn’t a fancy idea.
It was a simple observation:

Vendors were already using our platform every day to submit WCRs.
The data was real-time and reliable.

Instead of creating a new tool, we layered automation on top of the existing platform.

No new workflows.
No new habits.
No new onboarding.

Just smarter pipes.

⚙️ The Automation Layer We Built

1. Automated Invoice Engine

Every approved WCR flowed into a rule engine that calculated:

• Commercial rate

• GST

• TDS

• Net payable

No spreadsheets. No formulas.
A fully automated invoice in seconds.

2. OTP-Based Vendor Confirmation

To stay compliant:

System generates invoice → Vendor gets OTP → One-tap confirmation.

Legal. Fast. Error-free.

3. Finance Dashboard

A single, clean interface showing:

• Pending payables

• Batch-ready payments

• Exceptions

• Complete history

Finance finally had visibility, not clutter.

4. Vendor Payment Portal

Vendors could now see:

• Real-time receivables

• Invoice status

• Payment progress

• UTR details

• Their entire payment history

Queries dropped overnight.

5. Accounting Tool Integration

Automatic entries, tagging, and reconciliation.
Zero double entries.
Almost zero manual intervention.

📊 What Changed: The Numbers Tell the Story

• 95% reduction in invoice collection effort

• 75% faster payment processing

• 75% less manual accounting work

• 95% increase in vendor visibility on their payment queries

• Finance workload dropped by 85%

And beyond the numbers:

• The team finally had weekends back

• Vendors trusted the process

• Finance moved from firefighting → strategic work

• The business got a scalable financial backbone

✨ Why This Worked

• We built on top of an existing workflow

• We automated without breaking compliance

• We solved for vendors, not just internal teams

• Intelligent exception handling replaced manual chaos

• Change management was simple because the UX didn’t force new behavior

Sometimes the smartest solution is the one that feels obvious in hindsight.

🏁 Final Thought: Automation Should Feel Like Relief

What we built wasn’t revolutionary.
It was thoughtful.

It turned a stressed team into a strategic one.
It gave vendors visibility they never had.
And it created a financial engine that can scale long before headcount has to.

Thanks for reading. More soon :)

Cheers,
Apoorva 👩🏻‍💻

That’s when the cracks began to show.

What seemed like a neat solution for one team quickly turned into a series of roadblocks for another. We ended up spending more time reworking the product so that it could fit finance’s processes, and then procurement’s, and then operations’. That was my first real lesson: you can’t build internal tools in silos. If you don’t consider every department from the start, the cost of rework will eventually catch up with you.

Over time, every request I handled, every feature we debated, taught me something new about how to think about internal tools. Some of those lessons still guide the way I approach product building today.

I realized that every request comes from urgency. No one raises a ticket because they’re curious. It’s always because something is blocking their workflow, and the tool is supposed to unlock it.

I learned that solving one problem almost always affects another department’s workflow. A change for operations could quietly disrupt finance; an update for procurement could affect compliance. You’re never really solving for one team. You’re solving for the whole system, whether you plan to or not.

Along the way, I discovered that KPIs are sacred.

• Finance runs on accounting accuracy

• Operations depend on TAT compliance

• Procurement can’t function without visibility into closing stock

• Customer support lives and dies by plugging leakages

If your tool compromises even one of these, it doesn’t matter what else it delivers; the trust is broken.

And with trust comes another non-negotiable: security. Access, logs, permissions, these aren’t backend details; they’re the backbone of adoption. People need to know they’re only seeing what they should, and that their data is safe. Over time, I also found that it wasn’t enough to design permissions at a “module” level; they had to be action-based. Who can approve, who can edit, who can just view; those nuances make a tool safer, but also more flexible.

Then there’s data. If there’s one thing I’ve learned, it’s that data is currency. Every piece of information flowing in or out of a system matters. Storing it systematically, making it retrievable, ensuring nothing slips through the cracks, this is what future-proofs decision-making. Without it, even the most polished tool is hollow.

But the most important lesson of all has been this: centralization matters.

When you centralize systems, two things happen. First, integration becomes simpler. Every department can plug into the same core framework rather than running parallel systems that struggle to talk to each other. Second, it creates scalability. If tomorrow we ever decide to package and sell our internal tool as a SaaS product, we won’t be starting from scratch. The architecture will already be API-friendly, integratable, and hostable on any client’s server.

That perspective shifted the way I think about building. Instead of patching together quick fixes, I began to look at tools as living systems, ones that need to protect KPIs, safeguard data, respect permissions, and above all, connect and grow.

Because in the end, building internal tools isn’t just about solving today’s problems. It’s about creating systems that will stand tomorrow’s tests.

Thanks for reading. More soon :)

Cheers,
Apoorva 🤸🏻‍♀️

When you’re building something that your team has to use, you don’t have the luxury of adoption rates or user growth as success metrics. The tool just… needs to work. And work well.

I’ve been working on a procurement module that helps teams raise purchase orders (POs), track stock movement, and close stock accurately. It’s not flashy, but it’s super important. And when it comes to measuring whether it’s doing its job, the answer isn’t straightforward.

The Catch with Internal Tools

When the company mandates a tool, people will use it even if they don’t love it. That makes it tricky to measure success the way you would with an external app.

What do I look at instead? Three simple things:

• Is it faster?

• Is it more reliable?

• Is it making life easier?

Success Matrix for the Procurement Tool

Here are some of the things I look at to check if the tool is actually doing its job (though I’m sure this list will keep evolving, and I’ll probably come back to it later and add more or rethink a few):

1. Is creating a PO quicker than before?

2. Are there fewer mistakes while making POs?

3. Are teams spending less time doing repetitive, manual stuff?

4. Is the PO info more complete and accurate now?

5. Are we reducing maverick spend (people buying things off process)?

6. Is our inventory data actually matching what’s in stock?

7. Is the whole process from raising a PO to receiving goods faster now?

8. Can people track where things are more easily (like stock movement or what’s been closed)?

Adding Human Lens

Numbers are great, but they don’t tell the whole story. So I also rely on:

• Quarterly feedback to see how people feel about using the tool

• 1:1 chats and feedback forms to hear what’s working and what’s not

These layers together give a much more holistic view of how well an internal tool is performing & more importantly, where it needs to evolve.

Wrapping Up

Internal tools are tricky. They’re often invisible when they’re working well, & very visible when they aren’t. It’s about invisible wins: reduced friction, saved time, & better data. And sometimes, success looks like no one talking about the tool at all because everything just works.

Because at the end of the day, the best internal tools don’t make noise, they just make things easier.

Thanks for reading. More soon :)

That said, the list here isn’t just limited to internal tools. It applies to any product that’s gearing up to go live.

1. Testing Basics

Before anything goes live, functional testing is a must. Not just to tick a box but to make sure the tool is actually usable and doesn’t break mid-way. This includes checking all the flows, inputs, buttons, and conditions.

UAT with the internal teams helps too. Since access to end users is easy, getting quick feedback on the actual usability becomes more doable. They spot things that testers might miss.

Data testing is just important. Especially with modules that involve legacy information like procurement history, billing, vendor lists, etc it’s important to validate if the old data has been pulled correctly and shown in the new system.

2. Roles & Permissions

This is a crucial step. It’s not just about security; it’s about clarity and smooth handovers.

Different roles (maker, checker, approver) need different access. A procurement exec shouldn’t see financial approvals unless needed. The tool should reflect that. It’s easy to miss things here if every path isn’t walked through carefully. Even small things like whether someone can edit a record or just view it can cause problems later.

3. SOPs That Actually Help

SOPs sound boring, but they’re needed. Especially when different teams are going to use the tool. The idea is to keep it simple & goal oriented -

• Who does what

• What’s visible to whom

• Where to click

• What’s editable

• What’s not editable

• Any specific constraints they should be aware of

SOPs should act as a reference guide. Short, screen-level, and role-wise. Ideally, it should be usable even without a live demo.

4. Demo Before Go-Live

A proper walk-through helps everyone understand what’s coming. It also acts as one last round of sanity check. Sometimes, just talking through the product out loud brings out hidden issues. Even questions from others can highlight gaps that were overlooked.

This turned into a mini feedback loop in itself. Some things were minor UI fixes; others were functional gaps might have missed. Since this activity is pre-launch; there is still time to address what is necessary without too much disruption.

5. Backup & Rollback

Rollbacks are the insurance policy you hope to never use.

But if something goes wrong post-rollout whether it’s a bug, mismatch in flows, or just unexpected user confusion; Just making sure there’s a way to go back if something breaks after launch and that all necessary data is backed up. This gives some breathing room.

6. Managing Old Transactions

With internal tools, especially finance-related ones, there’s always the question: What happens to historical data? One way that worked here was creating a read-only view called “Old Transactions.” Keeps things clean without blocking people from referring to historical data.

7. Final Check with Stakeholders

Before going live, it helps to run a final alignment check with key stakeholders covering flows, access, data quality, and SOP readiness. This isn’t just a formal nod. It is about alignment. Making sure everyone is on the same page, felt heard, and knew what to expect once the tool goes live.

8. Gathering Feedback Post Launch

No rollout is perfect. Setting up a simple feedback mechanism like a shared sheet or a form creates space for early feedback. Collecting -

• Suggestions

• Bugs

• Ideas for version 2

It gives a roadmap for what comes next and makes users feel part of the process.

That’s pretty much the current checklist. Might evolve after the rollout, but this feels like a decent start.

Rollouts aren’t just about pushing features out. They’re about building trust in the tool and in the way things are done. It’s okay if it’s not all perfect. What matters more is being real about where things stand, staying open to feedback, & making it better step by step.

This one is just the beginning. Hopefully, the first of many.

Thanks for reading this far. More soon :)