Bare Minimum Product Management
Refusing to move forward without the right questions being answered. The bare minimum job of product management is to be curious before being helpful.
The VP of Operations walks into the room with a slide deck and a solution. She’s confident. She’s articulate. She’s been thinking about this for weeks.
“We need a self-service portal for our field technicians. They’re calling the help desk 40 times a day for things they should be able to do themselves. I’ve already talked to three vendors.”
The product manager nods. Opens a Jira board. Starts writing tickets.
No one in that room asked what problem they were actually solving. No one asked what “success” would look like if they got it right. No one asked if the 40 daily calls were really about self-service — or if something else was breaking upstream.
That meeting felt productive. It wasn’t.
I’ve seen this moment play out hundreds of times. The stakeholder isn’t wrong for being confident. The PdM isn’t lazy for not pushing back. They just never learned that the bare minimum job of product management is to be curious before being helpful.
Forget MVP — minimum viable product. The thing nobody talks about is the minimum viable thinking required at every stage of a product’s life.
The Curiosity Tax You’re Already Paying
Teams skip curiosity for two reasons.
The first is a confident stakeholder.
Someone senior walks in with a solution already baked, and the PdM defers. It feels respectful. It feels efficient. It’s neither.
The second is the belief that asking more questions “adds more work.”
This one is sneaky because it feels logical in the moment. Why slow down to ask questions when we could just start building?
Here’s the truth: skipping curiosity doesn’t save time. It moves the cost downstream. You pay it in rework. You pay it in misalignment three sprints later. You pay it in shipped features that no one uses. You pay it in the slow erosion of trust when your team realizes you built the wrong thing.
Benjamin Franklin had it right.. “An ounce of preparation is worth a pound of the cure.”
After coaching over 200 product professionals across different industries, company sizes, and levels of organizational maturity, we started noticing something that bothered us. Every team is different. Every market is different. But the gaps are actually pretty similar.
The information differs. The curiosity gap is universal.
And that’s the distinction that matters most:
bare minimum information is a template. You can Google it. You can copy someone else’s PRD format. Bare minimum curiosity is a skill and it’s the one most people were never taught.
The Two Questions That Change Everything
Here’s the simplest version of bare minimum curiosity I can give you.
Stakeholders and customers are experts in their problems. They live inside those problems every day. But they don’t talk about problems because no one prompts them to. They default to solutions, because solutions feel productive. Solutions feel like progress. Problems feel like complaining.
Your job is to create the space for the real conversation.
And sometimes that starts with just two questions:
“What is the problem we’re solving?”
“What signal will show us we’ve been successful?”
That’s it. Those two. Quite simple. And most teams aren’t asking them consistently at any stage.
Protege Tip: These two questions are just examples — the bare minimum curiosity shifts depending on where you are in the product journey. In the E3 Product Mindset, curiosity looks different at every phase. During Envision, your curiosity is anchored in the problem and the signals: What pain are we solving, and how will we know we got it right? During Empower, curiosity turns inward toward the build: Did we remove friction for the people co-creating this solution — engineering, design, stakeholders — so the right thing actually gets built? And during Elevate, curiosity becomes the “so what?”: Did this actually add value for the customer or the business? The questions change. The discipline of asking them doesn’t.
Bare Minimum Curiosity Has Three Modes
Most people think curiosity is a personality trait, something you either have or you don’t. In practice, it’s a set of behaviors. Modes you shift between depending on what the moment requires.
After years of coaching, observing, and pressure-testing what actually works in real product teams, we’ve identified three modes of curiosity that every PdM needs in their toolkit.
1. Tactically Curious — “What do I need to learn to unblock the next move?”
Tactical curiosity is more surgical. You know you have gaps. Instead of guessing or stalling, you run targeted discovery to fill exactly those gaps. Nothing more, nothing less.
Context: Imagine you’re a PdM at a mid-sized SaaS company. You’re building a pitch deck for a new integration your team wants to prioritize next quarter. You’ve got the market context and the competitive landscape, but you’re missing customer evidence and a clear sizing of the opportunity. Instead of shipping a half-baked deck or waiting two weeks for a full research cycle, you schedule three focused customer calls with a very specific set of questions designed to fill those two gaps and nothing else.
That’s tactical curiosity. You identified exactly what was missing and went after exactly that.
In the wild: A Slack thread pops up, sprint delay, the team is stuck. The tactically curious PdM doesn’t panic or escalate. They ask the tech lead: “If we hardcode the initial values instead of building the dynamic config UI, can we still ship the core flow by Friday?” Their curiosity is purely operational — what’s the exact scope trade-off that unblocks the team today?
Protege Tip: Tactical curiosity is what separates PdMs who “need more research” from PdMs who move. You don’t need to know everything. You need to know exactly what you don’t know, and go get that one thing.
2. Confidently Curious — “Can we pause and zoom out?”
This is the hardest mode. It requires something most PdMs don’t develop until they’ve been burned a few times: the willingness to slow a room down.
Context: Imagine you’re a PdM on a platform team at a large enterprise. You’re in a planning meeting with 10 stakeholders. Engineering, design, sales, and your VP are all in the room. The conversation is moving fast. Everyone’s converging on a direction. The energy feels good.
But something isn’t sitting right with you. The proposed solution seems to be trying to solve three different problems at once 1) onboarding friction, 2). API reliability, and 3) reporting gaps. Nobody has said out loud which one matters most. Nobody has asked if all three need to be solved in this push, or if trying to do so is exactly how this initiative will collapse under its own weight.
Confidently curious means raising your hand and saying: “Can we pause and zoom out for a moment? I want to make sure we understand the problem. It seems like this solution is trying to address several different issues, and maybe we need to learn more before we try to solve all of them at once.”
In the wild: A dense, highly technical architecture meeting. Half the room is talking about database migration strategies. The confidently curious PdM interrupts: “I’m losing the thread on how this migration impacts our end-user latency — can someone whiteboard the data flow for me?” They’re secure enough in their role to admit what they don’t understand. They ask the “dumb” question so they can genuinely grasp the trade-offs being made.
Protege Tip: Confident curiosity requires two things — psychological safety and self-trust. You can’t build it in a vacuum. Start small. Ask one clarifying question in the next meeting where you feel like the right thing to do is to stay quiet.
3. Competently Curious — “Show me the evidence.”
Competent curiosity is the disciplined practice of asking targeted, probing questions to uncover root problems without getting derailed by interesting but irrelevant tangents. It’s about separating signal from noise with an analytical approach.
Context: Imagine you’re a PdM at a B2B fintech company. Your Sales team pings you: “Big client wants a bulk export feature. This could be a six-figure deal.”
A less experienced PdM writes the feature request and drops it in the backlog. A competently curious PdM asks: “Can you link the Gong recording or the Zendesk ticket so I can hear the exact friction point the customer described?” They don’t take the idea at face value. They ground their curiosity in raw user evidence, hunting for the underlying use case rather than accepting a surface-level solution.
Maybe the client doesn’t need bulk export. Maybe they need a better way to reconcile data between two systems, and export is just the workaround they landed on. You won’t know unless you listen to the actual conversation or get a chance to ask follow up questions to the customer (or the sales team).
In the wild: The competently curious PdM balances open-minded exploration with analytical rigor. Every “why” they ask drives toward an actionable, evidence-based decision that aligns with overall product strategy.
Protege Tip: Competent curiosity is what prevents “discovery” from becoming an infinite loop. You’re not exploring for the sake of exploring. You’re building a case. Every question should get you closer to a decision, not further from one.
Curiosity Compounds
Here’s what happens when the bare minimum curiosity is present at each stage — from idea to build to live.
The next stage starts cleaner. Better inputs. Fewer arguments. Less rework. The team spends less time debating what they should have figured out two months ago and more time doing the work that actually matters.
The flywheel looks like this:
Curiosity → Clarity → Confidence → Speed.
Speed comes last. Always. Most teams try to go fast by skipping curiosity. They end up slow and perpetually rebuilding on assumptions no one pressure-tested.
This is the backbone of the E3 Product Mindset that we teach and coach at Product Protege — Envision, Empower, Elevate. At each phase, there’s a bare minimum curiosity threshold. Cross it, and the flywheel accelerates. Skip it, and you’re just spinning.
Protege Tip: If your team is constantly in “firefighting mode,” the fire probably started two stages ago, when someone skipped the bare minimum questions. Trace it back. You’ll almost always find a curiosity gap at the root.
The next time you’re in a meeting and a confident stakeholder walks in with a solution, notice what happens in your body. The instinct to nod. The pull to be helpful. The voice that says just write the ticket.
That’s the moment.
Here is the thing, the stakeholder isn’t wrong, the solution may not be half bad, but the bare minimum hasn’t been met yet — and you’re the person in the room whose job it is to notice.
The best product managers I’ve worked with all share one thing: they refuse to move forward without the right questions. They’re simpler than you think.
The E3 Product Mindset and the frameworks behind bare minimum curiosity are explored in depth in the Product Protege Guide, available on Amazon. If this resonated, it’s just the surface.
— Jason, Founder & CEO, Product Protege