Why Pm Matters For Developers
Product management is not just a PM job. Every developer who understands prioritization, user thinking, and product decisions grows faster and ships better software.
Here is a question I was not prepared for when I started engineering: should I fix the live bug or ship the new feature we promised this sprint?
Both feel urgent. Both have real consequences. I had no framework for choosing. I just guessed, and sometimes guessed wrong.
That question is a product management question. And every developer faces it, whether they realise it or not.
What Product Management Actually Is
The clearest definition I have found: product management is the art of effective prioritization.
At any given moment, there are hundreds of things wrong with a product. Every app on the Play Store has one-star reviews. Meta and Google, with infinite engineering resources, still have bugs, still have outages, still have features users hate.
The problem is never the absence of things to fix. The problem is always: which one do you fix first?
Product management is the discipline that answers that question in a principled way. It defines which problem is most critical to solve for users and the business right now, and then defines how to solve it in the minimum time possible.
Both parts matter. Identifying the right problem and then spending two years solving it is not product management. It is slow failure.
A Real Prioritization Problem: DoubtNut
DoubtNut was an EdTech app with a simple promise: photograph a question from your textbook, get an AI-generated video answer in ten seconds.
At peak, 4 million students used it every day -- largely students in Tier 3 and Tier 4 cities across India who lacked access to good tutors or well-funded schools. Seventy percent of those users were on 2G or 3G networks with low-end Android devices.
At any given time, the product had three major live problems:
| Problem | Description |
|---|---|
| A: Upload Failure | Users could not upload their photo due to poor network. They never experienced the product at all. |
| B: Video Abandonment | Users uploaded successfully but did not watch the AI-generated video solution. |
| C: No Return | Users asked, got a video, watched it, but never came back the next day. |
The team was spending Rs. 1 lakh per day on marketing to get 10,000 downloads. Of those, 6,000 users (60%) could not upload their image. That is Rs. 60,000 wasted every single day on users who could never experience the product.
ExpandThe DoubtNut user journey showing Problem A blocking B and C
Which Problem Do You Solve First?
The instinct is often to say "all three" or "it depends." But that is not a decision. Resources are finite. Time is finite. You can solve everything eventually, but your users need the app to work today.
The right answer is Problem A -- and the reasoning is structural.
Until a user can upload their image, they cannot experience the value of the product at all. They never see the video solution. They never get a reason to return. Problems B and C do not exist until A is solved -- because A is the prerequisite for the user experiencing anything.
Think of an e-commerce app where you can browse but cannot complete a purchase. You might have a perfect checkout UI, a brilliant recommendation engine, a superb email re-engagement flow.
None of it matters if the user cannot buy. The core action must work first.
In high-level system design, this is how you identify the critical path before optimizing anything around it.
There is also a secondary damage worth understanding. Users who try and fail do not disappear silently. They leave one-star reviews. They tell their friends the app is broken. Marketing spend compounds the problem instead of solving it.
The Solution Attempt and Why It Failed
The obvious approach: if users cannot send full images over a slow network, extract the text from the image on the device and send just the text instead. Far smaller payload. Works even at poor signal quality.
Google's Firebase ML Kit offered exactly this -- an on-device OCR (Optical Character Recognition) library, the kind of on-device prediction model that processes data without a network call. The team built a lazy-loaded implementation: users downloaded the app, and the OCR SDK loaded silently in the background.
The solution was technically elegant.
It failed completely in production.
The reason: the users most affected by upload failures were exactly the users with the lowest-end Android devices. Those devices could not process the on-device OCR without freezing. The user would take a photo, wait, see the app hang, and assume it had crashed. The app's rating dropped from 4.1 to 3.1 overnight. The team had to roll back entirely and send an emergency update.
The lesson is not that the technical approach was wrong. It is that the solution was designed without fully understanding the constraints of the target user's environment. When 60-70% of your users have mid-2010s Tier 3 Android hardware, "runs fine on the dev machine" is meaningless.
This is what product management teaches: before you define a solution, define the user.
What device are they on? What network? What are their expectations when something takes three seconds longer than usual?
A well-framed problem is half the solution. A solution designed without that framing will fail regardless of how clean the code is.
The next post picks up here: what kind of engineer internalizes this lesson, and what that actually looks like in terms of role, architecture decisions, and career growth.
The Essentials
- Product management is prioritization: Every product has infinite things to fix and finite time. The PM skill is choosing the one thing that creates the most impact for users and the business right now.
- Solve the prerequisite first: If Problem A blocks users from experiencing anything, fixing B and C is wasted work. Identify dependencies before choosing what to build.
- Design for your actual user, not your dev machine: The DoubtNut Firebase case failed because the solution assumed device capabilities the target users did not have. User context is a hard constraint, not an afterthought.
Further Reading and Watching
Keep reading