Leadership
Leadership
Leadership
What Strong Product Teams Do Before They Start Designing
Product teams can avoid building the wrong thing by getting aligned before the start pushing pixels.
Brandon Green
Jan 12, 2026
Anyone who has worked on products long enough has seen it happen. You show work you're proud of. Within minutes, stakeholders rip it apart. They already had something else in mind before you started. This makes the hours of discovery feel wasted. The cycles of building and testing with users start to feel pointless. Someone has to be blamed for the 'wrong direction' of the work that the three teams (product management, design, and engineering) did together.
The team gets together after the meeting and asks each other “what just happened?” Did the PM not get the right requirements? Did the designer not ask the right questions? Maybe the engineering team cut corners? Nothing cuts a team deeper than an overreaction from stakeholders who don’t bother to get curious before assuming they know best. Teams may be able to handle this type of rejection and confusion once or twice but after a few times of feeling like they are missing the mark and being told to “just do what you’re told” they stop innovating and start focusing less on outcomes and more on output.
The solution starts long before the team even has a kick off meeting. It starts with understanding what the organization is actually trying to accomplish, what users actually need, and why both of those things matter.
Anyone who has worked on products long enough has seen it happen. You show work you're proud of. Within minutes, stakeholders rip it apart. They already had something else in mind before you started. This makes the hours of discovery feel wasted. The cycles of building and testing with users start to feel pointless. Someone has to be blamed for the 'wrong direction' of the work that the three teams (product management, design, and engineering) did together.
The team gets together after the meeting and asks each other “what just happened?” Did the PM not get the right requirements? Did the designer not ask the right questions? Maybe the engineering team cut corners? Nothing cuts a team deeper than an overreaction from stakeholders who don’t bother to get curious before assuming they know best. Teams may be able to handle this type of rejection and confusion once or twice but after a few times of feeling like they are missing the mark and being told to “just do what you’re told” they stop innovating and start focusing less on outcomes and more on output.
The solution starts long before the team even has a kick off meeting. It starts with understanding what the organization is actually trying to accomplish, what users actually need, and why both of those things matter.
Agreement Across the Board
Every company has their own ways of working, their own frameworks, processes, hierarchy, etc. Sometimes those feel like they change on a quarterly basis too. But strong teams start with focus on who exactly has the problem, how painful it is, and what they're doing today instead. They speak openly and honestly with each other. They aren’t worried about titles, positions, “staying in their lanes,” or political standing.
For example, let’s say your company has noticed in their data analysis that potential customers are bouncing out of the signup funnel before it is completed at an increasing rate. Sales feels it’s because of the sign up flow, Operations feels like the prices are too high, Product leadership feels that legal restrictions are scaring people off, and Executives believe that not being at feature parity with competitors is causing loss of market share. How do you determine who is right? How do you please everyone? Where do you start?
The instinct is to pick a lane. Sales says it's the flow. Operations says pricing. Product leadership says legal restrictions. Execs say feature gaps. Someone has to be right…right?
But that's the wrong starting point. The better question is to understand “what do we actually know about why people are leaving?” Not what you assume. Not what each department's perspective suggests. Really understanding what does the data show and what have users told us?
Strong teams pause here. They resist the pressure to jump to solutions. They get aligned on the problem first.
That means asking specific questions. Who is bouncing? New users or returning ones? At what step? Is the pattern consistent across segments or concentrated somewhere specific? Has anyone talked to a user who left to understand what happened from their perspective?
This is what product research is all about and it’s not a single person’s role. It's the fastest way to avoid building the wrong thing by the entire team.
If Sales is right about the flow, you're looking at a design problem. If Ops is right about pricing, you're looking at a business model conversation. If Product leadership is right about legal language, you're looking at content and policy. If Execs are right about feature gaps, you're looking at a roadmap decision. Those are four completely different kinds of work. Starting without alignment means someone is going to spend months on something that never had a chance.
Agreement Across the Board
Every company has their own ways of working, their own frameworks, processes, hierarchy, etc. Sometimes those feel like they change on a quarterly basis too. But strong teams start with focus on who exactly has the problem, how painful it is, and what they're doing today instead. They speak openly and honestly with each other. They aren’t worried about titles, positions, “staying in their lanes,” or political standing.
For example, let’s say your company has noticed in their data analysis that potential customers are bouncing out of the signup funnel before it is completed at an increasing rate. Sales feels it’s because of the sign up flow, Operations feels like the prices are too high, Product leadership feels that legal restrictions are scaring people off, and Executives believe that not being at feature parity with competitors is causing loss of market share. How do you determine who is right? How do you please everyone? Where do you start?
The instinct is to pick a lane. Sales says it's the flow. Operations says pricing. Product leadership says legal restrictions. Execs say feature gaps. Someone has to be right…right?
But that's the wrong starting point. The better question is to understand “what do we actually know about why people are leaving?” Not what you assume. Not what each department's perspective suggests. Really understanding what does the data show and what have users told us?
Strong teams pause here. They resist the pressure to jump to solutions. They get aligned on the problem first.
That means asking specific questions. Who is bouncing? New users or returning ones? At what step? Is the pattern consistent across segments or concentrated somewhere specific? Has anyone talked to a user who left to understand what happened from their perspective?
This is what product research is all about and it’s not a single person’s role. It's the fastest way to avoid building the wrong thing by the entire team.
If Sales is right about the flow, you're looking at a design problem. If Ops is right about pricing, you're looking at a business model conversation. If Product leadership is right about legal language, you're looking at content and policy. If Execs are right about feature gaps, you're looking at a roadmap decision. Those are four completely different kinds of work. Starting without alignment means someone is going to spend months on something that never had a chance.
What Does Success Look Like
This isn't about gathering metrics, or just talking to a few users and doing whatever they say. Reading between the lines, understanding “the need” beyond “the what” is a skill that talented product people have learned over the years. Often due to failures and realizing their assumptions were nothing more than personal opinions.
As the situation gets clearer and evidence starts to pile up, you have to do the hardest part: getting everyone on the same page. Using data (metrics, feedback, etc) to quickly and simply help others understand is key. This is where storytelling matters. You need to speak each team's language and show how their assumptions line up with what you found.
Your team’s goal is to come away with agreement on the problem, if your actions work, what really changes, what behaviors shift (either internal/external, or both), and what's the smallest version that actually tests the hypothesis? I’ve seen teams move faster and hit the mark more times when this agreement is in place before the work starts. I’ve gone as far as documenting this agreement and asked each stakeholder to sign off on it before we’d even start. This helps cut down the blame games that can happen if things don’t completely work out as planned.
What Does Success Look Like
This isn't about gathering metrics, or just talking to a few users and doing whatever they say. Reading between the lines, understanding “the need” beyond “the what” is a skill that talented product people have learned over the years. Often due to failures and realizing their assumptions were nothing more than personal opinions.
As the situation gets clearer and evidence starts to pile up, you have to do the hardest part: getting everyone on the same page. Using data (metrics, feedback, etc) to quickly and simply help others understand is key. This is where storytelling matters. You need to speak each team's language and show how their assumptions line up with what you found.
Your team’s goal is to come away with agreement on the problem, if your actions work, what really changes, what behaviors shift (either internal/external, or both), and what's the smallest version that actually tests the hypothesis? I’ve seen teams move faster and hit the mark more times when this agreement is in place before the work starts. I’ve gone as far as documenting this agreement and asked each stakeholder to sign off on it before we’d even start. This helps cut down the blame games that can happen if things don’t completely work out as planned.
Limit the Committee Meetings
It's tempting to invite everyone so nobody can claim they weren't involved. This is a political move, or maybe you are just covering your ass. Either way, the more people in the room, the more opinions you'll get on what your findings actually mean. Strong teams know who needs to be in the room to avoid the “leadership review” ambush.
Deciding who should be in the room depends on your findings and your ask. Some people will even ask you to include them in the meetings. FOMO is usually a factor here and you need to be able to say “no” when it’s appropriate. A few factors to consider when setting up the meeting:
Who has veto power?
Who will be asked for their opinion later whether they're in the room or not?
Who has context that could change the direction?
What is important is having people from your own team there who can speak intelligently to questions asked that are in their areas of expertise. One option that I have taken in a situation when I felt that someone may be difficult in a specific meeting is to do a one-on-one with them beforehand to go over the findings, hear out their feedback and opinions, and let them know you'll be presenting these findings to the wider group. This allows them to not feel blindsided, have time to process, and in many meetings I have even had these stakeholders chime in to support our findings. I may even add in that I talked with them before and add in something they had told me to the larger group. It turns potential blockers into allies before the room gets crowded.
Limit the Committee Meetings
It's tempting to invite everyone so nobody can claim they weren't involved. This is a political move, or maybe you are just covering your ass. Either way, the more people in the room, the more opinions you'll get on what your findings actually mean. Strong teams know who needs to be in the room to avoid the “leadership review” ambush.
Deciding who should be in the room depends on your findings and your ask. Some people will even ask you to include them in the meetings. FOMO is usually a factor here and you need to be able to say “no” when it’s appropriate. A few factors to consider when setting up the meeting:
Who has veto power?
Who will be asked for their opinion later whether they're in the room or not?
Who has context that could change the direction?
What is important is having people from your own team there who can speak intelligently to questions asked that are in their areas of expertise. One option that I have taken in a situation when I felt that someone may be difficult in a specific meeting is to do a one-on-one with them beforehand to go over the findings, hear out their feedback and opinions, and let them know you'll be presenting these findings to the wider group. This allows them to not feel blindsided, have time to process, and in many meetings I have even had these stakeholders chime in to support our findings. I may even add in that I talked with them before and add in something they had told me to the larger group. It turns potential blockers into allies before the room gets crowded.
Document the Decisions
Business cases. PRDs that clearly define success. User stories that aren't vague. Decision logs that hold everyone accountable. These are how you protect the work. You need a shared record of what was decided, by whom, and why. Strong teams build this so when someone new joins or leadership asks questions six months later, you don’t have to reconstruct your reasoning from old emails or messages. There are a lot of moving parts in a company and it is easy to “misremember” the specifics even a month after they were decided. Referring to your decision log in review meetings, product demos, and go-to-market meetings can mean the difference between your team being viewed as an asset or a detractor.
Many designers and engineers have the thought process that documentation is something that the Product Manager or Product Owner should be responsible for. This is an incorrect understanding. Designers should be reading and adding their insights to all documents based on their knowledge and findings. Engineers should be reviewing timelines, tech stacks, and overall promises. The team as a whole should be understanding and agreeing on the target outcomes that they are all working so hard to hit. Cutting corners almost always leads to confusion, pointing of fingers, and it really could be the difference between you having a job when the company is making hard decisions.
Design Can’t Fix a Misaligned Team
If your work keeps getting torn apart in reviews, the failure didn’t happen during design. It happened before anyone agreed on what problem they were solving.
Design gets blamed because it’s the last thing people see. Research gets ignored because it “complicates” decisions. Roadmaps change because nobody ever committed to what success meant. By the time feedback shows up, the direction was already determined and opinions were already set.
Companies like to believe these breakdowns are about execution. They usually aren’t. They’re about avoiding alignment before a team is ever asked to execute. About leaders making informed decisions, and teams providing the information needed to do so.
Find the data, gather the feedback, inform the stakeholders and document the decisions. This isn’t a process that needs to take multiple weeks or months. You do need the team focused and aligned though, so communication is key.
You won’t win them all, but the team will get stronger and more comfortable with the work. That will increase the trust the company has in you and will start to equal more wins than losses.
Document the Decisions
Business cases. PRDs that clearly define success. User stories that aren't vague. Decision logs that hold everyone accountable. These are how you protect the work. You need a shared record of what was decided, by whom, and why. Strong teams build this so when someone new joins or leadership asks questions six months later, you don’t have to reconstruct your reasoning from old emails or messages. There are a lot of moving parts in a company and it is easy to “misremember” the specifics even a month after they were decided. Referring to your decision log in review meetings, product demos, and go-to-market meetings can mean the difference between your team being viewed as an asset or a detractor.
Many designers and engineers have the thought process that documentation is something that the Product Manager or Product Owner should be responsible for. This is an incorrect understanding. Designers should be reading and adding their insights to all documents based on their knowledge and findings. Engineers should be reviewing timelines, tech stacks, and overall promises. The team as a whole should be understanding and agreeing on the target outcomes that they are all working so hard to hit. Cutting corners almost always leads to confusion, pointing of fingers, and it really could be the difference between you having a job when the company is making hard decisions.
Design Can’t Fix a Misaligned Team
If your work keeps getting torn apart in reviews, the failure didn’t happen during design. It happened before anyone agreed on what problem they were solving.
Design gets blamed because it’s the last thing people see. Research gets ignored because it “complicates” decisions. Roadmaps change because nobody ever committed to what success meant. By the time feedback shows up, the direction was already determined and opinions were already set.
Companies like to believe these breakdowns are about execution. They usually aren’t. They’re about avoiding alignment before a team is ever asked to execute. About leaders making informed decisions, and teams providing the information needed to do so.
Find the data, gather the feedback, inform the stakeholders and document the decisions. This isn’t a process that needs to take multiple weeks or months. You do need the team focused and aligned though, so communication is key.
You won’t win them all, but the team will get stronger and more comfortable with the work. That will increase the trust the company has in you and will start to equal more wins than losses.
MORE INSIGHTS
Leadership
Jan 19, 2026
Executive feels the pressure and their instinct is to take control. Centralize decisions. Reduce the variables. Run everything through themselves.
The Cost of Certainty in Uncertain Times
Leadership
Jan 5, 2026
Designers and researchers often don't feel heard or seen in group settings. This hurts morale and culture when it goes on and on.
What I Tell Designers Who Feel Invisible