u/Humble-Pay-8650

I'm currently a mid career PM. At Amazon, I understand there are two PM tracks: technical and non-technical.

I’ve been speaking with L6 PMs from both tracks because I’m trying to figure out which path I should choose for interviews. My long-term goal is to move into VP of Product or CPO type roles, so I want to make sure I pick the track that helps me build strong strategic thinking and decision-making skills over time.

So far, the tech PMs I spoke with spend most of their time talking about the solutions they’ve built. They usually start with a problem statement, then explain the solution they designed, how they partnered with engineering or data science to test it, and how they scaled it based on results. It feels more execution-heavy and focused on building at the micro level.

Even when I spoke with an L7 technical PM, the conversation stayed mostly around solutions and delivery.

On the other hand, the few non-technical PMs I’ve spoken with seem to focus more on the business side. They think more about business outcomes and work closely with different stakeholders, including suppliers in some cases. But I still don’t have a very deep sample size here.

So I’m trying to understand: which track would better help me build the kind of strategic thinking and decision-making capability needed for senior leadership roles?

Right now, I’m leaning toward the track that pushes me more toward business and strategy thinking, rather than staying mostly in execution.

I keep hearing that “you have to simplify things” and that simplification is key in product management.

But what does simplification actually mean and look like in practice and context of Product Management?

Based on my personal experience, I have my own interpretation of what simplification means, but I’m still trying to understand how people actually simplify things at a deeper level.

From my own experience, I see two different types of simplification.

The first is execution or product-level simplification.

For example, I worked on a customer workflow that originally took 17 steps across multiple tools. I studied what customers were actually trying to accomplish and rebuilt the workflow into 3 steps directly within our platform. So in this case, simplification meant reducing customer complexity and making the workflow easier and faster.

The second type is strategy-level simplification.

I inherited a product domain with three separate products that had all grown organically over time to solve different customer needs. When I talked to internal stakeholders, nobody could clearly explain why all three products existed, how they connected together, or how they tied back to business value. Everyone had surface-level explanations, but there was no clear organizing principle.

To solve this, I did market research and customer research and identified one common thread across all three products. Once I had that, I used it as a decision-making filter to define the vision and strategy for the domain. It made investment trade-offs much clearer, helped me put one underperforming product into maintenance mode, and redirected investment toward the higher-leverage products. Those decisions ended up influencing about $8M in renewal revenue.

So in one case, simplification reduced customer workflow complexity. In the other, it reduced organizational and strategic complexity and created clarity.

From my own experience, I see two different types of simplification.

The first is execution or product-level simplification.

For example, I worked on a customer workflow that originally took 17 steps across multiple tools. I studied what customers were actually trying to accomplish and rebuilt the workflow into 3 steps directly within our platform. So in this case, simplification meant reducing customer complexity and making the workflow easier and faster.

The second type is strategy-level simplification.

I inherited a product domain with three separate products that had all grown organically over time to solve different customer needs. When I talked to internal stakeholders, nobody could clearly explain why all three products existed, how they connected together, or how they tied back to business value. Everyone had surface-level explanations, but there was no clear organizing principle.

To solve this, I did market research and customer research and identified one common thread across all three products. Once I had that, I used it as a decision-making filter to define the vision and strategy for the domain. It made investment trade-offs much clearer, helped me put one underperforming product into maintenance mode, and redirected investment toward the higher-leverage products. Those decisions ended up influencing about $8M in renewal revenue.

So in one case, simplification reduced customer workflow complexity. In the other, it reduced organizational and strategic complexity and created clarity.

Which type of example would be stronger for L6/L7 interviews?

The product-level example feels more obvious and directly tied to simplification, but I also worry it may come across as too execution-focused. The strategy-level example feels more aligned with senior-level thinking, but I’m not sure if interviewers would view that as “Invent and Simplify” in the same way.

I'm trying to figure out if I've ever worked on anything complicated or if I suck at explaining the complexity of the problems I've worked on. The feedback I always get is either people wondering why I think my example is complicated or that I need to tackle more complex problems if I want to advance my career.

I would love to hear other people's stories to know if I'm missing out on complicated problems or get some good examples of explaining complex problems so others can see the complexity.

