Back

From Analyst to Staff PM, in Slow Motion

5 MINS

From Analyst to Staff PM, in Slow Motion

I started my career as a Product Analyst at Amazon. Today I'm a Staff Product Manager at Walmart. People sometimes ask what changed, and I think the honest answer is: I stopped being the person who proves things and started being the person who decides things — and that took longer than any framework will admit.

This is the version of that journey I wish someone had given me at year three.

Analyst muscles you don't lose

The analyst years gave me three muscles I still use every week:

Writing the question first. Most product debates are caused by an unwritten question. Analysts learn to write the question before the SQL. PMs should too.
Distrusting the chart. A clean chart almost always has a dirty pipeline behind it. The instinct to ask "what's in this denominator?" is a permanent advantage.
Closing loops. Analysts learn that a study isn't done until somebody changes a decision because of it. PMs forget this surprisingly often. These muscles are why "analyst → PM" works. They are also why the transition is harder than it looks: the muscle that makes you a good analyst — proving things carefully — can quietly slow you down as a PM.

The transition I didn't see coming

The hardest part of the move wasn't learning to write a PRD or run a backlog. It was learning that a PM's job is to make decisions with incomplete information, on a schedule someone else owns. Analysts get to say "let me check". PMs often don't.

Some specific things that took me too long to learn:

A 70%-confident decision shipped this week beats a 95%-confident decision shipped next quarter — almost always.
Stakeholders rarely want the right answer. They want a clear answer they can act on. Those are not the same thing.
"Data-driven" is sometimes used as cover for "afraid to commit". A real PM commits, and uses data to make the next commitment better.

What "Staff" actually changed

The jump from Senior PM to Staff PM was less about scope and more about who I was solving for. As a Senior PM, I was solving for my product. As a Staff PM, I'm increasingly solving for my org's ability to ship the *next* product.

In practice, that has meant:

Spending more time on the team's frameworks (experiment design, prioritisation rubric, pricing guardrails) than on individual launches.
Saying no, on the team's behalf, to leaders who outrank me — which is a skill I'm still learning.
Mentoring earlier-career PMs even when nobody asked. The compounding return on that is bigger than any single feature I have shipped.

A few things I wish I'd known sooner

Don't optimise for the next title. Optimise for the next problem you don't yet know how to solve.
The fastest way to grow as a PM is to work near someone who is openly bad at the same things you are bad at, and watch them fight it.
Career growth is mostly the slow accumulation of trust. Do not break trust to make a quarterly target. The "analyst to Staff PM" arc isn't a hack. It is just years of doing the boring work, in public, with receipts.
Background

Nabendu skipped presentations and built real AI products.

Nabendu Goswami was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.