Skip to main content
Automatically keep your work and documentation completely in sync.LearnaboutDocs.

How to Bring Engineers on Board with the Product Vision

Erika Carter

The best way to build bad software products is to be certain that the relationship between your engineers and PMs is full of resentment and mistrust. Indeed, an unempathetic product manager and an unmotivated team of engineers who don’t understand why they’re building what they’re building is the ultimate key to succeeding in building bad software products. Yay. Success!

But, hey, it doesn’t have to be that way! If for some reason you want to build good products with happy people, communication is key - especially bringing engineers on board with the product vision.

When engineers and PMs get along, and the engineers are on board with the product vision, engineers will:

  • Feel significantly more connected to the mission of the company and product
  • Feel creative and empowered, leading them to think big-picture, and contribute big ideas
  • Feel motivated, be more productive, and much happier, leading to much better outcomes

Below are some tips for getting engineers on board with the product vision.

And at the end of this post, Sarah Binion, Engineering Manager at Shortcut, will provide her experience-based tips for PMs to get engineers on board with the product vision.

Always Explain the “Why”

Many engineers appear to resent product managers because they don't inherently understand the 'why' that led to the product ideas and so don't really care about building them. They're not bought in because no one cared about getting them to buy in.

Imagine being handed a to-do list that someone else wrote for you, with no context, no explanation for the reasons behind it - would you be happy about it, or even care about checking anything off? Probably not. Because nobody likes doing work for the sake of doing work, without knowing why. It can be very demotivating.

After all, no one is compelled to do anything you say, and nobody wants to feel like a worker on an assembly line. But this is exactly what some engineers feel like when they don’t understand the “why” of the product vision and how it relates to business goals.

So before telling engineers what to do, PMs should make it clear why this feature has prioritization over that feature, why there is such a strict deadline for this particular set of features, why a bug is not relevant to fix, why you’re doing something now which you said you wouldn’t 3 sprints ago, etc.

Beyond the company Roadmap, Town Halls, and other wider company communications, here are some ways to explain the why behind the what in smaller, everyday ways, because every piece of work has an impact, even the “small” pieces:

  • Explicitly link the everyday work back to the overall vision and goals - why is this bug fix or Story relevant to the big picture?
  • Facilitate interaction with real human users - include engineers when interacting with users and other parts of the business to remind them their work is making real people’s experiences better
  • Give strong, tangible incentives - how does the work benefit the engineers?
  • Share information regularly & give specific praise

Don’t Bullsh*t

Continuous improvement. Product-market fit. KPIs. Leverage. Solutionize. Personas. These words go a long way in pleasing the C-suite, but generally accrue yawns if you’re speaking to a group of engineers.

Speak clearly and honestly, because engineers have special, superhuman capabilities of identifying BS.

Simply explain what you’re trying to achieve and why. Be as brutally honest as you possibly can and leave the cliches for meetings with your sales and marketing teams instead - they love them.

Some even suggest asking your engineering team to call you out every time you use a BS phrase to gain their trust and respect.

Be Strategic About Your Org Structure

The best products are built when key stakeholders and teams are given equal voice in the development process. Org structure is critical to ensuring this equity.

At Shortcut, for example, Product Management, Engineering, and Product Design all sit at the same level within the company. This ensures that if a product manager and engineer disagree on a particular idea, each has the freedom to raise that concern without worrying about pushback. Only when these teams sit at equal levels can a truly safe space exist for each.

Create a Culture of Collaboration

Too often, Product Managers try to come up with product ideas in a silo, which creates two problems:

  • The ideas are limited by that one individual's capacity 
  • Getting buy-in from key partners in the development process is more difficult 

Fostering a culture of collaboration between developers and product managers can offer real change that improves your processes and can even spread throughout the entire organization.

Let’s take a look at some of those benefits:

Better culture

Collaboration brings team members together to create great products. As development processes continue, teams get to know each other better and form real connections. Before long, those working on a project go from colleagues to real friends.

Build better products

It doesn’t take a genius to know that great products come from teams that collaborate well, including developers and product managers. The less conflict between team members, the more time can be spent creating high-quality products packed with value.

More agility, less friction

In a collaborative culture, teams can adapt to changes much faster than teams that struggle to work together. Teams need to work together to pivot their workflow when the software project needs it: especially agile teams!

Streamlined process

Collaborative teams are always on the same page, which means they can stay focused on what really matters. This means less time trying to figure out how to build the product and more time actually building it.

Better alignment

Building a culture of collaboration helps every person involved in a project stay aligned with company and product visions. All team members, from developers to product managers to stakeholders, are aware of the product goals and how they will achieve them.

It Starts at the Hiring Phase

Creating teams that collaborate well starts in the hiring phase. Some people prefer to work alone and simply cannot do their best work when working with others. There’s nothing wrong with that - but they’re not the type of person you want to hire for a development team.

When hiring developers, or new product managers, you need to determine their level of empathy and make sure they have good communication skills. By hiring someone who can empathize with others and clearly communicate their thoughts, you can be sure they’ll be a great fit within a team setting.

It can also help to align the team with higher-level initiatives. This helps to give context to product teams’ actions and helps engineering teams understand the business objectives. It also means that both product managers and engineering managers work toward the same goal in the same timeframe, rather than having their own targets.

Empower Engineers to Work in Their Own Way

The product Roadmap can be a handy tool for bringing developers and product managers together. The Roadmap gives everyone a high-level and strategic blueprint of the company’s goals for a project while breaking it down into an easy-to-understand, granular view. This creates a clear picture of what needs to happen for anyone who looks at the Roadmap.

While it may seem counterintuitive, it can be beneficial to separate tasks. So, instead of a product manager being involved in sprint planning or writing technical Stories, these tasks can be left solely to the development team.

By doing this, the developers are empowered to work in their own way, rather than worrying about how to work in the way that a product manager has told them to. Meanwhile, the product manager escapes much of the nitty-gritty and can focus on the big picture. This is a win for both sides.

By allowing each party to simply do the job they’ve been hired to do, you can reduce friction between devs and PMs and improve collaboration efforts.

Tips from a Shortcut Engineering Manager

Here’s some advice for PMs from our very own Sarah Binion, an engineering manager here at Shortcut on how to bring engineers on board with the product vision.

  • Teach your team about metrics: what are the goals? Don't just tell them but show them how you are getting the numbers and what values you are watching to measure success. Because we are all on the same team: let's have the same goals. Also they might surprise you and start to dig into how we are getting data with you. If you make them feel like getting the right metrics are important, they will dig in with you.

  • Give space to spike on your hypothesis. Tell your devs the idea you want to validate, and ask them to come up with some options and the level of effort required. This will give them space to give solutions you might not have even thought of, and an idea of how much time you will need to plan for the work, rather than giving a random deadline.

  • Don't shut down when someone says "no". See if there is some other solution that can get you close to the problem you are trying to solve. Maybe the question you are asking does not give visibility to the bigger picture you are trying to solve.

  • Let engineers know what you’re working on even if it’s in the ideation stage. Talking about stuff often and openly will make it seem like it is not a surprise and they might even be willing to brainstorm with you. This will help get buy-in early on in the project too.

Try Shortcut

There's always space to improve, no matter which side of the coin you’re on. One way to do that is to choose the right issue tracking and project management tool that fosters the most collaboration. Give Shortcut a try for free.

Topics:

More stories from Shortcut