Himanshu — Product Work

01

The Problem

No one agreed on the numbers

The sales team pulled reports from one tool. The category managers worked off spreadsheets. The leadership team was asking questions that nobody could answer quickly — or consistently. There wasn’t a data problem exactly; there was a visibility problem. Everyone had access to some of the data, but nobody had a clear view of all of it together. Decisions were being made on gut feel, stale exports, or whoever had updated their spreadsheet most recently. The cost of that wasn’t obvious on any single day — but it showed up in missed opportunities, slow pivots, and hours spent reconciling numbers before every weekly review.

02

My Thinking Process

Starting with the questions, not the metrics

My first instinct wasn’t to map out a dashboard. It was to ask: what decisions are people actually trying to make? I spent time with the sales ops team and category leads — not to gather requirements in the traditional sense, but to understand where they felt blind. What were they looking for every Monday morning? What made them nervous going into a business review? The answers shaped everything. The problem wasn’t a lack of data; it was that no existing tool connected performance, catalog health, and sales trends in a way that matched how the business actually operated. I also had to balance what stakeholders said they wanted with what they actually needed — and resist the pull to build something comprehensive at the cost of something useful.

03

What I Built

A dashboard built around decisions, not data

The result was a sales and catalog dashboard that unified performance data across brands and categories into a single, role-appropriate view. Sales teams could track daily and weekly trends without running reports. Category managers could see catalog completeness alongside sales velocity — understanding not just what was selling, but what might be holding performance back. Leadership got a high-level snapshot that didn’t require a 30-minute prep call to understand. I worked closely with the data and engineering teams to make sure the underlying logic was consistent — one definition of “revenue”, one definition of “active SKU” — so that the trust issue upstream would eventually disappear downstream.

04

The Outcome

The weekly prep call got shorter. Then it disappeared.

The most telling signal wasn’t a metric — it was behavioral. Teams stopped maintaining their shadow spreadsheets. The pre-meeting scramble to align on numbers quietly faded. What had taken hours of manual reconciliation before a business review was now a two-minute glance at a shared screen. Beyond the efficiency gains, the dashboard surfaced patterns that had previously been invisible — catalog gaps correlating with sales dips, seasonal anomalies catching attention weeks earlier than before. Decisions got faster because confidence in the data went up.

01

The Problem

The ops team was always behind

In a fast-moving logistics environment, the gap between what’s happening and what the team knows about it can be costly. The ops team I worked with was skilled and experienced — but they were operating in a largely reactive mode. Exceptions surfaced late. Escalations came from customers before they came from internal systems. SLA breaches were discovered after the fact rather than flagged in advance. The information existed somewhere — in carrier feeds, warehouse systems, internal trackers — but it wasn’t connected in a way that gave anyone a working picture of what was actually in motion at any given time.

02

My Thinking Process

Finding the alert that arrives too late

I mapped the journey an exception took — from the moment something went wrong in the physical world to the moment a human knew about it and could act. That gap was longer than it should have been, and it varied wildly depending on the type of exception and which system it originated in. I also spoke with the ops team about which problems genuinely needed human attention versus which ones were eating their time without requiring judgment. The goal wasn’t just better visibility — it was better prioritization. A dashboard that shows everything equally isn’t useful in a high-volume ops environment. What the team needed was signal, not noise: the right exceptions, surfaced early enough to actually intervene.

03

What I Built

An ops view built around intervention windows

The product we built was an operational tracking and exception management tool that gave the logistics team a live view of shipments at risk. Rather than listing every order in a table, it surfaced prioritized exceptions — orders approaching SLA thresholds, delays at specific carrier or warehouse nodes, clusters of issues pointing to a systemic problem rather than a one-off. It was designed to fit into how the ops team already worked: actionable from the top of the page, not buried in filters. We also built lightweight escalation flows so that when something needed to be flagged, the path from identification to action was as short as possible.

04

The Outcome

The team started catching problems before customers did

The shift was gradual but noticeable. Customer-reported exceptions began to drop as the team started identifying and acting on issues earlier. SLA breach rates came down not because the logistics network improved overnight, but because the window for intervention expanded. Perhaps more meaningfully, the team’s working rhythm changed — from chasing fires to managing a queue. That shift had a secondary effect on morale and capacity: when people aren’t constantly reacting, they have more bandwidth to think about systemic improvements rather than just surviving the day.

01

The Problem

Netflix knows what you watch. It doesn’t know what you love.

