Every year, our incoming interns have a chance to talk to our Engineering teams and indicate their preferences so that we can match them up with good mentors and interesting work. We find that many people don’t have a clear idea of what they want, and request to be on “backend” teams that sound related to their academic courses. But building Asana requires a lot more than backend work, and more generally, the industry needs a lot of great product engineers with skills in technologies traditionally labeled as “front-end.”
This post explains why so many of us find product engineering compelling so that you can see opportunities for yourself. It’s not about pushing pixels around and fighting CSS—it’s about using great code to ship useful things to people who need them.
Product engineering is, literally, building the product. You collaborate with your team to figure out what you need to make, and then you make it. You ship it. People use it. You improve it.
Lots of people are involved in shipping product features. Ideas come from many places: brainstorming sessions within the company, requests from customers, and the brains of passionate engineers. The whole team collaborates to pick things out of the sea of ideas: product managers have context on the whole product strategy, engineers know how hard things are to build, and program leads know what the team’s workload looks like. And after shipping, everyone helps to iterate on the feature.
We really do mean everyone. Brainstorming, customer calls and all product-y things that are the domain of PMs alone at other companies are accessible to engineers too, if they’re interested. We truly believe that we make the best product we can if the whole team is involved.
When you experience this cycle of iteration in an internship, you gain skills that put you ahead of most new graduates. You do more important work earlier in your career because you don’t have to learn how to work in a product team for the first time. And if you decide to start your own company instead, you’ll have a template for how to run your own product development process, rather than starting from scratch and making beginner mistakes.
Shipping features that improve people’s lives is gratifying. As Asana engineers, we build a product that people use all day at work, where they spend 40 or more hours per week. Improving the product doesn’t just feel like programming, it feels like helping. Every time you add a time-saving tweak or deliver a large feature, you’re directly impacting the workflows of millions of people.
It feels really good to know that every time Uber launches in a new city, they’re doing it four times faster with Asana. Or when MIT plans its annual Earth Day events, including research symposiums and outdoor celebrations to educate thousands of people on things like climate change, they’re doing it with Asana.
Most of the Asana product runs on the web: users load a web page in a browser and our servers send them data. The technology that powers the web has a well-deserved reputation for being complex. Web servers and browsers are built on dozens of interrelated standards that have been evolving since the 1980s, solving for ever more complicated use cases.
Web development is a kind of superpower. It’s by far the fastest way to get product changes out to users and the lowest cost way to get new people using the product. It can be difficult to do well, but the payoff is massive.
Many companies’ web app code resembles exposed sedimentary layers of rock, weathered away by erosion. They aren’t composed of choices so much as circumstances. Not all companies do it poorly, though. There are some (including Asana!) that ship fast sustainably by improving their architecture, using strongly typed tools, and keeping third party libraries up-to-date.
Even with a good codebase, it can be very difficult to navigate the maze of tutorials, references, documentation, and sample code to figure out best practices and build a solid understanding of browser technology on your own. At Asana, we make sure every intern has a mentor who makes time for them. When you have a web UI expert on your team, easy problems have easy solutions, and when you run into something difficult, you’ll usually be able to find a reasonable answer. It won’t take you an entire afternoon to put a button on the right side of the screen.
On the server side, product engineers still deal with databases, performance, and core business logic for the product. You aren’t cut off from low-level thinking just because “product” is in your title. Everyone on an engineering team is responsible for good performance and code quality, and has opportunities to contribute to foundational ideas about how the team builds software.
Product engineers can be specialists in one part of the tech stack, or generalists who can tie many technologies together.
Timeline, one of the biggest launches in Asana’s history, involved a lot of coordination with our backend Stability and Infrastructure teams. A few weeks before Timeline’s launch date, we noticed some poor performance issues that we hadn’t seen in initial development and planning. When we first initialized a Timeline view for a project, we had to create a lot of objects in our backend datastore. In the final stages of testing, we discovered it could be very inefficient, with large Asana projects straining our infrastructure. Our product engineers dug deeper into stability issues, sorting through all of the consequences of the new feature in terms of queries, space, cost, and traffic.
In addition to a web app, Asana also has native iOS and Android apps. Developing mobile apps requires full-stack thinking: there’s a data layer, a UI layer, and asynchronous network communication. We support some offline work, which means we have to use a carefully engineered client-side database. There are also fancy animations and haptic feedback that users really appreciate, so sometimes engineers need to sit with designers and tweak things until they’re perfect.
Product Engineers at Asana go beyond the superficial frustrations of web development. Yes, we work to create features that deal with browser idiosyncrasies, CSS quirks, and an ever-changing front-end landscape. But we also tackle hard, cross-cutting problems that touch the database, the backend, and everything in between, powering the complete reactivity in our product. We design intricate features that require pushing the boundaries of what web applications can do while maintaining a high bar for quality and polish. As a team, all of this thought and effort means that our end-users do better work themselves as we help them achieve their mission, whether it’s to spread the word about incredible music, or to make transportation accessible to everyone, or to educate the world about the environment.
Our Engineering intern program gets better with every class of interns, and we’re gearing up to find the next group of engineers looking to tackle tough challenges that will ultimately help more people to work more productively. Learn more and see our open intern and new grad positions as they open on our Careers site.