Building thoughtful product ideas from user problems, research, and data.
I'm a PM who obsesses over the "why" before touching the "what." Based in Hyderabad, I've spent the last couple of years building products that don't just work but actually feel right to use.
Scheduled Order Feature
Problem: Users face high cognitive load when managing meal schedules. Goal: Enable 15%+ adoption within 90 days.
"I just want to know my lunch is coming without checking 10 times."
Case Study · Food Delivery
swiggy
Scheduled Order Feature
What if "I'll order later" could actually mean something? I explored how scheduling meals in advance could reduce Swiggy's peak-hour chaos while giving users back their mental bandwidth.
"Three out of five users I interviewed said they place their lunch order during their 10 AM standup. Not because that's when they're hungry. Because that's when they remember."
Research observation, User Interview Round 1
The Real Problem
It Was Never About Hunger
The surface problem was clear: delivery times spiked between 12:30 and 1:30 PM. But when I dug into user sessions and ran 12 interviews, the real problem emerged. Users weren't ordering at noon because they were hungry at noon. They were ordering at noon because they were afraid of forgetting and then scrambling.
That anxiety shaped their behavior. And that anxiety was completely solvable if we let them schedule a meal the night before, or first thing in the morning, with confidence that it would actually show up hot.
User Pain Point
"I feel bad if my team has to wait for me, so I order early even if I'm not hungry yet. The window to order at the right time just feels really small."
The mental model: users plan meals, not just cravings
How I Approached the Solution
Discovery
12 user interviews, session heatmaps, and competitor analysis to understand scheduling behavior patterns.
Mapping
Service blueprint tracing kitchen prep, fleet dispatch, and user notification touchpoints for scheduled slots.
Prototyping
3 rounds of Figma wireframes testing slot selection UI, cart lock behavior, and pre-order confirmations.
Validation
Usability testing with 8 participants, A/B tested notification timing, and measured slot adoption rate.
The fleet side: pre-scheduling unlocks route optimization and kitchen prep windows
The user side: slot selection, cart confirmation, and smart reminders
The Hardest Product Decisions
What Happens When the Restaurant Closes?
We spent two sprint planning sessions just on failure states. If a restaurant shuts its kitchen before a scheduled slot, the product cannot just show an error. We built a cascade: first a replacement suggestion from the same cuisine, then a full refund to wallet within 30 seconds. The PRD had 14 edge cases mapped before we wrote a single line of code.
Restricting Slots Without Feeling Restrictive
The hardest UX problem was explaining why certain time slots were greyed out. Kitchen capacity, delivery zone density, and fleet availability all factor in. We ran 3 copy tests before landing on "Filling up fast," which felt honest and urgent without being annoying. Small word choice. Big behavioral impact.
What I Learned
Convenience is not a feature. It is a trust contract.
The scheduled order feature worked not because it was technically clever, but because it made a promise users could rely on. Every edge case we covered, every failure state we handled gracefully, every notification we timed right: that was product thinking doing its job. The feature reduced Swiggy's peak-hour load. More importantly, it gave people one less thing to worry about at 10 AM.
Case Study · EdTech
SKILLBRIDGESkillBridge
Career switchers don't lack talent. They lack proof. I built and shipped a cross-functional workflow system that helped aspiring PMs generate real portfolio artifacts, not just course certificates.
"Every job description asks for 3 years of PM experience. Every career switcher asks: how do I get experience if no one will hire me without it? That loop is exactly what I set out to break."
Why This Problem Matters
The Catch-22 of Career Switching
I interviewed 20 people trying to break into product roles. Most had completed PM courses, built case studies, and read every Medium article on the subject. But they kept hearing: "You don't have real product experience."
The insight was uncomfortable but clear: credentials are table stakes. What actually breaks through is artifact-level proof. A real PRD someone shipped. A dashboard someone built. A decision someone justified with data.
Core Hypothesis
"If we match career switchers with structured, real-scope projects and run them like actual sprints, the output becomes indistinguishable from professional work."
Real sprints, real artifacts, real accountability
What I Built and How I Ran It
Definition of Ready: every ticket needed specs, edge cases, and a Loom before devs could touch it
Weekly retros kept the team honest: what was unclear, what was blocked, what could be done faster
Intake Sprint
Each participant mapped their skills, goals, and the kind of PM work they wanted to do before getting matched to a project.
Sprint Setup
Tickets written with full acceptance criteria. No vague tasks. Devs and PMs aligned before the sprint started, not during it.
Artifact Creation
PRDs, dashboards, user flows, and case studies generated through actual sprint work, not retrospective documentation.
Portfolio Review
Final artifacts reviewed against industry benchmarks. Portfolio ready for job applications within 6 weeks.
The Blocker I Did Not Expect
In Week 2, our AI recommendation engine had a latency issue slowing ticket SB-422 to a crawl. Instead of letting the sprint stall, I pivoted the team to front-end polish and user testing while the backend was resolved. Real-time triage is a PM skill. You build it by doing it.
When Clarity Becomes Culture
The most surprising outcome: engineers started writing better tickets themselves by Week 4. When the standard for what "ready" means is high, people rise to it. The Definition of Ready became the team's shared language. That's when you know the product mindset has actually landed.
What I Learned
"Operations is not about the tools. It is about the psychological safety that clarity creates."
The biggest unlock was not a feature or a framework. It was giving people a clear understanding of what "done" means before they started. When everyone knows the rules, execution becomes dramatically faster. And when execution is fast, confidence builds. That confidence is what career switchers need most.
Case Study · AI Operations
AI OPSAI Incident Response SOP
LLMs fail in ways that are quiet, subtle, and deeply weird. I built a structured playbook so teams could catch those failures before users did, and recover fast when they didn't.
"A traditional software bug is like a broken pipe. You can see the leak. An LLM hallucination is like water slowly seeping through the wall. You only notice it when the ceiling caves in."
The Problem with AI Failures
When "Mostly Right" Is Dangerous
Traditional incident response assumes binary failures: the system is up or it is down. AI product failures are messier. A model might be confidently wrong. It might start drifting on specific user segments. It might work perfectly for 98% of prompts and catastrophically for the other 2%.
Most teams I spoke to were reacting to AI incidents in panic mode: Slack DMs, manual checks, unclear ownership. The goal of this SOP was to give them the same calm, structured response that a senior engineer brings to a P1 infrastructure outage.
Core Observation
"Every AI incident we examined had the same root cause: no one owned the detection. Everyone assumed someone else was watching the model."
The detection gap: most teams caught failures through user complaints, not monitoring
Severity Matrix and Ownership
S1 incidents: immediate War Room, ML Infrastructure lead takes ownership within 5 minutes
S3 incidents: sprint backlog, Product Owner prioritization, post-mortem within 48 hours
Critical
Model producing harmful or wildly incorrect output at scale. Immediate war room. Full rollback if needed.
High
Significant accuracy degradation detected. Engineering lead notified. Fix deployed within 4 hours.
Medium
Edge case failures or drift on specific segments. Sprint backlog. Monitored for recurrence.
Low
Cosmetic or minor output quality issues. Logged, reviewed at next sprint planning session.
The Post-Mortem as a Learning Loop
Every incident generated a post-mortem using our "Five Whys of ML" template. Not to assign blame, but to feed learnings back into the model's RLHF pipeline. Over 6 months, we saw a 60% reduction in recurring incident categories.
Automating Detection Before It Becomes Reaction
The most impactful change wasn't the SOP itself. It was building automated confidence-threshold alerts that triggered before users noticed anything wrong. When the model's average confidence score on a query cluster dropped below 0.72, the on-call engineer got pinged. That shifted the team from reactive to proactive.
What I Learned
AI ops is not about the model. It is about the feedback loop between detection and engineering.
The playbook reduced resolution time by 30% through one mechanism: clear ownership at each severity level. Nobody was waiting for someone else to act. The moment an incident was classified, the right person was already in motion. That's what good product operations looks like.
Case Study · AI Health
TRUTHLABEL AITruthLabel AI
What if your grocery list could actually understand your health goals? TruthLabel is my exploration of how AI can turn a confusing nutrition label into a clear, personalized answer: "Is this safe for me, right now?"
"I watched a user spend 4 minutes reading the back of a protein bar in a supermarket. She had PCOS. She didn't know if the maltodextrin was fine or a problem. She bought it anyway because she didn't have time to Google it in the aisle."
Why Labels Fail People
Data Without Context Is Noise
Nutrition labels are legally required to tell you what's in a product. But they're not required to tell you what that means for you specifically. A 22-year-old gym-goer and a 55-year-old with hypertension look at the same sodium number and need completely different answers.
The core insight behind TruthLabel: the information already exists. The gap is personalized interpretation. If we know your health profile, we can instantly tell you whether that product is a green, yellow, or red for your specific situation.
The Design Goal
"Don't make users smarter about nutrition. Make the product smart enough to understand what their body needs."
The user's real question is never "how much sodium" but rather "is this safe for me today"
How the Product Works
Step 1: Scan the barcode. Instant product identification and ingredient list pull.
Step 2: Match against your profile. Age, allergies, health goals, and active conditions.
Step 3: Your score. A 0 to 100 safety rating with ingredient-level callouts and alternatives.
Input Analysis
Ingredient list parsed, flagged against your profile, cross-referenced with allergen databases and condition-specific restrictions.
Framework Auditing
Real-time ethics check: we surface risk signals and flag where a doctor's input is needed. We do not give medical advice.
Label Generation
A clear 0 to 100 score, a plain-language explanation, and 2 to 3 alternatives if the product scores below 60.
What I Learned
Transparency is not about showing more information. It is about showing the right information at the right moment.
The biggest design challenge wasn't building the AI pipeline. It was deciding what not to show. Users don't want a nutrition lecture in a supermarket aisle. They want a confident answer in under 5 seconds. Every design decision we made was filtered through that constraint. Less complexity visible to the user, more intelligence working invisibly behind it.
Critical Thinking
Product Teardowns
I spend a lot of time inside products that are not mine, asking "why did they build it this way?" These are the ones that taught me the most.
DUOLINGO
The Psychology of Streaks and Sabotage
How Duo the Owl weaponizes loss aversion, social status, and variable reward schedules to keep 37M daily active users coming back.
UBER
The Choreography of Magic Dispatch
Why the moving car on your screen feels reassuring even when you're watching a smoothed animation. The psychology of visible progress.
The Invisible Onboarding
Linear doesn't teach you how to use it. It builds a product that works the way your brain already does. A teardown of frictionless onboarding.
Teardown · Behavioral Design
DUOLINGOThe Psychology of Streaks and Sabotage
Duolingo is not a language app. It is a behavioral engine dressed in owl feathers. I spent 3 weeks inside it, mapping every psychological lever it pulls, and some of what I found made me genuinely uncomfortable.
"The streak is not a feature. It is a hostage. You don't keep your streak because you love learning French. You keep it because losing it feels like a failure of character."
The BJ Fogg Model in Action
B = MAP. Always.
Behavior happens when Motivation, Ability, and Prompt converge at the same moment. Duolingo's genius is that it controls all three simultaneously. Motivation is maintained through identity framing (you're a "language learner"). Ability is maximized by keeping lessons under 3 minutes. Prompt is timed to when you're most susceptible.
What looks like a fun app is actually a precision behavioral intervention running 24/7.
The action line: Duolingo ensures lessons sit well below the threshold of "this feels hard"
The streak counter is visible on every screen. This is not a coincidence. It is a deliberate anxiety trigger.
Weekly leagues: a competitive layer that converts a solo activity into a social status game.
The Three Manipulation Loops
Variable Reward
Random chest loot, surprise XP bonuses, and unpredictable encouragements. The same mechanism that makes slot machines addictive, applied to vocabulary drills.
The Endowment Trap
Streak freezes make you overvalue what you already have. The moment you "own" a 47-day streak, you'll do almost anything not to lose it. That's sunk cost as a retention engine.
Guilt by Design
"I guess these reminders aren't working." That notification is designed to make you feel you have let a relationship down. The owl isn't sad. The copy team just knows you respond to social repair impulses.
The Ethics Question I Keep Returning To
Duolingo uses techniques that, in a different context, we'd call manipulative. But the outcome is real learning. Millions of people speak more of a second language because of these mechanics. Does the ethical weight of the method change because the goal is positive? I don't have a clean answer. But I think PMs building habit-forming products should have to sit with this question.
What This Taught Me About My Own Products
After this teardown, I started auditing my own product decisions through a new lens: "Is this habit formation or manipulation?" The difference is consent and honesty. Duolingo is mostly transparent about what it's doing, which is why users feel gamified rather than exploited. That line matters enormously in product design.
Teardown Verdict
Users will tolerate dark patterns if the underlying promise is genuinely delivered.
Duolingo gets away with aggressive behavioral mechanics because the product actually works. The lesson for builders: manipulation is not a substitute for value. It is an amplifier of it. Make sure what you're amplifying is worth amplifying.
Teardown · Logistics UX
UBERThe Choreography of 'Magic' Dispatch
You tap a button and a car appears. But between that tap and that car, Uber is running one of the most psychologically sophisticated wait-management experiences in consumer tech. This is a teardown of how they make 4 minutes feel like 90 seconds.
"The car on your screen is not always real-time. Uber smooths the animation deliberately. A car that moves erratically is anxiety-inducing. A car that moves smoothly is reassuring. Same data. Very different emotional experience."
The Wait-Time Illusion
Active Watching Beats Passive Waiting
Before Uber, waiting for a cab was purely passive. You stood on a kerb with no information, no sense of progress, and no idea if a cab was even coming. That uncertainty was the pain. Not the wait itself.
Uber's breakthrough wasn't the technology. It was the insight that if you give people something to watch, the same duration feels shorter. The map is not information. It is therapy.
Passive Waiting
No feedback, no progress. 4 minutes feels like 12.
Active Observation
Moving car, ETA ticking. 4 minutes feels like 2.
The map converts idle wait into active watching. Same 4 minutes. Completely different psychology.
Surge pricing is not greed. It is a demand signal that draws drivers to where you need them, explained wrong by Uber for years.
Showing the driver's name and photo immediately shifts you from "waiting for a service" to "waiting for a person." That's humanization as a trust mechanism.
The Three Mechanisms of Post-Request Comfort
Haptic Comfort
The subtle vibration when your ride is confirmed is not just a notification. It is a physical handshake. The device touching your body creates a sense of transaction completion that a visual alone cannot replicate.
Humanization at Speed
You see Marcus's name, photo, and 4.92 rating within 3 seconds of matching. That is not coincidental. The faster Uber makes the driver feel human, the shorter the perceived wait becomes. You're not waiting for a car. You're expecting a person.
The Breadcrumb ETA
Research shows users tolerate waits better when they have a concrete endpoint. Even a slightly inaccurate ETA reduces dropout more than an accurate one with no visual. The ETA is not just information. It is a promise with a countdown.
The Batch Matching Paradox
Delaying Your Request to Serve You Better
Uber holds your request for up to 500ms before dispatching. In that half-second, it optimizes across hundreds of simultaneous requests. Users never know. They just notice their rides arrive faster.
Fleet Efficiency
Up to 15% fewer empty miles in dense urban zones through batch optimization.
Surge Intelligence
Price spikes draw supply to demand. The UI frames this as transparency, not penalty.
Teardown Verdict
The best logistics products are invisible. What users see instead is confidence.
Uber's real product is not transport. It is certainty. Every design decision, from the smoothed car animation to the 3-second driver reveal to the ETA countdown, is engineered to reduce uncertainty. The logistics happen behind the curtain. What the user experiences is a feeling of being in control of their own time.
Teardown · Product Tooling
The Invisible Onboarding: Deconstructing Linear's Frictionless Entry
Most tools teach you how to use them. Linear builds a tool that works the way you already think. The onboarding isn't a tour. It's a disappearing act, and that's the whole point.
"The first time I used Linear, I pressed 'C' and an issue was created. I don't remember reading a tooltip or clicking a 'Get Started' button. I just did the thing. That's the best onboarding I've ever experienced because I didn't notice it happening."
The Empty State Paradox
Every traditional project management tool starts with the same thing: a blank screen, a welcome modal, and a 7-step tour that nobody finishes. Jira, Asana, Notion: they all assume you need to be taught. Linear's thesis is the opposite. If the interface works the way a developer already thinks, teaching is unnecessary.
"Linear doesn't tell you what to do. It creates an environment where the fastest way to work is the right way to work."
Command Palette as Philosophy
Cmd+K Is Not a Feature. It Is a Worldview.
Making every action searchable through a single keystroke says: "We trust you to know what you want. You don't need to navigate our information architecture." That's a form of respect baked into the UI.
Jira Flow
Sidebar click, Project select, Create button, Form fill. 6 steps.
Linear Flow
Press C. Type. Done. 1 step.
The interface anticipates intent. Navigation becomes a side effect of working, not a prerequisite to it.
The Three Pillars of Invisible Onboarding
Default to Action
New users can create an issue before they understand the sidebar. The product rewards doing before exploring. Engineers learn by building, not by reading.
Speed as Feedback
Linear's sub-100ms response time is a product decision, not just an engineering achievement. When the tool responds at the speed of thought, every action feels like confirmation. That loop is the real onboarding.
Progressive Disclosure
Advanced features surface only when you're doing the thing they help with. Information arrives exactly when it's useful and never before. That's just-in-time learning at product level.
Teardown Verdict
The best onboarding is the one users don't notice having.
Linear proves that constraint is a feature. Deciding what the product does and does not support is an act of product leadership. The clarity of that leadership is what makes the onboarding invisible.
Explorations
Product Labs
Experiments I run when a problem bothers me enough that I need to build something to understand it.
Scheduled Order
How advance ordering can take cognitive load off lunchtime decisions and redistribute kitchen demand more evenly.
SkillBridge
Can sprint-based project work generate PM portfolio artifacts that are indistinguishable from professional output?
AI SOP
A structured playbook for teams shipping LLMs who want to catch model failures before users do.
TruthLabel
What if a nutrition label could understand your health context and give you a plain yes or no in 5 seconds?
From the Writing Desk
AI Product Strategy
Your Website Is Not for Humans Anymore
Product Strategy
The Real Reason Products Fail
Writing and Reflections
Things I've thought hard enough about to put into words.
Deekshitha Seeramdas on Substack
I write about product strategy, user behavior, and the decisions behind products we take for granted. Subscribe if you want the thinking, not just the headlines.
Read on Substack open_in_new
Your Website Is Not for Humans Anymore
The shift to Generative UI and Machine Experience design is quietly killing the static pixel.
Atlassian Just Released Its First State of Product Report
Diving into the latest frameworks and trends from the industry leaders at Atlassian.
Building Products that Don't Feel like Work
Exploring the deep psychological hooks of modern engagement and habit loops.
Hi, I'm Deekshitha. I think about products the way some people think about puzzles: I cannot rest until I understand how all the pieces fit.
I've been building at the intersection of user research, data, and business strategy, working across logistics, edtech, and AI to figure out what makes products actually land with people versus just technically existing.
My process is probably best described as stubborn curiosity. I interview users longer than is comfortable. I write PRDs with more edge cases than anyone asks for. I run retros even when the sprint went fine. I believe that the rigor of your thinking is visible in the quality of your product, and I want my work to reflect that belief.
I'm currently looking for Associate PM, Product Analyst, AI Product, and Product Operations roles, in India and remotely. If you're building something you genuinely believe should exist in the world, I'd love to hear about it.
Get In Touch
Let's talk product.
I'm genuinely interested in what you're building. Whether it's a role, a collaboration, or just a conversation about why your favorite app makes you feel the way it does, reach out.
Say Hello