Article

How to Get Your Engineering Team Involved in Product Efforts

•

August 11, 2020

•

5 min read

At Dataline, we don’t have a product manager. Seem weird? We’re not the only ones to do that...for instance, that’s also the case at Apple. But in our case, this role is spread out across our engineering team. In this article, I will detail why we do this and how we do it. To be honest, there are many things we’re still iterating on, and refining our processes will just be a constant effort, as it should be in every company. Note that our process works for any engineering team, working together in the same office or remotely.

Why you want your dev team involved in your product definition efforts

In our particular case, our target customers are developers and engineering managers (and later on, product managers). So our engineering team also happens to represent our own customers. It stands to reason that they should have deep insights on what has value and what has less, probably more than a non-technical product manager who thinks they can understand the audience.

However, this doesn’t mean that if your audience is not engineers that you shouldn’t care about this. Indeed, engineers have a lot of product knowledge and insights to share. That’s not surprising: they’ve been building products all their professional lives! Getting them involved will improve the quality of the debate around your product definition efforts and, therefore, your product overall.

Involving your team will get them to care more about the product. More care, more motivation, more productivity - all add up to higher quality work. And all of that makes a huge difference on the bottom line.

I hope I have convinced you why you should consider involving your engineering team. I’m sure there are many other ways to do this, but let me go through the 9 ways we do it at Dataline (some even inspired from previous work at Apple).

1. Asynchronous communication means written communication

Collaboration within engineering teams is asynchronous. Every tool they use favors asynchronous communication. And there is a very good reason for that. The biggest loss of productivity for engineers comes from interruptions (planned or unplanned). And you don’t ever want to make a conscious choice of sacrificing your team’s productivity. It will send your team the message that their work is not important, which will destroy any productivity left.

So how do you achieve product involvement asynchronously? You will need to favor written communication. At Dataline, our center of communication is the ticket. Everything is written within the ticket.

The ticket description is kept as it was at its creation so other team members can understand the conversation. And when a plan of action is decided, it’s written in the comments and added in the description, but below the “original description” as a separate part named “plan of action.” This enables the team to avoid going through the whole discussion to get the conclusion, but if they want to, they have access to the full history.

For us, oral conversations or Slack ones are both considered informal. If any progress is made on the subject during these discussions, a summary should be reported back as a comment in the ticket.

This is important, as it implies that anybody can pitch in and participate in the debate. The engineering team does not consider itself as contractors for the product team, as they are developing features that they could influence.

2. Expose your team to customers and their feedback

There is nothing new here. So, I won’t belabor this point. No individual, however good they might be, can think of all use cases and needs for the product’s customers. Being exposed to customers and their feedback enables your team to be educated about the customers’ needs and pain points that they might not have perceived otherwise, because they do not use the product in the same context.

You want your debate on the product to be qualitative, and thus you want every participant to be in touch with your customers, in order to take a step back from their own convictions. Feedback opens minds, and you want open minds to have fruitful debates. That doesn’t mean you should go towards consensus. Let me be clear, you should never go towards consensus. But, you need open minds to listen to your teammates’ arguments.

3. Let your team create the tickets

This might not be intuitive, and actually, is probably the hardest to implement. The reasoning behind it is that when you create tickets, you have already put your own way of seeing how to implement this feature within the ticket. If your product manager creates the ticket, you may not realize it, but it can actually have an adverse effect on your team. Inevitably, the way your product manager (PM) does this is not the way your team would do it. The result is loss of focus, productivity and even possibly implementation quality. It always takes more time to understand another person’s point of view than your own, let alone how to approach a problem starting from another person’s view.

Another reason is that if your PM or manager creates tickets, it implies a contractor relationship with the team, which doesn’t encourage the team to get really involved or motivated. They might not tell you about it, but I assure you they feel it.

Now, it’s not an easy task to have your team create tickets. They will say they prefer you to do it because it’s more work for them. Don’t give in. The rewards are really worth it. They will get more involved.

4. Ticket descriptions should only focus on problems to solve

If you put the solution right into the description, it doesn’t invite people to pitch in, it ends the debate right away. So, instead focus the description of your tickets on the problems you’re trying to solve. And if you have a solution in mind, put it as a first comment and invite others to pitch in.

Don’t hesitate to mention people in the comments to bring them into the discussion if you think they might have an opinion on the matter.

5. Discuss the features before the design work

For instance, in a project prior to the current version of Dataline, the beginning of workflow would look something like this: Ideas > In Discussion > To Design.

Tickets would go from Ideas to In discussion when we wanted to address them in the coming weeks. Once a plan of action was agreed on, it would go To Design. Both engineers and designers were invited to participate in the discussions occurring in In Discussion.

We tried to put priorities at each stage. This means priorities might have changed from one stage to the other. For instance, something that was high in In Discussion because it was something we wanted to work on in the next few weeks, once discussed, would be moved to To Design and have a lower priority there, as designers might have been focusing on finalizing a milestone before that.

6. Include the design workflow within the engineering projects

In the same project, after To Design, we would have Design To Review > Feature Validated > In Progress > Integrate > Verify… So, you can see that the design workflow is part and parcel of the overall engineering one. There was no separation. This is important, as you want your engineering team to be involved in the design process and your designers to be involved in the implementation phase.

7. Design Reviews with the engineering team

In order to get the engineering team involved in the design process, we hold design reviews to discuss all tickets that are in the Design to Review state. For the moment, we have been doing video calls with screen sharing by the designers, who are leading the meetings and presenting their work. Engineers are invited and welcome to join to pitch in with their comments.

Before the meeting, we write our comments in Figma, which is an awesome design tool for collaboration, as it helps the designers prepare the design review.

8. Get the team to present the new features they worked on

You want your engineering team to be proud of what they ship. That’s very important to get them involved. One really great way to do this is to have them present their work to the whole team at your all-hands weekly meetings (if you have weekly ones).

Indeed, if they’re proud of the work they’ve done, they will happily present it. But if they’re not, they might feel a bit ashamed at presenting their work. You can be sure that the next time, they will try to get more involved so they won't be embarrassed again!

9. Update your team with the impact made

Your engineering team cannot be responsible for gathering the metrics on the impact made for each feature developed. It requires a certain discipline and a lot of effort. So you still need some product-related entity to do this, which could be the data team or a product owner.

Without knowing the impact of the work done, the question arises as to whether the work is meaningful.. So, this part is an absolute necessity. Don’t underestimate its importance.

---

A little conclusion

Have you ever read Conway’s law? It says:
“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."

Even if you have a dedicated product manager, getting your engineering team involved will benefit the organization and its product in a lot more ways you can consider. So think about it!

Let me know if there are other ways you can think of. We’re constantly working on improving our processes, so I am definitely interested!

Limitless data movement with free Alpha and Beta connectors

Introducing: our Free Connector Program ->

The data movement infrastructure for the modern data teams.

Try a 14-day free trial