Beyond data: why experience defines senior PMs

Somewhere along the line, many PMs pursuing a “Senior” career have lost sight of the most critical value proposition of being “Senior”: Experience.

Being a crafty Product professional yourself, I’m sure you’re itching to dig deeper into that loaded word, “experience”. What do I actually mean by “experience” in this context? 

Well, in short, experience means: “you’ve done this before”, “you’ve seen this before” - and hopefully, many times before.

Now I’ll bet your PM instincts are really starting to kick into gear, aren’t they? Fantastic. Keep pressing me. Why is “experience” such a critical element of being a “Senior” PM? Why does it matter that you’ve “done it” and “seen it” before? Many times before?

Great question. 

Because the more you’ve “done it” and “seen it” - assuming you’ve “done it” and “seen it” effectively - the fewer questions you’ll have to ask while you’re “doing it” and “seeing it” again.

A.k.a. You already know things that less experienced people don’t. 

🚨ALARM SOUNDS🚨

Uh-oh, call the PM Police; is he telling Product Managers to be anti-curiosity?

No, no, no I’m not. Grab your blood pressure medication, take a breath, and hear me out. 

I’m not saying Senior PMs - or any level of PM - shouldn’t be asking questions. What I am saying is that hopefully, if you’ve been doing this long enough, well enough, the number of circumstances under which you are reliant on someone else’s answers go down (e.g., user research), the odds of having a blocking question go down, and the odds of you being able to unleash yourself and your team into warp speed while making sound decisions along the way go way up.

What a Data Be Alive

Ultimately, over time we have culturally shifted how we communicate and calculate the worth of a Product Manager. Our industry started placing a lot less value on “personal skills”, and a lot more value on “effective observation”. We fled from the perception of insular and erratic, and fawned over the promise of insatiable hunger for insights. Which made a lot of sense because answers got a lot more accessible. 

In the early 2010s we got an explosion of light-weight-instrumentation analytics platforms. And that was hot on the heels of broad-reach, low-barrier “human factors” services. Riding the momentum of ubiquity - and the newfound upside of data-enabled precision - the art of observation and interrogation became a symbol of objectivity and rationality, and the most attractive, intrinsically measurable way to de-risk the cost of your attention, your prioritization, and ultimately, your decisions. 

Don’t get me wrong; the revolution of Data-Driven Decision-Making was essential. 

Value-generation and ROI as givens, I think about pushy Enterprise customers, God-complex founders, in-it-for-the-ownership PMs, prideful product designers, and all shades of SPITRS (Smartest Person In The Room Syndrome) who have been rightfully reconfigured over time as a result of people having easier and easier access to a ‘numbers don’t lie’ defense.   

That said, I think it has gone so far in one direction that it has skewed our math on what makes uniquely illustrious and impactful Senior Product Managers and leaders.

PMs are now too often discounting a hard reality that hasn’t left us, and never will. That reality is that with years and years of intelligent observing, ignoring, deciding, trying, failing, succeeding, learning, borrowing, inventing, discarding, iterating, and implementing, you are necessarily developing four critical, synergistic characteristics:

Validated Knowledge

Intelligent Instincts

Inspired Taste

Calculated Confidence

Whenever I’ve needed a Senior Product person, personally, I’ve needed those four things just as much or more than I’ve needed someone to work a Heap dashboard or execute an awesome A/B test. 

It DePendos On the Circumstances

Having spent most of my career in scale-ups and mature start-ups focused on growth through new and expanded products, I have spent most of my career confronted with questions that lead to more “decisions” than they do “answers”, if you know what I mean.

Ultimately, the right mix of Raw Input, Processed Feedback, and Existing Knowledge depends on the context. That context is also painted by the relative ‘domain expertise’ of the PM making the calls. 

(But be careful how conservatively you interpret the word, ‘domain’. I’ll get to that shortly.)

Here are two example scenarios I have experienced in the past that may help draw a spectrum of contexts and their varying key characteristics.

Scenario 1: Operational Mandates - There’s No Way For You to Know

In this scenario, a customer (often Enterprise) is facing some kind of operational mandate (i.e., “Business Rules”) as a result of regulation, internal policy, restructuring, or any number of other environmental prompts. 