My example:

I led an E2E initiative everything from problem discovery to customer experience evaluation and execution coordination across multiple cross-functional teams and launch. About three teams were involved, so one layer of complexity was simply stakeholder management and dependency coordination.

Another complexity was around MVP scope definition. There was a debate about whether we should release a narrow MVP with just one feature, or build a broader first version. My broader product vision included around five core features for the initiative.

I know MVPs are a very common product management concept, but based on prior customer conversations and business context, I believed this initiative would perform well and had already been delayed for a long time because of other priorities. So I leaned toward a broader first release rather than an ultra-narrow MVP.

Before execution even started, I also had to drive a build-vs-buy decision. I leaned toward buying the dataset from a vendor instead of building it in-house. I spent a lot of time evaluating the trade-offs before arriving at that recommendation.

Convincing the data team was not straightforward. The data director had concerns about the approach, but I walked them through my analysis, reasoning, and evaluation process to get alignment.

After that, the complexity shifted into coordinating development across three different teams while also managing the vendor relationship. During integration, we ran into technical issues with the vendor data integration. They initially looked complex, but I knew they were solvable because the vendor had experience integrating with multiple companies before.

There was also pressure because other teams were dependent on my team’s output, so any delays from our side could become a bottleneck for the broader initiative.

These are the main complexities I can think of right now.

Hey everyone,

I’m trying to understand what kinds of disagreement examples actually demonstrate the right mental model for L6 PMT. Not just “I disagreed with leadership,” but situations where the disagreement shows strong judgment, prioritization, and alignment with business impact.

One example I currently have is this:

I pitched a zero-to-one initiative that I believed could unlock ~5X revenue over the next decade. For phase one, I asked for additional resources so I could execute the MVP while also continuing my existing product responsibilities.

However, leadership disagreed and decided we should only allocate more resources after the MVP proved success.

I disagreed with this approach because I believed the initiative had strong early signals and could contribute meaningfully to revenue earlier, especially through renewal conversations where it could help drive higher contract value without discounts. So from my perspective, there was already a clear line of sight to business impact.

At the same time, I did not escalate or block the decision. I committed to it, scoped the MVP tightly, and moved forward with existing resources. I also recognized that despite the upside, there was uncertainty and we needed to validate the direction step by step before scaling investment.

My question is:

Is this a strong enough example for “disagree and commit” at L6?

Also, what kinds of disagreement scenarios tend to resonate better at L6 level interviews?

I keep hearing a recurring theme in product management: the PMs who get promoted are often the ones who “spot things others miss” identify opportunities early, build conviction, and then drive execution and outcomes.

I understand the idea in theory, and even my coach reinforces this: you need to notice gaps, build a business case, get buy-in, and then execute.

But what I’m struggling with is the how.

How do you actually develop the ability to spot these opportunities in the first place?

Right now, most of my time is spent in execution mode shipping work, handling dependencies, and dealing with day-to-day firefighting. Between that and existing roadmap commitments, I genuinely don’t see how people create the space to step back and identify these “missed opportunities” without either:

• Working constantly beyond normal hours, or
• Sacrificing execution quality on current priorities

So I’m trying to understand:

• Is this expectation of “spotting what others miss” something that naturally comes from seniority and pattern recognition over time?
• Or is there a deliberate practice or habit that PMs use to build this capability?
• And practically, how do you balance execution with the kind of exploratory thinking that leads to new opportunities?

Would really appreciate how more experienced PMs think about this.

Hey everyone,

I’ve recently been looking more into asymmetric investing and high-upside opportunities.

I have around $20K that I’m willing to allocate toward higher-risk, asymmetric bets like RKLB, IONQ.

Which ones should I buy tomorrow? I'm considering Reddit stock and couple other asymmetric stocks.

I wanted to get some outside perspective on a situation I recently handled at work and whether my thinking had any blind spots.

I was working on a new zero-to-one initiative (let’s call it Project A) that was part of a broader strategic direction for the company. At a high level, it was aimed at building a new workflow experience for customers.

At the same time, I also had existing mature products (let’s call them Project B) within my product portfolio that were already generating meaningful revenue and required ongoing investment to maintain and improve.

