Product Engineering: Reimagining role boundaries at Asana

Within tech startups, many people believe they either fall into product roles (e.g., product managers, designers, etc.) or engineering roles, and that interaction between the two camps resembles the following: the PM hands off a spec to the engineers and then the engineers build the feature.

But it doesn’t always have to be  that way. At Asana, we have product engineers, who, as the name describes, do both. Product engineers play a role in the entire product lifecycle, from inception to launch, and get to work cross-functionally not just within product and engineering, but also across the user experience research, data science, sales, and marketing teams.

We spoke to a product engineer and product engineer-turned-manager on our team to find out how Asana is changing the role boundaries for product engineers.

Ownership and empowerment lead to impactful contributions

Theresa Lee

As a product engineer, I’ve always felt like my job is much more than writing code: from discussing what features we should work on in planning, to working closely with designers and keeping the engineering voice present throughout the entire process, right up until (and after) launch. This makes sure that we find solutions that are balancing multiple factors of “easy to do,” “don’t create technical debt” and “serve the user needs.” For example, if a feature would make it easier for the user to perform some action, but was very difficult to implement without creating technical debt, product engineers would think about the tradeoff: is this action something that happens frequently? If so, then it may be worth the effort; otherwise, it should be put at a lower priority. This is just a simple example of some things that product engineers keep in mind and bring up during the product cycle.

The first feature I worked on at Asana (I literally started working on this during my first day!)  was making private tasks and projects show up as private links. While working on this feature, I was the DRI for the feature. This meant I worked on the overall goals, but also on granular details like language, type of icon, and the behavior of the cursor when indexing through the link.

The Shipping and Launches project at Asana makes it easy for me to make sure what I build gets clearly communicated to users by our marketing team. We add a task to this project before we ship a feature, and it’s always assigned to the DRI of the feature (typically a product engineer). The project is followed by much of the company, including our co-founders, and helps link processes around marketing and press for features. Having such clear ownership and built-in accountability empowers product engineers to do more than just build the feature. Where PMs would typically act as gatekeepers, product engineers are empowered to make decisions and move work forward.

This type of ownership and responsibility also applies to much larger features or portions of the product or tech stack. Many product engineers are project leads (PLs) for broader technical programs at Asana, like the task pane. They partner with PMs to decide the direction of the overall program, what the team is going to focus on, and set high level goals for the episode.

Sweating the details

Sarah Chandler

As a product engineer, we get to sweat the details of new features, and because we’re engineers, we can often build or play with solutions at the same time. That’s one of the best parts of this work: quickly throwing something together that helps move the entire design, development, and launch process along faster. For example, I care about the details of app interactions, such as being able to try things out, fine-tune them, and work closely with a designer to make sure everything feels right. I feel really proud that I have the skills to work with other teams to contribute to building something that’s not just useful, but beautiful and enjoyable too.

One of my favorite projects at Asana was figuring out the navigation for the Android app. Over a couple of days, I worked directly with a designer to quickly prototype a few of our ideas (mine and the design team’s). I would build something, Slack the APK to everyone, and we would try it out—no matter how crazy the ideas were. Through that process, our PM and user experience researcher helped us decide which ideas to prioritize. Later that week, I worked with the designer to build out a more polished version which we sent to our beta for more feedback. Ultimately, we made a couple of changes to get the app feeling just right, and it launched! It was a lot of fun to work with the designers and we all learned so much about how the navigation could feel from the prototypes I made.

Getting cross-functional

Theresa Lee

There are so many different skills that are essential to developing a great product, and as a product engineer, I’ve been able to develop a wide range of them through my cross-functional work. I’ve improved my sense of usability, design, and product skills by working closely with designers, product managers, user experience researchers, and many other different groups such as marketing—all of whom are experts at their craft.

I’ve taken to shadowing users experience research sessions and observing how both new and power users think of different features and products. This has deepened how I empathize with different users and enabled me to give more structured feedback to our design and UX teams.

I was surprised at how closely I work with the sales and marketing teams for launches, even for small features (like project due dates showing in Calendar View). For example, I keep the marketing team updated on the status of what I’m building so that they can blog about it, and the sales team checks in about customer requests that are launching soon. Being an engineer and working so closely with seemingly unrelated teams has shown me the impact that my work has—not just on teams at Asana, but on our users, too.

As engineers, we know that our work affects our customers, but working alongside customer-facing teams has really allowed me to experience firsthand what features our users want and how influential they can be in the sales process.

Reimagining role boundaries allows all of our teams to do great things together and, as a result, our collective of peers continues to be transparent and united in achieving our goals. How has your team reinvented roles or role boundaries? Tell us about it in the comments. And if you’re interested in joining a team like ours—be it engineering, product, or something else—we’d love to hear from you.