How product managers and engineers at Asana develop great relationships

A healthy relationship between Product Management and Engineering is critical to building successful products. It’s also essential to creating a team where great people want to work.

When it goes well, we’re two partners working shoulder to shoulder towards a shared mission. Each is grateful for the contribution of the other. When it goes badly, there’s finger-pointing, ignored input, wasted work, frustrating processes, and resentment.

New PMs at Asana tell me how good it feels to have engineers who care about creating great customer experiences and who actually want a PM. Many new engineers have told me the same: that working with PMs at Asana is much better than at their past companies.

Here are the four keys to a healthy PM and engineering relationship:

1. Share leadership and credit

One of the top ways PMs damage relationship with engineers is by hoarding all the credit. They claim that they thought of all the ideas and make sure they’re always the ones presenting to executives, leading meetings, or announcing results. They act like they’re the most important person on the team.

At Asana, we explicitly share leadership between product managers, engineers, and designers. Each role has a clear responsibility, but we all work together to share our points of view and come to better solutions together. We have different points of view, but we all know we’re on the same team working towards shared goals.

One specific way we share leadership responsibilities is through our concept of Program Lead (PL), who can be either a PM or an Engineer on the team. PLs own communicating progress, establishing the rhythm for the team, and team unity. The Program Lead can be the same person as the Tech Lead, but on some teams they are different engineers — one person is responsible for running the team, while the other person is responsible for the technical direction.

At Asana, we explicitly share leadership between product managers, engineers, and designers.

Another way we share leadership and credit is with Key Results. These are team goals that get shared across the company. We assign them to the person who contributes the most towards their success, whether it’s an engineer, PM, designer, user researcher, or data scientist.

With this system, more people get to take on leadership roles and everyone gets recognition for their work.

“I think PMs are awesome at letting engineers own process, meetings, and leadership. They really understand that credit is not a finite resource, which hasn’t always been my experience with other places.” – Cliff Chang, Growth & Adoption Eng Lead

2. Include engineers in product decisions

Some PMs think it’s their job to have all the ideas and do all the product thinking. They’ll go off with their designers and come up with a grand vision to toss over the wall to the engineers for implementation. If an engineer comes up with a proposal, they’ll quickly dismiss it — either out of a lack of respect or territorialism.

At Asana, engineers are involved and can lead product direction from the beginning of the product lifecycle. We gather input from across the company in planning our roadmap, and include all the engineers on a team in research and design brainstorming at the beginning of each project.

Engineers appreciate understanding the reasoning behind product decisions. PMs love when engineers come up with valuable ideas enabled by creative technical solutions. We know aligning everyone on the team around a shared purpose and shared understanding will help us achieve bigger and better things together.

“I love how engineers are included in brainstorming.” – Rachel Miller, Engineering Manager

“Getting engineers involved in product decisions not only resulted in better quality output, but also made the product design process much faster! When the New York team worked on a large feature rich with complex interactions, many of the product decisions were exposed to high technical risks. Instead of going back and forth between design and engineering, getting everyone involved in the same discussion was more efficient and way more fun/rewarding for everyone!” – John Hung, Product Manager

“When building custom fields, a powerful feature that integrated across Asana, there were aspects of the product spec that would have introduced engineering complexity, added eventual user confusion, and delayed our launch. Instead, the PM and I went back to the product goals and came up with alternative solutions which were faster to build and ended up being even better for the user.” – Eric Pelz, Engineer & Program Lead

At Asana, engineers are involved and can lead product direction from the beginning of the product lifecycle.

“I really appreciate how involved Asana engineers are in the product process. They really care about the user needs and approach the discovery process with curiosity. Alvaro, a product engineer, once set a record for user research sessions attended during our program! This user empathy also carries through to the solutions they build, where I’ve seen Asana product engineers do a great job of weighing eng tradeoffs with users in mind.” – Lili Jiang, Product Manager

