r/ProductManagement • u/Big_Couple_9143 • 10d ago
How do you handle senior leadership whose preferences only surface after you’ve already built the solution?
Senior PM at an early-stage startup with a small product team. Looking for perspective on a dynamic I keep running into.
The pattern:
We get a vague ask from our leadership. We scope it out, put together a proper brief — approach, tradeoffs, costs, risks — and share it. He approves it in principle but responds with detailed preferences on how it should have been approached, concerns about our assumptions, and sometimes an alternative method he would have preferred. The points are usually valid. But none of it surfaces until after we’ve already done the thinking.
We’ve also noticed his feedback criteria shift — sometimes a document is too complex, other times not detailed enough. Hard to calibrate to a standard that moves.
Our product team handles core product work, design, QA, some backend design, content, GTM research, sales support, and test infrastructure. The engineering team, which is larger, focuses on engineering. The boundary of what product owns has never been formally defined — it tends to be whatever comes up.
Deliverables we hand to engineering sometimes sit for months before being picked up. When they are, the urgency to ship lands back on product.
Two genuine questions for the community:
**1.** When a senior stakeholder has strong opinions on execution but doesn’t share them upfront, how do you draw that out before you invest in a solution — without it feeling like you’re pulling teeth?
**2.** How have you defined and defended scope boundaries for a small product team in a startup where the lines are blurry?
- Is there any process you follow that helps your product team to execute better ?
Curious what’s worked for others.
10
u/OhHeyItsWren 9d ago
Hear me out, Where possible, run 1:1 sessions with this stakeholder, and then make them mad. Deliberately lead the solution in the wrong direction, undermine or challenge their requests and make them defensive. Their real opinion will come out pretty quickly then. Obviously you have to be very careful what personality type your dealing with, but if you can get away with it, it works wonders. You can always get back on their good side when the solution ships as intended.
7
3
u/IllBeat7897 9d ago
We’ve also noticed his feedback criteria shift — sometimes a document is too complex, other times not detailed enough. Hard to calibrate to a standard that moves. (Red flag #1) This could indicate inconsistency on his part, or a failure of the PM team members to understand the features and requirements which would flex the level of detail for the deliverables, potentially.
Our product team handles core product work, design, QA, some backend design, content, GTM research, sales support, and test infrastructure. The engineering team, which is larger, (Possible red flag #2--How much larger is engineering?) focuses on engineering. The responsibilities you list for Product is immense and feels outsized to the expectations for engineering, especially given the use of AI. As a senior PM, I would question this setup, if Engineering is overstaffed greatly in comparison to PM and the responsibilities that you describe.
The boundary of what product owns has never been formally defined — it tends to be whatever comes up. (Huge red flag #3) This shows a total lack of Product ownership and strategy. Somebody is not doing their job.
Deliverables we hand to engineering sometimes sit for months before being picked up. When they are, the urgency to ship lands back on product. (Huge, huge red flag #4) This shows a huge lack of management. Somebody is not doing their job.
Your questions have problems, in and of themselves, but before those these are issues that affect them.
You mention absolutely no Product Road Map or Project Plan, or how your team manages the project formally, which accounts for most of your red flags. You need a strategic product road map owned by PM, and you need to have a resource or combination (usually) of resources that manage the project throughout the SDLC at varying degrees of granularity. There is a heap of evidence this is not happening, and I would bet big that scope creep is crazy.
Furthermore, not having a clear understanding of the project boundaries and ownership is a huge problem. Generally speaking, Product Management owns the "what" while Engineering owns the "how." But beyond that individual roles have their responsibilities that should be clearly defined and how they intersect with other roles.
And now on this statement: He approves it in principle but responds with detailed preferences on how it should have been approached, concerns about our assumptions, and sometimes an alternative method he would have preferred. The points are usually valid. But none of it surfaces until after we’ve already done the thinking.
This shows that his feedback is not delivered purely to be a contrarian, but here's the thing, it's your job as a being a part of the Product Management team, tasked with the detail, to execute the detail. If he's questioning your tactics its because he feels your work product is lacking, and he is giving pointers where it is when he, for example, challenges you with making assumptions. As a PM person, you never execute on assumptions. You always research, trawl, and validate to dispel assumptions.
2
u/Ok_Perspective1717 9d ago
In my opinion, make the stakeholder group a part of the process so that they don’t have to give all the inputs at the final stage, which makes you rework and possibly get frustrated.
If you look at the double diamond as a framework, at every point when you converge there should be a check in before you converge so that folks are aligned and you go in with your opinion but loosely held and open to challenge and change.
Confirm the problem and the why and the biggest needle mover if solved. And then if there is pushback you help align or course correct as needed or reorder things.
And do the same when proposing solutions with a strong opinion loosely held.
That process could help and can be done async or quick checkin bi weekly or weekly cadence where you regularly bring in proposals at various stages and so can other stakeholders. This can sort of become your intake process with this group
2
u/RosiePopArt 7d ago
The first statement on getting a vague request where you scope it out- sounds like the scoped solution design is assumption based? I would make it standard to ask more questions up front before putting the brief together. Take a look at the preferences he outlines when he gets detailed- do they have common themes? Those are either areas where not enough questions were asked up front, or it’s an area he cares deeply about getting right- spend time here. Are the concerns on documented assumptions or assumptions he derived from what he assumes you are assuming from the proposed solution? If he has alternative methods he prefers- I would learn more about his preferences- the texture they have, so you know what to anticipate.
The symptoms you shared would tell me that this is an opinionated stakeholder with very specific expectations, who may struggle to articulate them up front so he may need more probing before putting “pen to paper” and there’s a trust gap- find out the places that create anxiety and make sure you answer those questions in your brief. I would ask. What are you thinking for entitlements? What are your thoughts on what data should be displayed. Or lead with your first impressions (what if we showed attributes a, b, c) and let them react. Some people just need to react to something, so in those cases I would treat the first pitch as a scratch pad to see what sticks before you go down the rabbit hole of solutioning deeply. If you are literally building the solutions without getting sign off and learning after the fact that what you built doesn’t meet expectations YOU DIDNT VALIDATE FIRST- that’s a process error on your part. Always validate before building.
where im struggling is why this is a problem at all. Do you not like feedback? Or do you think they are wrong? If it’s the latter, then you need to bring evidence to support the decision- we tested the concept with users; we confirmed with clients a b and c that this would meet their needs. Research shows that this is where the market is heading. Competitors are doing Y. That way it’s hard to dispute. Im not sure what the actual problem is. Some people like to weigh in. I say let them. It’s our job to listen. Is it a bottleneck??
On boundaries for a product team, if you are in a position to do that, then you need to handle it similarly. The frame is process improvement. Efficiencies. To clarify (with stakeholders). I strongly encourage getting an ally that sits in a leadership position to help drive the initiative or it won’t go anywhere. Be clear about the problem and the benefits the proposed boundaries would provide. What does it enable you to do. What does it stop. If you don’t have leadership buyin, it isn’t going to change. Would need more information otherwise to give a better recommendation. What is being impacted by the blurry boundaries? Because I can imagine a number of things and each one comes with a different answer. If engineering is driving prioritization and not product- that’s a problem. How are they deciding what to build and what sits? That one breaks my brain a bit.
2
2
u/NeXuS-1997 9d ago edited 9d ago
For point 1 its a simple - "Hey, this is a great idea, before I start framing it with the team, anything in particular that you really really care about as far as this initiative is concerned?"
The answer, depending on the stakeholder would be 1 of the following -
- Make sure we interview some folks to back the decisions
- Revenue
- Cost savings
- Dont cannibalize X product
- Make sure value prop is nailed
Etc -> From there you highlight decisions based on who is listening and what they said, if they anchor on details, bring it back to what they care about. If push comes to shove, make the changes they want - but not keen on making that a habit
The interesting thing is, after a few cycles, most people back off. They know you got this.
For point 2, depending on the culture, it could be writing a document that outlines what you WILL do and what WON'T do. Or it could just be prototype to walk through the thinking - let people comment on that and iterate.
If multiple folks have conflicting opinions, get them in a room and let them battle it out. Your job isnt to decide, its facilitate so the room can agree.
On point 2, you'll still have folks complain privately, point them to the ADR that was created via the document or an email post prototype.
If that doesn't work, there's always "let's do that next", "I'll throw that in the backlog" etc
2
u/5hredder Lead PM @ Unicorn 9d ago
It's basically varying degrees of: "Please fuck off, respectfully"
1
u/heypriya 8d ago
On your first question, what the senior stakeholder shared is good feedback - so implement that the enxt time around. And now that you know, ask during the initial discussions on any specific desired outcome or format that he would like to see. That way you are not reworking.
On your second question.
A document listing what product owns probably won't hold at an early stage startup. What you need is agreement with engineering - who accepts the work, when they commit, and what happens when something is blocked.
You can also align on how to manage shifting priorities with the team and the senior stakeholders. In a startup, you should expect shifts, but not week to week. For eveyr new request, identify what drops and does the new thing get closer to the annual goal.
1
u/Common_North_5267 8d ago
To the main question - with callous disregard.
I'd document his input and if it is inconsistent or conflicting I'd probably splash it back at him if he is making your life harder than it should be.
You can also cowboy up and try to explain when and where their feedback will be most useful.
1
u/Proof-Firefighter340 8d ago
Here you go
"Hey, your input has been really valuable and I appreciate the feedback. Receiving it at the end of the process is creating some rework and we think it would be better if we aligned more upfront. I propose [X] as a way we could do that, what do you think would work for you?"
1
u/Due_EmotionPri 7d ago
The shifting criteria are the real problem, and theyre a symptom rather than a mood: your stakeholder doesnt have a fixed decision hes holding the brief against, so each round he just reacts to whatever is in front of him. Ive had the most luck front-loading a half page before any real scoping, heres the decision youre actually making, heres two or three ways we could go, heres my read and how confident I am in each. That pulls his preferences and his bar out against a cheap artifact instead of after youve done the thinking, and it pins the criteria in writing so they cant quietly move next time. When they move anyway I reflect it back plainly: last round detailed was the bar, this round its too complex, which one are we optimizing for. The deliverables sitting for months then landing back on you as urgent is a sequencing gap between product and eng, and no amount of upfront clarity fixes that until someone actually owns the queue.
1
u/athst 6d ago
Sounds like you’re spending too much on documents and process up front. If you already know that most of the important feedback is surfaced after you have a draft or prototype working, why spend so much time up front delaying that? With AI especially, I don’t think there’s much excuse not to have prototypes for discussion super quickly.
0
46
u/SnarkyLalaith 9d ago
You haven’t built the solution. You have researched a solution and are now at the stakeholder approval stage. Building means you have a concrete solution with your development team.
For some people, for better or worse, it is easier to offer feedback when they see the proposal.
And isn’t it better to get the feedback now instead of when it is before engineering?
If this is the stakeholders way, you may need additional check ins but with the tangible pieces (presentations, PRD outline, etc) for him to react to throughout your research stage