guest blogger product management

Road to Product Consensus

Guest Post by: Andraž Zvonar (Mentee, Session 11, The Product Mentor) [Paired with Mentor, Dimitris Sotiriou]

How I learned that aligning 20 people is easier than arguing with the CEO


Have you ever been in a situation where you needed to execute fast, but people you depended on just weren’t cooperating — which drove you to absolute frustration? I get it, it’s a high stress, high stakes situation and you just need to get things done, but it just ain’t moving forward. What you feel is of the utmost priority is just another idea to them. Maybe a backlog item to be prioritised.

Move fast, but go together

While startups need to move fast, getting everyone on board with the decisions that are being made is crucial to actually execute fast. And not just that, this goes way deeper than just acquainting your team with decisions that were already made.

In a perfect world where everyone instantly gets it and can agree, there is no need for team alignment, you just put a few people together and it’s a done deal. The team will execute the plan and results will be exactly what was envisioned.

Harness the power of collaboration to get ideas that stick

Back to the real world though. Product teams are a multidisciplinary unit of people, usually none of the members being a direct report to one another (other than the team lead). Each person brings their unique mental model and knowledge into the mix. This knowledge and thinking is a resource that needs to be put to use in order to generate diverse and innovative ideas, while it can certainly make it hard for a team to agree on all points.

So, why is team alignment even important, you might ask. Why not just use the team to generate ideas, pick the best ones yourself and deliver the spec to the team to develop it?

Well for one if your developers don’t agree with the direction they may simply refuse to make it. But in a more likely, and worse, scenario they’ll go along with it, but not committing fully. Your team will make minimum effort to get the job done, and you will be left with a mediocre product if you even get one on time.

Include your team in the decision making process

Here’s what I propose: let your teammates take part ownership and feel accountable for making the product successful. It’s really simple, but takes some getting used to, to implement correctly.

Here’s how I did it: I was having trouble getting MVPs made, features released on time, developers telling me specifications were incomplete, etc.

I’ve stumbled into product areas I thought needed help to make the product successful. I took the initiative to research what could be done to improve them and progress the product. I made a few proposals, talked to a few people and presented to the CEO. He liked them but in the end turned down one after another. Too much product work, too many changes, that’s not gonna work… he would say. Anything I proposed, he would have a better argument against.

I couldn’t fathom why not, especially since these problems would then be addressed months later, with similar strategies as I proposed but driven by somebody else.

Luckily not everyone else was having this problem to the same degree. I tried to understand what others were doing differently to overcome this hurdle. First by just observing and then by talking. What I noticed is this: they all had other people supporting them. Everybody used their strengths to achieve this outcome, since there are multiple ways to get it done.

That was when I started doing product work more closely with my team, my team lead and the CTO. I knew I needed to introduce this new behaviour gradually and ease the team into cooperating. Especially because even though coworkers knew how to get alignment, they still called the shots themselves and not including their teams. I wanted to include others and make the decision making process collaborative. 

I wanted to show small results and keep them willing to build on that.

What I did at first was:

  • Post about product problems and ideas to the team board
  • Chat the team members up about what I’m working on
  • Mention product ideas at the sprint planning sessions
  • Present early ideas to the team lead

When I did these things I always asked for their thoughts on it.

After I got some engagement out of those three, I arranged with the team lead to have weekly meetings where I would first present the current product focus and general strategy and then discuss product objectives that needed to be solved by our team.

The goals of the meeting were to:

  • Align the team around a single idea or a solution
  • Make team members feel ownership and responsibility
  • Brainstorm unique and creative ideas

At least one day before the meeting I would send out a brief email that set out the meeting agenda and elaborated on the product problems. This is crucial to give your team time to think about ideas beforehand. I learned this from practice; when I first tried this I didn’t give people time to prepare and the ideas they had were mediocre, but most importantly very few ideas were contributed.

I would then brainstorm ideas on my own to prepare for the weekly meeting be prepared to share my own ideas and get feedback.

I would then start the meeting off by presenting the product objectives again and ask the team for any ideas. My team lead was very helpful at the start by giving a few ideas which helped the team relax and brainstorm. If nobody had any ideas I started asking questions that would guide them to think critically. If even that didn’t work I would share an idea of my own to start discussion.

Only at the end I would share my own ideas if they had not been already mentioned. This keeps the team fresh and won’t lead them to tell you your ideas.

I would note all of their ideas and use the best suggestions. Sometimes I would stick with my ideas, sometimes with the team’s, most often combining the best of both worlds. I would then convey them to the CTO and discuss the proposal with him further, noting this was done in collaboration with the team to add more weight. I would then work with the CTO to incorporate their suggestions and improvements. 

Every time an idea made by a team member was used or something was informed by it I would tell this to the team to pat their backs. This created a positive feedback loop, when more of their ideas were used, more ideas would be suggested and the more proactive they would become by contributing and brainstorming solutions.

After that I would have the team lead and CTO backup whenever I needed to get CEO approval. Getting CEOs approval then became a non-problematic part for me. The proposals were better, the team had a vested interest to make them work and it was much easier to get the CEO on board, even if it was a feature or test they would not otherwise have supported.

How I leveraged consensus to reach my goals

Here’s an example to showcase the process: I proposed a test that would very drastically change UX in user on-boarding to improve overall conversion. The CEO was initially against it, arguing it wouldn’t work.

I did my best to support my point, but without actually testing it, it boiled down to the CEO’s view against mine.

Instead of trying to push this myself I presented the idea to the CTO and separately to my team at our weekly meeting. I first presented the problem and asked for their ideas and  only then presented mine.

The team was skeptical, but understood what I was aiming for after presenting how I came to the conclusion and collectively agreed it was a good idea to proceed with it. That’s how I aligned with the team and the team lead, which would later back me up.

The CTO liked the idea at the get go, so he didn’t need anymore convincing. I got approval by him and set the plan in motion. Keep in mind I didn’t get any approval by the CEO, which meant he would still not support this. 

When the test was ready to go live I followed up with all stakeholders to let them know it’s on track to be live by the end of the day, since it was a rather impactful test. 

I didn’t know this but the CEO at that point wanted to cancel it. It came down to CEO trying to convince the CTO to bin it. CTO was unfortunately not able to hold his ground either. Luckily the news got to our team lead as well which backed the CTO against the CEO and eventually convinced the CEO to let us push the test to production.

All this without me even being involved in the discussion. Trying to do this myself would have been impossible.

A day later the results were in and they were significant. The test was a major success, doubling the funnel conversion! The CEO got the news and congratulated the team on the effort, while the team celebrated the victory.

Include your team, and your team will include you

All in all, make your team a part of the ideation and decision making process to not only improve the quality of the product but also to give them ownership and eventually support you up when you need backing.

If this is not currently the way it’s done in your team or even your company then it will take some effort to introduce the process but it is definitely worth it if you aim to be effective.

About Andraž Zvonar

Andraž is a product manager curious about software products that delight. He loves making music and creating new experiences!


More About The Product Mentor

TPM-Short3-Logo4

The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…

Better Decisions. Better Products. Better Product People.

Each Session of the program runs for 6 months with paired individuals…

  • Conducting regular 1-on-1 mentor-mentee chats
  • Sharing experiences with the larger Product community
  • Participating in live-streamed product management lessons and Q&A
  • Mentors and Mentees sharing their product management knowledge with the broader community

Sign up to be a Mentor today & join an elite group of product management leaders!

Check out the Mentors & Enjoy!

Jeremy Horn
The Product Guy