“Before I was a manager, I pushed really hard for us to take mobile seriously and was told not only ‘go ahead’ but also got the mandate and support to build out a whole team to make it happen.” – Tim Bavaro, Product Eng Lead

“Our Tech Lead was working on a technical design an upcoming feature and came to an important a-ha! moment on how it should be architected. Funny thing, those principles were just as relevant to the feature’s design as well. So, the TL pulled in Design and Research, we jammed away and suddenly, it’s an a-ha moment for the whole project, end to end.” – Lawrence Han, Product Manager

3. Clarify roles and reinforce them with mutual respect

An easy way to muddle any work relationship is with unclear roles and lack of respect. PMs insult engineers by trying to tell them how the code should work or endanger the schedule by insisting on frivolous features with outsized costs.

At Asana, we’re really into clarity of purpose, plan, and responsibility. When people start at Asana we cover the basics during onboarding: PMs own the problems and Engineers own the solutions. For team leadership responsibilities that can vary from team to team, we go a step further and fill out a checklist so it’s clear for each responsibility whether the PM or Program Lead will take it.

For mutual respect, our trick is really in the cultural norms we’ve set up. We’ve never had a PM sign an eng up for a deadline without their buy-in. Engineers take the time to explain technical challenges to PMs and really care about the customer impact of our work. All new employees go through leadership training that reinforces the idea of approaching situations with curiosity rather than a need to be right.

“Working on Conversations, I really didn’t want to work on emails because I didn’t think it matched our strategy. The PM explained the usage patterns of Asana, specifically that teams leads use Asana the app, while a lot of other users use it via email. So if we don’t make the email experience good, all these users and their teams won’t be able to use the feature. This gave me the motivation to work on emails and understand the value. On the other hand, there was a feature that would bloat to our data model. The PM approached it with curiosity asking about the cost of adding extra bits to our data model and we talked through the pros and cons. In the end, she agreed that it was not worth it for this feature.” – Bella Kazwell, Web Eng Lead

“I joined a technical team at Asana and expected that I’d need to spend several months proving myself to earn respect. Instead, I was welcomed to the team right away and really felt like my opinion was valued. The engineers were quick to give me praise and point out the things I did that added value to the team.” – Caitlin Johnson, Product Manager

4. Clear away inefficiency and help your teammates succeed

I’ve heard from engineers at other companies who think that PMs just add bureaucracy and inefficiency. They’ve worked with PMs who try to solve every problem with more meetings and who burden engineers with work about work without convincing them that it’s worth it. Even worse, those PMs thrash projects in the middle because they’ve changed their minds, wasting weeks or months of work.

At Asana, one of our top values in PMs is being a productivity multiplier. We’re encouraged to look for every kind of creative way to help our teammates be more efficient and effective. We use our product process to ensure we really understand the customer problem we’re going after and are all on the same page about goals at the beginning so we avoid unnecessary changes later.

“I find PMs here are really helpful with constructive feedback for engineers (both directly to them and to their managers) and it’s clear they genuinely want them to succeed.” – Tim Bavaro, Product Eng Lead

“I love how PMs will work with engineers to get their side projects launched” – Rachel Miller, Eng Manager

“One of our teams lost an engineer. A PM presented a very clear argument about why shipping this project on the original timeline was very important for the business, while a different team could afford to take a hit. This made the staffing decision obvious and made it very easy to pitch the eng team and the engineer transferring teams on why it’s important.” – Bella Kazwell, Web Eng Lead

Healthy relationships between PMs and Engineers are critical to the success of any project

Healthy relationships between PMs and Engineers are critical to the success of any project. With shared leadership, inclusive decision making, mutual respect, and a commitment to helping each other succeed, you can build a team that delivers results and attracts great people.

Calling all engineers and engineering managers: we’re hiring! If you’re interested in joining Asana, we’d love to hear from you.

Would you recommend this article? Yes / No