What I Had to Unlearn Before I Could Think Like a Product Manager
- Tushar
- Dec 2
- 7 min read
When I entered my first product role, I did not struggle with effort. I struggled with my own certainty.
For years, I had taken decisions as a business owner. I was used to spotting gaps, acting quickly, and trusting my judgement. That instinct had protected me in the world of business and e-commerce. But inside a product organisation, the same instinct quietly started hurting the quality of my decisions.
I was still sharp.
I was still hardworking.
But I was biased in a very dangerous way:
“Because I can see this as a problem, it must be a big one.”
“Because it never bothered me, it probably is not worth solving.”
“Because this approach worked last time, it should work again.”
I am writing this specific article to address the unlearning phase. Not tools. Not frameworks. Not “how to become a PM”. It is about how I had to get out of my own way before any serious product thinking could start.
Table of Contents
Side-Effect of your Biases
The “If I Don’t Feel It, It’s Not a Problem” Bias
The “If It Worked Before, It Will Work Again” Bias
The “If I See It, Everyone Sees It” Bias
Unlearning the Biases
The Most Dangerous Bias: “My Lens Is the Truth”
In my founder days, this bias did not feel like a bias. It felt like responsibility.
If I noticed a friction in my own buying experience, I took it seriously.
If a process irritated me, I assumed many people felt the same.
If a certain type of listing worked, I would repeat the pattern in new categories.
Most of the time, this did not kill the business. Sometimes, it even helped. But in product management, the stakes are different. You are no longer optimising only for your own conviction. You are optimising for a system that serves thousands of people who do not think like you at all.
There was one moment early in my PM journey that made this painfully clear. We were exploring a new workflow for a merchant segment. I was convinced that one specific friction point was the “big problem” we should solve. It was exactly the kind of thing that would have frustrated me as a business owner.
I pushed hard for it.
I argued clearly.
I sounded confident.
Then we went out and spoke to users. It showed up in maybe 10–15 percent of conversations. They acknowledged it. But they did not act on it. It was a mild irritation, not a tipping pain. The real problem they wanted fixed was something I had almost ignored:
A messy, unstructured journey that wasted their mental energy every day.
That day I realised:
“My personal experience is a useful input, but a very poor centre of gravity.”
If you are thinking of moving into product, this is the first unlearning:
Your lived experience is a starting hypothesis, not the truth.
Three Biases I Had to Face Very Honestly
Over the years, I noticed three recurring thinking patterns in myself. You may recognise some of them in your own context, whether you are in engineering, design, business, support, sales, or operations.
A. The “If I Don’t Feel It, It’s Not a Problem” Bias
As a founder, if something never troubled me, I assumed it was not very important. In a product role, this became dangerous. Users would complain about something that did not seem “logical” to me. Maybe they wanted extra communication, or they were uncomfortable with a step I took for granted.
Earlier, I would have brushed it aside mentally: “This is not a real blocker. They will adjust.”
But once we did enough user conversations, one thing became clear:
A problem is not defined by how you feel about it. It is defined by how much it changes user behaviour.
Actionable way to catch this bias:
For the next week, every time you hear a complaint that does not make sense to you, do two things:
Write it down exactly as the user said it. Do not translate it.
Ask: “If I solved this, what would the user start doing differently?”
If you cannot answer (2) clearly, you need more understanding - not a faster judgement.
B. The “If It Worked Before, It Will Work Again” Bias
At Sangeeta Enterprises, a few strategies worked brilliantly:
Certain types of listing structures
Certain way of using reviews
Certain advertising tactics
Certain categories and price points
It is very natural for the mind to say: “This approach gave me growth. Let me apply the same formula everywhere.”
In product, this shows up as:
“We did this on the previous product; let us apply it here.”
“This worked in one segment; it must work across all segments.”
The risk is subtle: You stop observing this context and start replaying your old success. I had to consciously switch from:
“How do I reuse what worked earlier?” to “What is different here that could make the old pattern fail?”
Actionable pattern-breaker you can try:
Before you apply a known playbook, write down answers to these two questions:
“What is genuinely similar between this situation and the last one?”
“What is crucially different?”
If the “different” list is longer and deeper than the “similar” list, your previous formula is a reference, not a plan.
3. The “If I See It, Everyone Sees It” Bias
This is the bias that survived the longest in me. For example, in e-commerce, I became very sensitive to product details:
Listing quality
Packaging
Delivery timelines
Micro-level operational issues
My eye was trained to notice these things. So when I later entered the product role and evaluated flows or features, my mind assumed: “If I can spot this friction in 10 seconds, everyone else will too.” But that is not how usage works. Users are not walking into your product with the same lens, training, and history as you.
In one internal review, I was strongly against a particular flow. I felt it was not “clean” enough. It violated my internal taste. We still shipped it, and then sat on the data. Users did not care about what bothered me. They got stuck somewhere else entirely.
Actionable way to interrupt this bias:
The next time you feel strongly about a product decision, ask yourself:
“How did I learn to care about this?”
“Would a first-time user with no context care about the same thing?”
If your reason is “because I have seen this 100 times”, you are likely over-indexing on your own exposure, not the user’s reality.
Unlearning as Subtraction, Not Improvement
For a while, I tried to “improve” as a Product Manager by adding:
More frameworks
More terminology
More methods
But the turning point came when I stopped adding and started subtracting. I began to treat every strong conviction as a hypothesis that needs to survive three simple checks:
Have I heard this from at least 5–10 users unprompted?
Have I seen this reflected in actual behaviour, not just in what they say?
What would change in their journey if this were magically solved tomorrow?
If I did not have good answers, my earlier self would have still pushed. My current self pauses. This shift - from “I am right” to “Let me test if I am right” — is what actually unlocked product thinking for me.
A Simple Bias Audit You Can Run in Your Current Role
You do not need a PM title to start this. For the next 7 days, pick three decisions you are part of. They can be:
A feature in engineering
A process in operations
A design change
A sales pitch
A support playbook; OR
An internal tool change
For each decision, write down:
What did I assume to be true without fresh data?
Which part of this assumption comes from my own past success or failure?
Did we hear directly from real users before finalising? How many?
What evidence would disprove my belief?
Do not share this with anyone. This is not for office politics. This is for your own calibration. If you repeat this for a week, patterns will show up:
Maybe you make decisions from one strong personal experience
Maybe you rely too much on one type of user voice
Maybe you trust internal stakeholders more than real users
Seeing this clearly is more valuable than any certification.
How This Applies to You, No Matter Your Background
You may not be a founder. You may be an engineer, a designer, a QA professional, a customer success manager, an analyst, or a business operator. Your label is different. The risk is the same:
You start believing that the way you experience the product is how the world experiences it.
None of these instincts are wrong. They become dangerous when they become invisible to you. Product management, at its core, is the discipline of making these invisible forces visible before you take a call.
What Unlearning Changed for Me in Practice
Once I started taking my own bias seriously, a few things changed in how I worked:
I spoke to more users before I wrote problem statements
I forced myself to write “What I might be wrong about” in PRDs
I asked engineers and designers to openly challenge my assumptions
I slowed down on decisions where my conviction was very high but my data was very thin
I stopped reusing old templates blindly, even if they had worked well before
My speed went down a little in the beginning. My accuracy went up a lot. And over time, the speed came back - but from a different place: Not from impulse, but from clarity.
When people talk about getting into product management, they often focus on what they need to learn. "Frameworks. Tools. Case studies. Interview preparation." They matter, but in my experience, the deeper shift is:
In what you are willing to unlearn about your own thinking.
If you can clearly see where your past success patterns might be blinding your present judgement, you are already thinking like a Product Manager - long before the title appears.
If this reflection made you more aware of your own biases - and you are currently exploring a move into product.
Comments