There’s a meaningful difference between something you watched and something that genuinely moved you — a film you’d press into a friend’s hands, a show you’d rewatch without hesitation. Netflix’s current experience flattens that distinction. Your taste exists implicitly in the algorithm, but there’s no place to make it explicit, no space to say: these ten titles define me as a viewer. The social layer on Netflix has always felt underdeveloped — you can share what you’re watching, but not what you stand behind. That gap creates a real missed opportunity: for self-expression, for discovery through people you trust, and for Netflix to deepen engagement beyond the next autoplay.

02

My Thinking Process

The difference between sharing content and sharing taste

I started from a simple behavioural observation: people already do this informally. They make Letterboxd lists, tweet their top 10s at year-end, send voice notes raving about a series. The desire to curate and share taste is native — Netflix just hasn’t given it a home. The core design question wasn’t “how do we add a social feature?” It was: what format lets someone’s taste speak for itself without becoming noise? A ranked, curated, limited list — ten titles — forces intentionality. It’s not a watchlist dump; it’s a statement. Add a voting mechanic from connections and it becomes a dialogue. Add a direct “add to my collection” path and it closes the discovery loop in a way Netflix’s current recommendation engine can’t — because it’s trust-driven, not algorithm-driven.

03

The Feature

Your Top 10 — curated, social, yours

Each Netflix user gets a personal “My Top 10” space — a fully customisable shelf that lives on their profile. You choose up to ten titles from anything on the platform, rank them however you like, and optionally add a one-line note for each. The shelf is shareable via a link or directly within the Netflix social graph. Connections can vote on your selections — not to change the ranking, but to signal resonance. Every title card on someone else’s shelf carries an “Add to my collection” button, saving it directly to a personal watchlist. The result is a taste graph that’s human-curated rather than machine-inferred.

UI Mockup

04

Why It Works

Trust travels further than an algorithm

The feature solves something Netflix’s recommendation engine structurally can’t: it makes discovery social and intentional. When a friend puts something in their Top 10, it carries weight that “Because you watched X” never will. For Netflix, it deepens session engagement — browsing a connection’s Top 10 and voting on it is time spent on platform. It also creates new hooks for content teams: surfacing which titles appear most frequently across users’ Top 10s tells you something very different from raw viewership numbers. And for users, it finally gives taste a home — something to build, share, and return to.

01

The Problem

Listening is personal. Spotify treats it as passive.

Music is rarely just background sound. Songs attach themselves to moments — a road trip, a late night, a loss, a beginning. Every listener carries stories about specific songs that shaped them, but those stories exist nowhere on the platform that delivered the song in the first place. Spotify’s data tells artists how many streams they have. It doesn’t tell them why a song hit someone the way it did. And for listeners, that emotional relationship with a song has no outlet — no channel back to the artist, no space to say: this is what your work meant to me. That asymmetry — rich on consumption data, empty on emotional context — leaves something valuable on the table for both sides.

02

My Thinking Process

What does an artist actually want to know about their listeners?

I thought about this from both sides. For a listener, the impulse to share “what this song means to me” is real but currently homeless — it ends up on Twitter, in a WhatsApp forward, or just unexpressed. For an artist, streams and playlist adds are gratifying but thin. The design challenge was finding a format that’s intimate enough to feel personal but structured enough to be surfaceable. A short paragraph, attached to a specific song, submitted voluntarily — that’s the right unit. Not a comment section (too noisy), not a rating (too reductive). A story. And giving the artist the ability to amplify a story they connect with creates a feedback loop that doesn’t exist anywhere in music streaming today.

03

The Feature

A story for every song that earned one

On any song page, listeners see a “My Connection” prompt — an optional space to write a short personal story (capped at 250 characters) about what this song means to them. Stories are public by default, attached to the song, and visible to other listeners as a human layer beneath the lyrics and credits. Artists and their teams can browse stories submitted for their songs, and if one resonates, they can choose to amplify it — featuring it on their artist page, sharing it to their social channels, or responding directly. For listeners, it’s a chance to be heard. For artists, it’s a window into the human impact of their work that streaming numbers alone can never provide.

UI Mockup

04

Why It Works

It makes music personal — on both sides of the speaker

This feature works because it doesn’t try to replace what music already does — it creates a channel for what music already makes people feel. For listeners, the act of writing the story deepens the connection to the song. For artists, it replaces a black box of stream counts with actual human signal. And for Spotify, it builds something no other platform has: an emotional layer on top of the catalogue that makes every song richer the more it’s been loved. The artist amplification mechanic is the key accelerant — the possibility that an artist might see and share your story is a powerful, low-friction engagement driver that requires no algorithmic intervention.

01

The Problem

Your best statuses disappear in 24 hours