One product I worked on with a past team was a bulk distribution tool for communications and financial disbursements. The complexity arose when a subset of recipients were part of defined “organizations” or “associations” - with or without designated leaders - and potentially subdivided further into tiers within those organizations..

These were sensitive communications, sometimes involving money. And the whole point of introducing the product was to replace the hours of manual intervention required for these distribution events - automation was critical.

So then come the questions: Who gets what? Lump sums or individual transactions? Who gets notified? What visibility do qualified ‘leaders’ have into recipient communications and PII? And many more.

The only way we could move forward intelligently was for these companies to tell us exactly what rules they needed applied. And those rules? They varied by company.

Some niche expertise helped grease the wheels, but to make it to the finish line customer guidance was absolutely non-negotiable.

Scenario 2: Existing Conventions - You Should Pretty Much Know This

Now let’s venture to the other side of the spectrum.

In previous lives, I have had teams working in the world of “Menus”. In one case, we were helping small businesses build out simple menus of services and shippable products. In another case, we were innovating on how enterprise food services companies build out and manage multi-layered (Corporate > Region > Network > Location) food and beverage menus. 

In this case, however, we discovered the need for something in-between: small businesses building out and managing food and beverage menus for group orders and corporate catering, with a portion of those businesses needing to account for multiple locations with subtle differences between them. 

But here’s the thing: we had experience. I had built similar things before, and a Senior PM on the team had as well. We also had, as did everyone else with an internet connection, access to tons of the existing ‘hard’-menus and websites from these small businesses. 

So what do you think our first step was under these circumstances? 

Was it to gather a bunch of data, customer feedback, and market comparables? Thorough analysis of alternatives, risk, and opportunities? 

No. Our first step was LFG (Let’s Freaking Go).

We needed to move fast, and we could move fast. Collectively, in this space we had been through many cycles of inception, discovery, prioritization, design, tinkering, listening, watching, refining, revising, reprioritization, getting it wrong, and then getting it really right - all the while watching where possible, ‘what everyone else was doing about this problem’. 

Of course we invested a lot of time and thought into the MVP and rollout strategy; and what would be optimal UX/UI in consideration of both our existing application experience and what vendors were already used to (the latter of which we already had a lot of experience); and there were certainly problems that we were about to solve that hadn’t entirely been solved in this context before.

We hit the gas hard based on our own validated knowledge, intelligent instincts, inspired taste, and calculated confidence, and agreed that when we encountered a truly novel fork in the road we would pump the brakes, dangle an arm out of the race car, scoop up what we needed from the market, and then get back to strong decision-making at top speed.     

And it worked out really well.

The Pseudo-Scenario: Conventions Are Everywhere

What I hope hasn’t happened after reading the above scenarios is a conflation of “general knowledge” with “industry expertise”. Sure, there are elements of narrow familiarity in the menus example, but if you zoom out you’ll realize that many products are built on convention-rich fundamentals that many PMs should master and internalize over time.

Just to name a few, ranging from components to products:

  • Order/shopping carts and checkouts
  • CMS libraries
  • Product catalogues and product pages
  • Editors
  • Artifact / asset lists
  • Tables and matrices 
  • Settings and configurations
  • Activity histories and chronological representations of messages, assets, and events
  • Summary screens (as a pre-trigger step to a manual workflow)
  • Automated workflows and status management
  • Marketplace views and tools: buyers, sellers, administrators
  • Central-to-distributed / ‘dispatch-to-fleet’ relationships
  • 1-to-1 and group messaging
  • Posts and comment threads
  • Badges, indicators, and labels/chips
  • Searches and search results
  • Product onboarding
  • Information architecture
  • Dashboards, reports, and primary vs. secondary data hierarchies

and more.

This is not to suggest that anything above is a no-brainer, or that it is cookie-cutter, or that once you’ve done it before it never requires any kind of up-to-date insights in order to make new, nuanced decisions. 

This is also not to suggest that when you are working on truly novel products that innovatively integrate and evolve ingredients from the above list (and beyond) you won’t be reliant on new data and thus refined skills in seeking, capturing, distilling, prioritizing, and applying that data.

I am also a big advocate of always trying to achieve brand-defining, industry-advancing, eye-bulging UX. So this is definitely not suggesting that you shouldn’t need to spend time on impeccable, original design.  

