How to Build Product-Oriented Engineering Teams

Product-oriented engineering teams do more than just write code. They’re more than just a feature factory; they’re co-owners of the product experience. They look at the full picture to understand the value and impact of what they’re building. They talk to customers. And they rigorously analyze and measure the performance of features to unearth opportunities to improve.

Building and being a product-oriented team isn’t without its challenges. From staying involved with product and design decision-making to encouraging any and all ideas on a cultural level, here are five ways engineering teams can better influence the products that they’re working on.

Product Oriented Engineering Teams from Amplitude

1. Don’t Get Siloed Off From Product and Design

If you want your team to influence product, you can’t get siloed off from product and design.

In typical product organizations, you’ll have different functional roles. In many cases (but not necessarily all), you’ll have your product managers (or an equivalent role), your designers, and your engineers. These roles tend to have a clear understanding of what they’re responsible for. The PMs are responsible for understanding the discovery and the problem space. Designers are responsible for exploring the solution space and coming up with the solution. Then, engineers are responsible, as you know, for executing on that solution and delivering a quality product in the end. In this scenario, it’s really easy to get your blinders on and focus heads down on one particular aspect.

What good engineering teams do

Good engineering teams will strive to influence product decision-making by avoiding a function-separated dynamic. They’ll invest in building really strong relationships with their colleagues on these other teams. In the best case scenario, they’ll also hold themselves accountable to the same product metrics and product goals that the rest of the organization is responsible for. In the end, this breeds a true sense of equally shared ownership over the product. No team owns the product more than another.

In an opposite scenario, engineers who are completely siloed off are heads down and focused on execution. This tends to fuel office politics and put stress on relationships between different teams. The product suffers.

Communication helps everyone move faster

At Amplitude, one of the things I enjoy the most about working is are the strong relationships we have built with our engineering, product, and design teams. But even here, there have been instances where engineers have incidentally isolated themselves and caused pain in the end.

Take this example. Below, you’ll see a screenshot of all the different colors and buttons that we have in our app. This was taken a few months ago and as you can tell, there are a lot of colors and buttons. This translates into a lot of duplicated code and a lot of code maintenance.

We have so many color variations to choose from, which ended up taking a lot of time for both the engineering and design teams.

For the longest time, the front-end engineering team was bellyaching about this problem and saying, “Why can’t designers give us designs that are consistent and have the same buttons. Why do we have to keep creating all these new colors?”

Eventually, after a year of complaining internally, the engineers finally decided it was time to sit down with the design team and actually hash it out. When we did, we were surprised to find out that the design team actually wanted to do this as well. They had just assumed that we wouldn’t be bought in and wouldn’t be interested in actually taking on this challenge.

So even here at Amplitude, where we have such great relationships, we still fell into the trap of siloing ourselves out. It’s really unfortunate that we went so long without communicating the issue (and finally tackling it at its core).

2. Recognize the Value of Iteration

If I were to ask “how do you build a car?” what would you say?

The naïve answer would be “Henry Ford.” You have an assembly line, each of your parts, and you go down the line. In the end, you build a car. Right?

Not so fast.

Here at Amplitude, we use Henrik Kniberg’s metaphor to highlight the value of product development. In the exercise above, you’d end up with a car, but is it the type of car you actually needed to build? Maybe you’ve focused too much on the interior, and the exterior doesn’t match the latest styles consumers are looking for. Or maybe you realized after-the-fact that you should have installed a mini TV in the back seat. Either way, you overlooked important details because you jumped straight to building the final product that you thought should be built.

We prefer to design solutions by focusing on the real problem at hand. With a car, the real problem is that you’re trying to get from point A to point B. How can we deliver a solution that solves this problem as quickly as possible in order for us to learn and figure out what to do after that?

To simply get from point A to point B, the easiest thing we can do is just take a block of wood, sand it down, add some wheels, and we have a skateboard. Then, we can go out there with our new skateboard, try it out, show our friends, get their feedback, and figure out what to do from there.

Building a car probably doesn’t start with an actual car. It probably starts with something much simpler, like a skateboard. That’s the value of iteration.

Maybe next we apply our learnings from our skateboard to build a scooter that ends up being a better scooter than if we hadn’t built the skateboard to begin with. By repeating this process and having this constant interaction loop, hopefully at the end we have a car that we’re much happier with. Or, maybe it ends up not being a car. Maybe we end up with a spaceship.

Your product development process should help you build a better product

Engineers have a lot of knowledge about the solution space and should be involved in every product iteration. A good example of this is Taxonomy, one of our most successful features. It solves a bunch of different use cases to help teams manage their data. If you look at the original mock-up Taxonomy, you see that all it was focused on was adding the feature set to allow you to categorize and describe the events that you send to us.

