The Tech Leader's Guide to Managing Up, Down, and Across
How do you get multiple stakeholders to agree on anything in a business?
It's one of the most challenging problems technical leaders face today. When you're trying to establish product direction, someone has to set a path and say, "go this way."
But that's easier said than done.
In large companies, you can't get everyone to agree, and nobody wants to take risks. In small companies, everyone has opinions, and you need to move quickly to survive.
I recently spoke with Stephen Pollack on Product Driven about this exact challenge and how AI is changing product management. Stephen brings five decades of experience building successful technology products and has a powerful perspective on navigating these complex stakeholder dynamics.
Stephen's experience is unparalleled. As the founder and CEO of PlateSpin, he grew the company from $0 to $40M in five years before a strategic acquisition by Novell for $210M. His company was Canada's 2nd fastest growing technology over a 5-year period and 12th in North America.
One insight from our conversation stood out clearly: most businesses don't have good "airbags" to protect them from crashing into walls when product direction goes awry.
Stephen identified a core problem: "Most businesses don't often afford developers the luxury of taking time to create a plan because they think it's a waste of time or believe they'll 'just figure it out as we go.' Both approaches are wrong."
The Stakeholder Alignment Problem
One insight from our conversation stood out clearly: most businesses don't have good "airbags" to protect them from crashing into walls when product direction goes awry.
What do I mean by "airbags"?
Just as cars have safety systems to protect passengers during a collision, businesses need systems and processes to absorb the impact when product decisions inevitably hit obstacles. Without these protective mechanisms, one bad decision can cascade into catastrophic failures that derail entire product lines or companies.
These "business airbags" come in many forms: strong documentation practices that preserve institutional knowledge, decision frameworks that guide tough choices, regular review cycles that catch problems early, and contingency planning that anticipates potential failure points.
Most companies operate without these safety systems. They dive into product development with minimal planning, thinking they'll figure it out as they go. This lack of protection means when they hit an obstacle – a major technical limitation, market shift, or stakeholder conflict – there's nothing to cushion the impact.
He identified a core problem: "Most businesses don't often afford developers the luxury of taking time to create a plan because they think it's a waste of time or believe they'll 'just figure it out as we go.' Both approaches are wrong."
This shortcuts the crucial planning phase where potential risks can be identified and mitigated. When teams skip establishing a clear vision and framework at the outset, it creates a chain reaction of problems:
Stakeholders advocate for different directions without a common reference point
Developers make technical decisions without understanding the bigger picture
The product lacks coherence as it evolves through competing priorities
Technical debt accumulates as short-term fixes replace strategic solutions
Instead, the most successful product teams Stephen has worked with build their airbags into the process from day one. They develop robust frameworks for decision-making, create clear documentation of the vision and rationale, and establish review mechanisms to catch misalignments early.
The Three-Direction Challenge
As a technical leader, you're constantly pulled in three directions:
1. Managing Up: Executives want predictability, ROI, and market differentiation. They're often focused on the big picture but may not understand the technical complexity involved.
2. Managing Down: Development teams need clear direction, context for their work, and protection from constant priority shifts. They want to build great products but can get lost in the details without the bigger picture.
3. Managing Across: Other departments (sales, marketing, customer success) all have their own priorities and perspectives on what should be built next. They're directly facing customers and have valid input that needs consideration.
As Stephen put it: "Key stakeholders, if you view all the different role leaders as the stakeholders, have a lot of challenges communicating with each other. The salesperson and the marketing person agree and disagree about different things."
Why Consensus Is the Enemy of Progress
One of the most powerful insights from our conversation was that seeking consensus is often the wrong approach.
If you're asking for input, you have to be ready to take input.
If you're not ready to take input, all you're creating is disappointment.
When leaders throw decisions completely to the group without any framework, all the interpersonal issues come into play. This leads to analysis paralysis.
Even the best leaders sometimes don't want to be caught saying, "That's all really great, but we're just going to do it this way." They fear alienating team members who may then execute with less passion.
Thanks for reading Product Driven Newsletter! Subscribe for free to receive new posts every Tuesday and Thursday.
The North Star Approach
Instead of seeking consensus, Stephen advocates for what I'd call a "North Star" approach:
Paint the Path First
As a technical leader, coming to stakeholder meetings with a blank slate is a recipe for endless debate. Instead, Stephen recommends that leaders do the hard work of establishing a clear direction before opening the floor.
What this looks like in practice:
Draft a concise vision statement that defines what success looks like for the product in 1-2 years
Identify clear boundaries – what's in scope and what's explicitly out of scope
Define guiding principles that will inform decision-making (e.g., "We prioritize user experience over feature breadth" or "We optimize for enterprise clients over SMB")
Create a high-level roadmap showing key milestones and dependencies
Prepare market and competitive analysis showing why this direction makes strategic sense
This isn't about dictating every detail. It's about providing enough structure that discussions can be productive rather than circular. You're saying, "Here's the mountain we're climbing; let's talk about the best path to the summit" – not "Should we climb a mountain, swim across an ocean, or build a spaceship?"
Refine Through Collaboration
Once you've established the direction, invite your team to collaborate on refining the vision and identifying potential pitfalls. This is where the real value of diverse perspectives shines.
What this looks like in practice:
Hold structured brainstorming sessions where you present the vision and explicitly ask for ways to strengthen it
Create dedicated channels for ongoing feedback (Slack channels, regular office hours, etc.)
Conduct small group discussions with key representatives from different departments
Use "premortem" exercises where teams imagine the product has failed and identify why
Request specific input rather than general opinions: "How can we improve the user onboarding flow?" versus "What do you think about the product?"
Stephen emphasized that this approach actually increases buy-in because stakeholders feel heard and can directly influence how the vision is executed. Their input matters, but it's channeled productively.
At a large enterprise software company Stephen consulted with, this meant bringing marketing, sales, and development leads together after the product direction was established. The focus wasn't "Should we build this?" but rather "How do we ensure this succeeds in the market?" This shift led to valuable insights on positioning, customer concerns, and technical considerations that strengthened the original vision.
Focus on Framework Discussions
Even with a clear direction and collaborative refinement, debates will inevitably arise. The key is ensuring these discussions happen within the established framework rather than constantly revisiting fundamental decisions.
What this looks like in practice:
Create a decision log that documents what's already been decided and why
Reference the guiding principles when discussions start to drift off course
Establish a formal change management process for revisiting fundamental decisions
Use "parking lots" for capturing ideas that are valid but outside current scope
Time-box discussions to prevent circular debates
Define clear owners for decisions within their domain of expertise
Stephen noted that one of the biggest time-wasters in product development is rehashing the same discussions repeatedly. "You have to have a stake in the ground in order to have a way to do change management," he explained.
In meetings, this means actively redirecting conversations when they start to question the established direction. For example, if someone asks, "Should we be building a desktop app instead of a web app?" (after that decision was made), you respond: "We agreed on building a web app because of X, Y, Z reasons. Let's focus our discussion on how to make this web app exceptional."
At PlateSpin, Stephen's team implemented regular "context reminder" sessions where they revisited why certain strategic decisions were made. This helped new team members understand the reasoning and prevented the team from drifting away from their focus as they grew.
The Balance of Input and Decision
One challenge I've experienced as a CEO is the delicate balance between gathering input and making decisions. You don't want to tell everyone what to do, but you need to drive direction.
In large companies, stakeholders often avoid decisions out of fear of risk. In startups, they make too many decisions without giving any enough time to play out.
Stephen shared a fascinating example from his experience at PlateSpin:
"When PlateSpin came together, we had a very balanced table at that leadership event. We all functioned really well together and understood how to make trade-offs. We could communicate, partly because as its leader, I was very technical."
PlateSpin started out of bankruptcy with a product that was "trying to do one thing with 100 tentacles." Their solution? They picked one tentacle, did it really well, became globally dominant with it, and then expanded.
The key was focus: "The whole team understood the one thing we were doing. So we were able to align and orient around it quite successfully."
Practical Strategies for Technical Leaders
Based on my conversation with Stephen and my own experience building technology companies, here are practical strategies for technical leaders caught in the middle:
1. Create a Decision-Making Framework
Don't start discussions without a framework. Stephen suggests: "If I come into a scenario not having any kind of framework for making a decision, then I'm just throwing it over to the group. And that's really hard."
Instead, establish parameters and principles for decisions before opening the floor. This gives people guardrails for their input.
2. Beware the Tactical Implementation Trap
Many teams deliver a tactical implementation of their original vision because they get distracted by too many ideas or talk to customers too early without a solid foundation.
Stephen's advice: "Focus is important. I've been involved in a couple of businesses that needed to be resurrected, and usually the problem is lack of focus, too many ideas at the beginning."
3. Build a "Plan for Success"
Many companies have "inherently within their plan, a lack of planning for success," according to Stephen. They say things like "We'll worry about a lot of users when we get them" or "We'll worry about performance when we have that problem."
This reactive approach means you can't solve these problems well when they arrive. Build a plan that anticipates success and prepares for it.
4. Balance Customer-Driven vs. Innovation-Driven Development
One company Stephen worked with was 90% customer-driven, responding primarily to top tickets. While they addressed immediate needs, they never advanced their product's differentiation, allowing competitors to catch up.
His recommendation: Determine the right balance (like 40% customer-focused, 60% innovation) and use this framework to make decisions about what to build next.
5. Create Shared Understanding
The most successful product teams have what Stephen calls a "stake in the ground." Teams can revolve around a stake, but they can't revolve around nothing.
"You have to have a stake in the ground in order to have a way to do change management," he explained. Without this shared understanding, teams waste time revisiting the same decisions repeatedly.
How AI Is Changing the Game
No conversation about product management would be complete without discussing AI's impact.
Stephen views AI as a team member with specific capabilities. "It's like having Stephen Pollack in all your meetings. He can be available 24 hours a day. He'll answer whatever question you ask."
The key difference? AI won't go further than you ask it, while a good advisor would proactively identify gaps.
For product managers, AI offers tremendous value in synthesizing inputs to produce outputs that help make final decisions. Stephen suggests using AI to help balance priorities:
"If you go to AI and say, 'My goal is 40% of my time on customer-focused issues, here's the current ticket log, and 60% on innovation, here's what our product currently does, here's my innovation statement, how would you recommend we implement the balance?' You'd get an output you can look at and make decisions around."
The Takeaway: Strong Direction, Collaborative Refinement
The job of a technical leader isn't to build consensus. It's to provide a strong direction while creating space for collaborative refinement.
You're not just a messenger between executives, developers, and other departments—you're the linchpin that makes product direction possible.
As Stephen summarized: "You need to be responsible for at least in general saying here's the North Star... and then work with the team to just navigate the path through the forest to get to the other end."
By providing that clear North Star while allowing input within a structured framework, you can move your product forward without getting stuck in endless debates or making too many directional changes.
This is how successful technical leaders manage to navigate the complex terrain of stakeholder management—up, down, and across.
