Breaking Down the Product and Engineering Wall: A Catalyst for Product Success

While there are many reasons to unite your product and engineering teams, shipping better software faster is among the most compelling of the bunch. At UserVoice, we found that the separation of our product and engineering teams led to finger-pointing. Engineers would grumble “I don’t understand why we’re building this, it doesn’t make sense," while the product managers would see what the engineers delivered and think “This doesn’t solve the problem we set out to solve.” Neither party was satisfied with the process nor the outcomes and the two teams were frustrated. These inefficiencies were causing significant repercussions to the ideation and building of new products.

The root cause of this tension? These two teams had very different goals. After all, the mechanics of the two roles are very different, so you’d presume the measures of success be different as well. Over the past year or so we found some pressing flaws with this theory.

“Product teams love to identify the problems holding our users back then provide solutions to those problems that will delight. Engineers love solving problems for use-cases that are real, well understood, and well defined for our users,” said Torre Matthew, one of our exceptional Product Managers at UserVoice.

Oftentimes, product teams are often goaled on adoption, which is a proxy for the delivery of value. Ideally, you could get an honest answer from your entire user base to know just how valuable each change a product team makes turns out to be.

On the other side, engineering teams are measured on efficiency, predictability, and delivery. These are important things to know, of course, but getting an A+ in each of these areas in no way guarantees that what an engineering team delivers is valuable to customers, and therefore the business that employs them.

In the end, the goals of the product and engineering teams of an organization should be the same — the delivery of value.

Why break down the product and engineering wall

Today, I’d like to address another significant change that helped better suit the product and engineering teams for each other: flattening the product and engineering teams to break down the product engineering wall.

Previously, I discussed our switch to Shape Up and how that has enabled our teams to have a voice in product decisions. Shape Up has moved the needle for us and we’re now delivering high-quality products that our customers actually want. How did we know this was a needed change? And how exactly did we get here?

How we aligned product and engineering

We realized we were guilty of continuing this pattern. So, how did we shift from the mindset of maintaining traditional, separate product and engineering metrics and align our teams toward the same goal?

• Merging product and engineering leadership
• Giving engineering a seat at the product table
• Emphasizing open and consistent communication

It took some work, but the results speak for themselves. Our teams are now higher-functioning and our customers are happier than ever.

Merging product and engineering leadership

The first step we took on this journey was merging the leadership of the two teams. Since we’d already decided it was best for the two teams to be goaled the same way, it only made sense to unify the leadership as well. For us, having a VP of Product and a VP of Engineering promoted team focus with tunnel vision — the two siloed teams worked together, of course, however they didn’t value the same things, which led to some serious challenges. Any time there was a disagreement, conversations were going up and down a chain of command, losing fidelity, emotion, and impact.

Naturally, someone accountable for operating a great engineering team is going to emphasize achieving superior traditional engineering metrics and the same holds for product leaders. For us, this led to a tense relationship between the two sides of the R&D coin and was hindering us from doing the exceptional work we could have been doing.

We maintain a traditional organizational structure oriented around job function in order to help people grow their careers. However, when it comes to the day-to-day work and setting outcomes-based goals, we put complementary roles together onto teams that last the duration of a Shape Up cycle. Each team will have some number of engineers, a product manager, and a designer. This is becoming more common, but it’s obvious that in order for a team to produce a full solution to a problem they’ve been tasked to wrestle down, they require each of these functions.

Leaders in product, engineering, and design, are all goaled on producing valuable improvements to our product. We no longer report on engineering velocity to the entire team, because that doesn’t translate to customer value. We do report on product adoption, but only as a part of the formula that you need to understand customer value.

Giving engineering a seat at the product table

Engineers know the product they’re working on, so why limit solution design to product managers and designers? Chances are high that your own engineers have ideas and opinions about solutions so give them an outlet to share those. This is why we invited engineering management to have a seat on the product team and we don’t do this in the traditional consultative role — one where we ask the engineering team “how hard would this be?” Rather, the engineering managers play an active role in deciding what we’re going to work on.

This is the beginning of a shared understanding of value across both teams. Leaders of each discipline must be able to speak confidently — from a place of true personal belief — that the projects we’re taking on are valuable and the best choices that we have before us. We’ve been able to do this rather easily thanks to Shape Up. We’re now able to have these conversations throughout each cycle of work and the team is empowered to bring up the most important feedback and requests from our customer base.

Our engineering and product teams are now working in far greater harmony, too. Today, we get the leaders and the broader engineering team involved in the preliminary research into both problems and solutions, rather than just asking them an offhand question about the complexity of a vaguely defined solution. This way the problems are well understood and the solutions to those roadblocks are far more aligned with end goals.

You might think that generating this alignment requires more meetings and more work. In the end, it does not. By making the “why” clear up front, you save a lot of time in significantly lowering the level of detail that product teams need to provide in expressing a solution. Conversations suddenly become a lot more information-rich rather than the giving and consuming of orders.

Emphasizing open and consistent communication

Finally, we make sure that everyone on the team is hearing about the goals of delivering value and how we’re going to measure that. It begins with making sure that everyone on the now single product and engineering team clearly understands the problems we’re trying to solve and why those problems are important to the users of our software. This requires everyone on our team to learn a lot about our customer base, what they value, and the job they are trying to get done. This is a good thing, the better you understand the people using your software, the happier you’ll make them and the better your business will do.

This philosophy isn’t limited to just the product/engineering team, but we embrace it company-wide. Everyone at UserVoice is a Product Manager. By encouraging others to emulate a Product Manager as a team we foster a closer relationship with our users and are able to better understand their challenges.

One big collaborative team

Today, we are a synergistic team, all fixated upon our users and product evolution. It’s understood by everyone what we’re trying to accomplish and this leads to an organization-wide emphasis on thinking critically about the problems we’re trying to solve and for whom we’re trying to solve them.

“We knew we could be doing better so we shifted our process to allow our product team to really spend more time thinking about problems to be solved and less about solid solutions,” said Torre Matthews. “This enabled us to bring better thought out problems to our engineering team and lean on them like we never had before — but should have been — to be more active participants in defining our solutions. My only regret is that we didn’t make this shift earlier.”

If you’re running your product and engineering teams separately, consider tearing down that wall. For us, it’s made for a dramatically more productive, efficient, and most importantly happy team. If you’re interested in learning more about the outcomes of our product and engineering enhancements or simply want to chat, get in touch!