Our starting point for Taxonomy included limited features.

Over time, this design evolved from skateboard to scooter and scooter to bicycle. The end product (below) encompassed many more different problems such as setting up filters to filter out PII data or sensitive data and transforming your data to make it less messy.

After several iterations, Taxonomy took a different form to bring more features, and therefore more value, to our users.

Scope is important. That does not necessarily mean scoping things down. If you’re given a design and you realize as an engineer that this design isn’t going to help your team learn what to do next, you should push back and suggest increasing scope to deliver a product or feature that will generate learnings and help you figure out what to do next. Or maybe it means coming up with some creative alternatives.

3. Directly Interact with Customers

To influence product direction, engineers need to directly interact with customers. From a product strategy perspective, if you want to influence the product and make your voice heard, you really need to have an understanding of how your customers are talking about a particular problem.

We actually have a Slack channel called #customer-notes where we log all interactions with our customers along with key takeaways from client calls. We also sometimes include video recordings of these interactions.

Amplitude engineers stay connected with customers by participating in client calls.

In the image above, you’ll notice there are two engineers, a designer, and a product person. We believe this type of interaction is so important for engineers. There is nothing more inspirational or insightful than direct customer interactions. And oftentimes, we’ve had engineers walk out of a meeting with a customer and ship a fix or an improvement that very same day. While reading the Customer Notes Slack channel and watching videos are great, you can’t substitute being present with the customer. If other roles are working with customers and engineering is not, you’re going to have a really difficult time justifying your arguments for product strategy.

4. Understand How Features Are Being Used

If you want to have your voice heard to influence the direction of the product that you’re working on, you really need to know your stuff when it comes to how people are behaving in your product today.

Product-oriented engineering teams wait to celebrate their wins until after they’ve shipped product and are able to measure the results (and therefore the impact) of what they built. This is unlike most product teams, who celebrate as soon as they’ve shipped.

The reality is that an engineering team wants to have more influence on product strategy. Simply shipping product is no longer the end goal. Instead, the goal becomes to build the best product possible. This involves analyzing the impact of features and understanding and learning from user behaviors. There’s no reason that your engineering team can’t own this part of the process if you have the data available to you.

A couple of our engineers digging into product analytics!

5. Encourage Experimentation

Any good engineering team is going to have a set of processes in place to keep the code-quality bar high. That could include unit tests or code reviews. This process can actually have a negative side effect, though. You might have other people within the company who have good ideas and some coding skills, but they feel intimidated or they don’t have the time to get onboarded with your company’s experimentation process. So, their ideas never get tested out.

Breed innovation by creating opportunities for experimentation

At Amplitude, we’ve seen well-intended engineering processes inhibit experimentation. A few years ago, we realized some back-end engineers and designers were actually afraid to make contributions to the front-end team. They thought it was too much work, or they were afraid that they were going to break something, or that they’d get nasty code review comments.

In response, we built Labs, a solution that allows anyone within the company to test out their ideas. It’s basically a product sandbox. You can build to your heart’s content without worrying about experimentation processes or breaking anything for any of our customers.

Labs is our way to give people space to just be creative, and it’s worked out pretty well for us.

Labs are actually really simple and work like this: Our front-end code base is one single repo and we’ve set it up so you can have it point to any one of our back ends. That way you don’t have to have the back end running yourself. To create a new sandboxed lab, you simply create a new directory and write some JavaScript. You’re free to pull in whatever dependency you want. This code is isolated, separated from our main JavaScript bundle. This means creators can rest easy at night knowing that they won’t be breaking anything. And they won’t be impeded the normal thorough code review process, so they can get experiments into the hands of select customers really quickly!

Creating a culture for experimentation has had a noticeable impact on our company. Many of our best features released in the last few years were born out of Labs, including our Insight package for monitoring and alerting our Personas chart type, our Engagement Matrix chart type, and our team spaces concept.

Insight, which came out of Labs, tracks user actions to help you keep an eye on product performance.

It’s important not to lose sight of the relationship between experimentation and innovation. Engineers have a big responsibility to ensure that there’s a culture of experimentation in your company. You should be thinking about how to remove obstacles to enable other people within the company to test those skateboards.

Don’t Focus on Building the Car. Build the Best Possible Engineering Team.

If you’re an engineer who wants to build the best possible product, invest all your energy into building the best possible engineering team first. Nurture relationships with design and product. Embrace cross-functional teams or what we call “pods” here at Amplitude. Prioritize experimentation. Encourage a healthy sense of creativity. And don’t be afraid to build a few skateboards along the way.