The challenge was that engineering resources were limited, and both areas were competing for the same capacity.

I felt that if we didn’t invest enough early into Project A, we risked slowing down learning and speed to market. Because of that, I initially made a case for additional engineering resources so we could:

• continue supporting Project B properly without disruption, and
• also move faster on Project A

However, leadership decided not to add additional headcount.

Their reasoning was that Project A still carried a high level of uncertainty. While the direction was compelling, we had not yet proven that users would consistently adopt the new workflow at scale. From their perspective, it would be risky to pull significant engineering capacity away from proven revenue-generating products before validating the MVP.

So instead of increasing resources, the decision was to move forward with existing capacity and split it across both efforts.

In practice, that meant I had to operate in roughly a 50/50 allocation between Project A and Project B.

I didn’t fully agree with the level of conservatism in that decision at first. My concern was that underinvesting in Project A could slow down momentum and reduce long-term upside. But once the decision was made, I fully committed to it and focused on executing within the constraints rather than continuing to push for more resources.

What I’m trying to reflect on is:

• Was my instinct to push for more resources reasonable, or was I over-weighting future opportunity vs. execution risk?
• How do you typically think about balancing investment in stable revenue products vs. early-stage initiatives?
• Are there any blind spots in how I framed or approached this tradeoff?

Would really appreciate honest feedback from people who’ve navigated similar product/resource allocation decisions.

Hey everyone,

I’m trying to improve my product thinking and business acumen, and I’ve been thinking about studying business/product/feature analyses of companies that recently made notable product moves.

The idea is to pick a product or feature launch, and then break it down from a PM perspective. Specifically trying to understand:

• Why the company made that decision
• What market opportunity or user problem they were targeting
• What business outcome they were aiming for
• And how strong that reasoning actually is

Before I start doing this on my own, I wanted to ask:

Are there any good resources, blog posts, frameworks, or examples where people already do this kind of structured product analysis or teardown?

Ideally something that goes beyond UX critique and goes into product strategy, market reasoning, and business impact.

Would really appreciate any recommendations or examples that have helped you think this way.

I’m a PM with ~8 years of experience, and whenever I do behavioral mock interviews with PMs who have 15+ years of experience, is that they often suggest reframing my narratives or decisions in a different way.

Most of the time, I actually agree with their feedback after hearing it. The reframing usually makes the story sound more senior, strategic, higher leverage, or more aligned to leadership thinking. But my challenge is: how do I develop the ability to come up with those reframes on my own instead of only recognizing them after someone points them out?

I’m trying to understand:

• How do experienced PMs develop strong narrative framing and decision framing instincts?
• What daily habits, mental models, or exercises helped you improve this skill?
• Are there specific resources, coaching approaches, books, or frameworks that helped you communicate/frame your narratives and decisions effectively?
• Is this mainly pattern recognition that comes with experience and time, or are there deliberate ways to practice it?

Would especially love advice from senior PMs/directors who became noticeably better at storytelling, strategic framing, and communicating tradeoffs over time.

I’m really trying to understand how to justify speed under uncertainty and constraints.

What I mean by that is: there were several situations while working on an MVP where I intentionally prioritized speed/learning over perfection/completeness.

For example, during the MVP launch, we ran into quality and coverage issues with production data set. At that point, I made the decision to move forward with the good, high-confidence data we already had instead of waiting for full set. My thinking was that if the MVP showed promise and customers responded positively, we could gradually improve and expand the data coverage over time. I made that call mainly to keep the teams unblocked and continue learning from real users rather than stalling execution.

There was another situation involving a dependency on another team’s feature. Instead of waiting an additional quarter for that dependency to become available, I redesigned the workflow to remove the dependency entirely. The redesigned version still solved the core user problem sufficiently for the MVP, even if it wasn’t the ideal long-term solution. My assumption was that if user behavior evolved and the workflow proved valuable, we could later invest in the more complete integration with the dependent team.

Even stepping back further, the decision to pursue the MVP itself was a speed-versus-certainty tradeoff. I could have continued investing in our existing stable products that were already driving retention and revenue. Instead, I chose to invest in this MVP because it was part of a larger strategic opportunity that I believed could significantly expand the business long term potentially even 5x revenue over time.