This is suggesting, however, that the more experience you have - used wisely - the less reliant you become on external input, the better equipped you are to navigate when reliance is necessary, and the more momentum to “Done” you’ll be able to generate individually, and by extension, within the capacity of your team.    

Feed Me Your Experience AlgoRYTHM 

As a small detour of acknowledgement, it should be noted that I haven’t even touched on the other super-booster here: repeat experience with the many processes and points of failure that come into play when trying to successfully move things from 0 to 1. 

For example, to PMs who may feel confined in a “Feature Factory”: though you’re not always starting from ‘absolute zero’, don’t underestimate the value you’re building from the experience of taking new things to market over and over and over again.

Back to the main road though - hopefully we’re all landing in a similar place on this.

Once we’re in the realm of “Senior”, I’m not looking for a mind-reader, but I do expect some heightened skills in understanding how people usually think and react. 

Will you always definitively “know”? No. Uncertainty is inherent to the world of thought leadership. But you should often have a pretty solid opinion - an intelligent, low-risk take on where something is probably going to land and what it looks like when it sticks that landing. You should have some elevated taste, and a sharp nose for what’s “off”. You should have access to express judgments that are far more often near the bullseye than they are the edges of the board.

You’ve been compiling years and years of information and answers about how things actually work - not just learning ways to find out how they should.    

You’ve seen this before 100 times - or something like it; where does it usually take us? Where should it take us? Step away from the data for a second - if you’re even able to get your hands on enough of it, and enough of the good stuff to make it convincing - and tell me, “what does your experience tell you?”. 

How fast do you hit the ground running? How often do you need to slow down? What advantage do I get by mining your data set of 7+ years in the field? If all the answers you need are out there, then why do I need you in here?

Your successes are important, your approach is paramount, and your skills are essential. Especially communication - oh, man are you gonna need to be an amazing communicator. I need to know about all of that. But you’re going to be making a lot of big decisions under a lot of different circumstances. So don’t shy away from the stuff you think that I’ll think is soft. 

Tell me about the knowledge you’ve accumulated after thousands of hours of research and repetition; about how you’ve sharpened your instincts over hundreds of edges; how your tastes have evolved from Product Pupil to Software Sommelier; how you rarely flinch in the face of ambiguity, because for every ounce of uncertainty, you’ve got two ounces of your own unique stabilizing insights. 

In a world overflowing with frameworks, data, and tools, experience is your seniority edge.

Talk to me about that stuff. Give me that data.

What you get as a TPMA Member

Mentorship program and in-person event experiences are at an extra cost.

Join for free!
  • Join the TPMA Slack Community with 1000+ members

  • Free Virtual TPMA events for the entire TPMA Season

  • Become the first to know about in-person events and networking opportunities

Beyond data: why experience defines senior PMs

August 7, 2025

Somewhere along the line, many PMs pursuing a “Senior” career have lost sight of the most critical value proposition of being “Senior”: Experience.

Being a crafty Product professional yourself, I’m sure you’re itching to dig deeper into that loaded word, “experience”. What do I actually mean by “experience” in this context? 

Well, in short, experience means: “you’ve done this before”, “you’ve seen this before” - and hopefully, many times before.

Now I’ll bet your PM instincts are really starting to kick into gear, aren’t they? Fantastic. Keep pressing me. Why is “experience” such a critical element of being a “Senior” PM? Why does it matter that you’ve “done it” and “seen it” before? Many times before?

Great question. 

Because the more you’ve “done it” and “seen it” - assuming you’ve “done it” and “seen it” effectively - the fewer questions you’ll have to ask while you’re “doing it” and “seeing it” again.

A.k.a. You already know things that less experienced people don’t. 

🚨ALARM SOUNDS🚨

Uh-oh, call the PM Police; is he telling Product Managers to be anti-curiosity?

No, no, no I’m not. Grab your blood pressure medication, take a breath, and hear me out. 

I’m not saying Senior PMs - or any level of PM - shouldn’t be asking questions. What I am saying is that hopefully, if you’ve been doing this long enough, well enough, the number of circumstances under which you are reliant on someone else’s answers go down (e.g., user research), the odds of having a blocking question go down, and the odds of you being able to unleash yourself and your team into warp speed while making sound decisions along the way go way up.

What a Data Be Alive