WhatsApp Status was designed to be ephemeral — and that’s largely a feature, not a flaw. But there are moments worth keeping. A photo from a trip you posted. A quote that captured exactly how you felt that week. A celebration that your closest people responded to. Right now, once 24 hours passes, those are gone. You can screenshot them locally, but that’s clunky, and you lose the context — who saw it, who reacted, who reached out because of it. There’s no in-app way to say: I want to hold on to this one. That gap is small, but for users who post thoughtfully, it’s genuinely felt.

02

My Thinking Process

Not a highlight reel — a personal archive

The instinct might be to build a “highlights” feature — publicly showcasing your best statuses, Instagram-story-style. But that misses the point. What users actually want is something quieter and more private: a personal record of the moments they chose to share, visible only to themselves. The value isn’t in broadcasting the archive; it’s in having it at all. “Ten people reacted to this” is less interesting than “my sister reacted to this” — and preserving that specificity is what makes the feature feel human rather than just functional.

03

The Feature

Save before it disappears — just for you

While a status is live, a simple “Save to Archive” option appears in the status controls — one tap, no friction. Saved statuses are stored in a private, end-to-end encrypted archive accessible only to the user, organised chronologically. Each archived status retains the viewer and reaction data it had at the time of saving — so you can see who saw it and who responded, preserved as a snapshot in time. The archive is never shared, never surfaced to contacts, and has no social function. It exists entirely for the person who made it.

UI Mockup

04

Why It Works

It respects what WhatsApp already is

The best thing about this feature is what it doesn’t try to do. It doesn’t add a social mechanic. It doesn’t create a new feed or a new reason to post. It doesn’t change how Status works for anyone who doesn’t use it. It simply gives users who care about their own history a way to keep it — privately, cleanly, with the context intact. That restraint is the product thinking. WhatsApp’s identity is built around intimacy and privacy; a feature that leans into those values rather than against them is one that fits naturally into the product rather than feeling bolted on.

01

The Problem

Active job seekers in India are portal-hopping — and burning out doing it

Mid-level job seekers toggle between 4-5 portals daily — Naukri, LinkedIn, IIMJobs, Shine, Indeed — applying fragmented search filters on each, missing relevant listings, and wasting 45-90 minutes a day on manual de-duplication. Filters reset on every visit. Duplicate listings appear with no way to identify them. Each platform has different UX and result quality. There is no single surface that unifies listings with personalised relevance scoring — and the result is cognitive overload, diminishing returns per session, and users spending more time searching than actually applying.

02

Why It Doesn’t Exist Yet

The structural reason — not just a market gap

If this problem is so obvious, why hasn’t someone built it? The answer is structural, not accidental. Every major job portal actively defends against scraping — especially AI-powered scraping — because exclusive job listings are their core USP. A posting “only on Naukri” or “only on IIMJobs” is a competitive moat, not an oversight. This creates a genuine technical and legal barrier that has kept the aggregation layer from existing in the Indian market. JobLens isn’t ignoring this constraint — it’s the central engineering challenge the POC needs to validate before any further investment is made.

03

Key Product Decisions

The thinking behind the scoped POC

Three decisions define what JobLens is — and isn’t. First, the match score deliberately avoids naive keyword overlap, using a weighted composite of skill match, role title similarity, experience bracket fit, and location — because “Python” matching a 10-year senior role for a 2-year candidate is a false positive, not a feature. Second, the 70% threshold is the product’s noise filter: below it, at least two major signals are misaligned, and showing those listings defeats the core value proposition. Third, in-app application tracking is explicitly out of scope — not because it wasn’t thought about, but because it’s a different product problem that would inflate scope without validating the core hypothesis.

04

Success Metrics

Optimising for time saved — not time spent

The north star is time saved per day on job discovery — targeting ≥40 minutes saved daily within the first week of use. Supporting metrics include match score accuracy (>75% of shown listings feel relevant), feed-to-apply rate (>30% of listings viewed result in a source redirect tap), and daily active use (≥5 of 7 days in the first two weeks). Critically, time spent in app and number of listings shown are explicitly anti-metrics — more time in the app means the product is failing, not succeeding. Faster discovery is the win, not deeper engagement.

05

What This Demonstrates

End-to-end PM thinking — before a single line of code

This PRD is itself the POC artefact. It shows problem definition grounded in specific user behaviour (not assumptions), a persona built on a real job-seeker archetype, prioritisation with explicit rationale for every deferral, match score logic that rejects the obvious naive approach, and anti-metrics that resist vanity optimisation. The decision not to build in-app application tracking is as important as what was built — scope discipline is a PM superpower, and this document demonstrates it explicitly.