To reduce risk, I scoped the MVP very tightly. The idea was: if we saw early traction and meaningful customer signals, then we would continue investing and gradually scale the initiative. If not, we could pivot quickly without overcommitting resources upfront.

Throughout all of this, the principle I kept coming back to was that this was an MVP, and the primary goal was learning. I didn’t want to spend too much time optimizing for perfection too early, especially when that time was coming at the expense of already proven products and roadmap priorities.

At the same time, I sometimes wonder whether my reasoning for moving fast was actually strong product thinking, or whether it was just my own personal preference for speed. For example, in the dependency situation, some stakeholders suggested waiting another quarter for the “proper” integration rather than redesigning around it. But I pushed back because I felt the redesigned workflow solved the immediate customer problem well enough for the stage we were in.

So I’m trying to better understand: is this actually good product judgment around MVPs, reversibility, and learning velocity? Or is this something stakeholders and experienced leaders would see as impatience or underthinking second-order consequences?

One of the products I currently work on had just reached PMF when I took it over. At that point, the challenge shifted from simply proving value to figuring out how to scale the next phase of growth.

As part of that effort, I spent a lot of time talking to customers, reviewing submitted feedback, and trying to understand what we should build next. My natural approach in B2B product management has always been: if customers are explicitly asking for something, I use that feedback as a starting point to explore the broader problem space. I try to understand the magnitude of the problem, whether it’s worth solving, whether solving it could help us win more deals or reduce churn.

While I was describing this process to my manager, he said something like this: “You have to anticipate customer needs.”

I honestly don't fully understand what he meant.

My thinking was: if customers are already submitting feedback or explicitly asking for something, then I know where to start. But what does it actually mean to anticipate customer needs? How do you identify a need before customers can clearly articulate it themselves? How do you come up with something when there isn’t an obvious request sitting in front of you?

I’m a PM at a B2B data platform company, and I’m looking for feedback on whether I’m approaching a product/data dependency problem the right way.

We’re building a zero-to-one product around structured event intelligence — things like attendees, organizations, and relationships around industry events. The MVP timeline is aggressive (~6 months), and multiple downstream teams are blocked on production data being finalized before they can fully move forward.

During ingestion, we discovered that a significant portion of event records had incomplete organization entity links. The fix is mostly manual — the data team would need to hand-link missing entities one by one — and there’s realistically no way all of that work gets completed before launch.

At that point, I had two options:

• Wait for complete production-quality data
• Or move forward with partial coverage and design the MVP around it

I’m leaning toward moving forward with what we have, while reducing risk intentionally.

The approach I’m considering:

• Segment the dataset into three buckets:
  1. Events with complete attendee/org coverage
  2. Events with ~70%+ coverage
  3. Events below that threshold

For the MVP:

• Prioritize fully complete events first
• Include high-confidence (~70%+) events where the experience is still usable
• Completely exclude below-threshold events from the product to avoid obviously broken experiences

I’m also planning to:

• Work with domain experts to identify the highest-priority events by customer importance
• Escalate important but incomplete records to the data team for manual completion before launch
• Design engineering systems assuming at least 2x future data scale
• Build graceful handling for missing links instead of hard failures
• Add user-facing feedback mechanisms post-launch so customers can flag missing coverage directly

My reasoning is that this is an MVP, and early customer learning is more valuable right now than waiting for completeness.

A few things I’d love feedback on:

• Am I thinking about this trade-off correctly?
• What risks am I likely underestimating?
• Have you seen partial-data launches backfire? If so, why?
• How do you determine the minimum acceptable quality threshold for an MVP in data-heavy products?
• Are there operational or stakeholder-management challenges I should think through earlier?

Would especially appreciate perspectives from PMs, data platform teams, or anyone who has dealt with upstream data quality dependencies in zero-to-one products.

I’m a PM at a B2B data platform company, and I’m looking for feedback on whether I’m approaching a product/data dependency problem the right way.

We’re building a zero-to-one product around structured event intelligence — things like attendees, organizations, and relationships around industry events. The MVP timeline is aggressive (~6 months), and multiple downstream teams are blocked on production data being finalized before they can fully move forward.