Ultimately, over time we have culturally shifted how we communicate and calculate the worth of a Product Manager. Our industry started placing a lot less value on “personal skills”, and a lot more value on “effective observation”. We fled from the perception of insular and erratic, and fawned over the promise of insatiable hunger for insights. Which made a lot of sense because answers got a lot more accessible. 

In the early 2010s we got an explosion of light-weight-instrumentation analytics platforms. And that was hot on the heels of broad-reach, low-barrier “human factors” services. Riding the momentum of ubiquity - and the newfound upside of data-enabled precision - the art of observation and interrogation became a symbol of objectivity and rationality, and the most attractive, intrinsically measurable way to de-risk the cost of your attention, your prioritization, and ultimately, your decisions. 

Don’t get me wrong; the revolution of Data-Driven Decision-Making was essential. 

Value-generation and ROI as givens, I think about pushy Enterprise customers, God-complex founders, in-it-for-the-ownership PMs, prideful product designers, and all shades of SPITRS (Smartest Person In The Room Syndrome) who have been rightfully reconfigured over time as a result of people having easier and easier access to a ‘numbers don’t lie’ defense.   

That said, I think it has gone so far in one direction that it has skewed our math on what makes uniquely illustrious and impactful Senior Product Managers and leaders.

PMs are now too often discounting a hard reality that hasn’t left us, and never will. That reality is that with years and years of intelligent observing, ignoring, deciding, trying, failing, succeeding, learning, borrowing, inventing, discarding, iterating, and implementing, you are necessarily developing four critical, synergistic characteristics:

Validated Knowledge

Intelligent Instincts

Inspired Taste

Calculated Confidence

Whenever I’ve needed a Senior Product person, personally, I’ve needed those four things just as much or more than I’ve needed someone to work a Heap dashboard or execute an awesome A/B test. 

It DePendos On the Circumstances

Having spent most of my career in scale-ups and mature start-ups focused on growth through new and expanded products, I have spent most of my career confronted with questions that lead to more “decisions” than they do “answers”, if you know what I mean.

Ultimately, the right mix of Raw Input, Processed Feedback, and Existing Knowledge depends on the context. That context is also painted by the relative ‘domain expertise’ of the PM making the calls. 

(But be careful how conservatively you interpret the word, ‘domain’. I’ll get to that shortly.)

Here are two example scenarios I have experienced in the past that may help draw a spectrum of contexts and their varying key characteristics.

Scenario 1: Operational Mandates - There’s No Way For You to Know

In this scenario, a customer (often Enterprise) is facing some kind of operational mandate (i.e., “Business Rules”) as a result of regulation, internal policy, restructuring, or any number of other environmental prompts. 

One product I worked on with a past team was a bulk distribution tool for communications and financial disbursements. The complexity arose when a subset of recipients were part of defined “organizations” or “associations” - with or without designated leaders - and potentially subdivided further into tiers within those organizations..

These were sensitive communications, sometimes involving money. And the whole point of introducing the product was to replace the hours of manual intervention required for these distribution events - automation was critical.

So then come the questions: Who gets what? Lump sums or individual transactions? Who gets notified? What visibility do qualified ‘leaders’ have into recipient communications and PII? And many more.

The only way we could move forward intelligently was for these companies to tell us exactly what rules they needed applied. And those rules? They varied by company.

Some niche expertise helped grease the wheels, but to make it to the finish line customer guidance was absolutely non-negotiable.

Scenario 2: Existing Conventions - You Should Pretty Much Know This

Now let’s venture to the other side of the spectrum.

In previous lives, I have had teams working in the world of “Menus”. In one case, we were helping small businesses build out simple menus of services and shippable products. In another case, we were innovating on how enterprise food services companies build out and manage multi-layered (Corporate > Region > Network > Location) food and beverage menus. 

In this case, however, we discovered the need for something in-between: small businesses building out and managing food and beverage menus for group orders and corporate catering, with a portion of those businesses needing to account for multiple locations with subtle differences between them. 

But here’s the thing: we had experience. I had built similar things before, and a Senior PM on the team had as well. We also had, as did everyone else with an internet connection, access to tons of the existing ‘hard’-menus and websites from these small businesses. 

So what do you think our first step was under these circumstances? 

Was it to gather a bunch of data, customer feedback, and market comparables? Thorough analysis of alternatives, risk, and opportunities? 

No. Our first step was LFG (Let’s Freaking Go).

We needed to move fast, and we could move fast. Collectively, in this space we had been through many cycles of inception, discovery, prioritization, design, tinkering, listening, watching, refining, revising, reprioritization, getting it wrong, and then getting it really right - all the while watching where possible, ‘what everyone else was doing about this problem’. 

Of course we invested a lot of time and thought into the MVP and rollout strategy; and what would be optimal UX/UI in consideration of both our existing application experience and what vendors were already used to (the latter of which we already had a lot of experience); and there were certainly problems that we were about to solve that hadn’t entirely been solved in this context before.

We hit the gas hard based on our own validated knowledge, intelligent instincts, inspired taste, and calculated confidence, and agreed that when we encountered a truly novel fork in the road we would pump the brakes, dangle an arm out of the race car, scoop up what we needed from the market, and then get back to strong decision-making at top speed.     

And it worked out really well.

The Pseudo-Scenario: Conventions Are Everywhere

What I hope hasn’t happened after reading the above scenarios is a conflation of “general knowledge” with “industry expertise”. Sure, there are elements of narrow familiarity in the menus example, but if you zoom out you’ll realize that many products are built on convention-rich fundamentals that many PMs should master and internalize over time.

Just to name a few, ranging from components to products:

and more.

This is not to suggest that anything above is a no-brainer, or that it is cookie-cutter, or that once you’ve done it before it never requires any kind of up-to-date insights in order to make new, nuanced decisions. 

This is also not to suggest that when you are working on truly novel products that innovatively integrate and evolve ingredients from the above list (and beyond) you won’t be reliant on new data and thus refined skills in seeking, capturing, distilling, prioritizing, and applying that data.

I am also a big advocate of always trying to achieve brand-defining, industry-advancing, eye-bulging UX. So this is definitely not suggesting that you shouldn’t need to spend time on impeccable, original design.  

This is suggesting, however, that the more experience you have - used wisely - the less reliant you become on external input, the better equipped you are to navigate when reliance is necessary, and the more momentum to “Done” you’ll be able to generate individually, and by extension, within the capacity of your team.    

Feed Me Your Experience AlgoRYTHM 

As a small detour of acknowledgement, it should be noted that I haven’t even touched on the other super-booster here: repeat experience with the many processes and points of failure that come into play when trying to successfully move things from 0 to 1. 

For example, to PMs who may feel confined in a “Feature Factory”: though you’re not always starting from ‘absolute zero’, don’t underestimate the value you’re building from the experience of taking new things to market over and over and over again.

Back to the main road though - hopefully we’re all landing in a similar place on this.

Once we’re in the realm of “Senior”, I’m not looking for a mind-reader, but I do expect some heightened skills in understanding how people usually think and react. 

Will you always definitively “know”? No. Uncertainty is inherent to the world of thought leadership. But you should often have a pretty solid opinion - an intelligent, low-risk take on where something is probably going to land and what it looks like when it sticks that landing. You should have some elevated taste, and a sharp nose for what’s “off”. You should have access to express judgments that are far more often near the bullseye than they are the edges of the board.

You’ve been compiling years and years of information and answers about how things actually work - not just learning ways to find out how they should.    

You’ve seen this before 100 times - or something like it; where does it usually take us? Where should it take us? Step away from the data for a second - if you’re even able to get your hands on enough of it, and enough of the good stuff to make it convincing - and tell me, “what does your experience tell you?”. 

How fast do you hit the ground running? How often do you need to slow down? What advantage do I get by mining your data set of 7+ years in the field? If all the answers you need are out there, then why do I need you in here?

Your successes are important, your approach is paramount, and your skills are essential. Especially communication - oh, man are you gonna need to be an amazing communicator. I need to know about all of that. But you’re going to be making a lot of big decisions under a lot of different circumstances. So don’t shy away from the stuff you think that I’ll think is soft. 

Tell me about the knowledge you’ve accumulated after thousands of hours of research and repetition; about how you’ve sharpened your instincts over hundreds of edges; how your tastes have evolved from Product Pupil to Software Sommelier; how you rarely flinch in the face of ambiguity, because for every ounce of uncertainty, you’ve got two ounces of your own unique stabilizing insights. 

In a world overflowing with frameworks, data, and tools, experience is your seniority edge.

Talk to me about that stuff. Give me that data.