During ingestion, we discovered that a significant portion of event records had incomplete organization entity links. The fix is mostly manual — the data team would need to hand-link missing entities one by one — and there’s realistically no way all of that work gets completed before launch.

At that point, I had two options:

• Wait for complete production-quality data
• Or move forward with partial coverage and design the MVP around it

I’m leaning toward moving forward with what we have, while reducing risk intentionally.

The approach I’m considering:

• Segment the dataset into three buckets:
  1. Events with complete attendee/org coverage
  2. Events with ~70%+ coverage
  3. Events below that threshold

For the MVP:

• Prioritize fully complete events first
• Include high-confidence (~70%+) events where the experience is still usable
• Completely exclude below-threshold events from the product to avoid obviously broken experiences

I’m also planning to:

• Work with domain experts to identify the highest-priority events by customer importance
• Escalate important but incomplete records to the data team for manual completion before launch
• Design engineering systems assuming at least 2x future data scale
• Build graceful handling for missing links instead of hard failures
• Add user-facing feedback mechanisms post-launch so customers can flag missing coverage directly

My reasoning is that this is an MVP, and early customer learning is more valuable right now than waiting for completeness.

A few things I’d love feedback on:

• Am I thinking about this trade-off correctly?
• What risks am I likely underestimating?
• Have you seen partial-data launches backfire? If so, why?
• How do you determine the minimum acceptable quality threshold for an MVP in data-heavy products?
• Are there operational or stakeholder-management challenges I should think through earlier?

Would especially appreciate perspectives from PMs, data platform teams, or anyone who has dealt with upstream data quality dependencies in zero-to-one products.

I’m a PM at a B2B SaaS/data platform company, and I’m looking for feedback on a dependency/trade-off decision I’m currently navigating for a new zero-to-one product initiative.

Context:
This initiative is the first phase of a broader strategic investment area for the company, and we have an aggressive 6-month timeline to launch an MVP and start validating customer demand.

The challenge:
My team is currently blocked on a dependency with our data/platform team, who are still finalizing the production-grade dataset required for the product experience.

That dependency is now starting to impact overall timelines, so I’m evaluating two approaches:

Option 1: Wait for full production-ready data

• Higher data completeness and cleaner long-term setup
• Ideally, users prefer complete data. But they dont know what "Complete" dataset is
• Lower risk of future rework
• But longer timelines and delayed customer learning

Option 2: Launch with partial data (60%) and iterate

• Faster delivery and earlier feedback from real users
• Lets frontend/search/non-data teams continue building in parallel
• But introduces risk around incomplete coverage, edge cases, and future rework

Right now, I’m leaning toward Option 2 because:

• This is an MVP, and the goal is learning/validation more than completeness
• The decision feels reversible
• Waiting for “perfect” data could delay learning too much

Practically, the proposal would look something like:

• Launching with ~70% coverage using a smaller high-confidence subset of data for the MVP and gradually increasing coverage as we go.
• Designing systems assuming future scale growth (ex: 2x+ expected volume)
• Designing workflows to tolerate missing edge cases gracefully instead of blocking execution
• Adding feedback loops post-launch (customer feedback, support signals, usage patterns) to identify coverage gaps quickly

A few things I’d love feedback on from experienced PMs/engineering leaders:

1. What risks am I underestimating with this approach?
2. What usually breaks when teams launch with partial datasets?
3. How do you decide whether a dependency is “good enough” for MVP validation?
4. Any advice on managing alignment/trust with stakeholders when knowingly launching with incomplete coverage?
5. Are there second-order effects I should think through before committing to this direction?

Would especially appreciate perspectives from people who’ve worked on platform/data-heavy products.

In my current product domain, the primary goal of the products we build is to increase the value customers derive from their platform subscription. Ultimately, that value is expected to show up in retention and renewals.

However, one challenge I’ve encountered is that we don’t have a clear way to identify which specific products influence pricing or renewal outcomes during customer conversations. While Sales captures notes in Salesforce after renewal discussions, this data is largely unstructured and difficult to tie back to specific product usage or impact at scale.

As a result, it becomes challenging to answer a key question: how much revenue in a given period can be attributed to each product on the platform?

This led me to explore a broader question: how do other B2B companies track product-level contribution to renewal outcomes and revenue impact.

I joined the new role expecting to own a single product, but once I got deeper into the space, I realized it was actually made up of five distinct product lines operating under one umbrella. How to balance a portfolio of products across different life stages?

Is there a mental model to know when to invest, when to maintain, and when to retire a product to protect the company's future?

I’m currently in a situation where I’m debating this trade-off.

I’m a platform PM working closely with our API team. They recently shared their product strategy, but most of it is centered around platform parity. Personally, I don’t think parity alone is a strong enough long-term strategy.

I’ve been thinking about doing independent research on what a stronger API strategy could look like and sharing those insights with the team. The reason I care is because their roadmap directly impacts my domain as well. They frequently depend on my team to enable data capabilities that power their API products, so if their strategy improves, it could create better long-term alignment and outcomes for both teams.

The challenge is: this work is outside my responsibility, and realistically, I don’t have much bandwidth. Taking this on would likely mean sacrificing time from my own roadmap and priorities.

So I’m curious:

• How do you decide when it’s worth stepping outside your scope?
• What signals tell you it’s worth the trade-off?

Thank you

I’m trying to refine how I think about and communicate my 0→1 product experience both for my day-to-day work and for behavioral interviews (especially for senior/staff PM roles). I’d love feedback on my current approach.

I work in a B2B SaaS environment and to me 0→1 product means the workflow doesn’t exist on our platform today.

Here's how I approached a 0->1 product in my current role:

Idea and validation:

• ⁠I discovered this problem through extensive market research, customer feedback, and seeking diverse perspectives from internal stakeholders.
• ⁠I also listened in on sales calls to understand how customers are currently expressing this need in real conversations.
• ⁠I reviewed customer feedback to identify recurring themes and used them to recruit users for deeper interviews.
• ⁠Then I conducted direct customer interviews across different user types with a goal to learn if this is a real problem with enough demand.

Business case: Once I’m confident in the problem, I built a business case. I partner with revenue/finance teams to create financial projections. Estimate revenue potential and long-term impact.

Leadership Buy-in: I align leadership using a simple narrative: What problem are we solving? Why does it matter? Why now? For “why now,” I typically focus on: Challenge competition and opportunity to win back customer spend currently going to other tools.

Defining MVP: Since there’s no existing product or usage data, I relied heavily on qualitative inputs. In my case, my 0->1 product had 5 core features. I partnered with design to build clickable prototypes. Tested those prototypes with customers. This helped me define an MVP based on real user feedback.

Execution: After defining MVP, move to delivery. I wrote requirements for all 5 core features. Negotiated timelines and managed dependencies across 6 teams. One challenge I ran into was one product team couldn’t support my request due to their own priorities. I had to find a workaround to stay on track without blocking the launch. Execution involved a lot of cross-functional coordination and ongoing trade-offs.

After launch, I track adoption and engagement. ~40% adoption among enterprise users in the first month. Grew to ~60% within three months. Passed X million in cost savings to customers.

What I’m looking for feedback on:

- Am I missing any critical steps in a 0→1 process?

- How would you improve this approach?

- Where should I go deeper (especially for staff-level expectations)?

- How would you expect this to be communicated in interviews?

Thank you

I’m trying to better understand what differentiates the scope of a Senior Product Manager from a Staff or Principal Product Manager.

In my current role, I own a product domain that includes four product lines. These span a mix of growth-stage and 0→1 products, and together they contribute to the business in two key ways: driving new revenue and protecting existing revenue.

From a user perspective, my domain touches a significant portion of the platform roughly 60% of users engage with at least one of these products as part of their workflow.

Given this scope, I’m trying to understand what truly defines readiness for a Staff or Principal role.
Is it:
Expanding scope horizontally (owning more products or domains)?
Increasing business impact (more revenue ownership, larger strategic bets)?
Or evolving how I operate within my current scope thinking and executing more like a Staff/Principal PM?

More specifically, I’m trying to understand whether the transition is primarily about what you own, or how you operate within what you own?