As my co-founder Justin put it recently, “technology empowers small groups of passionate people with an astonishing degree of leverage to make the world a better place.” Like him, I believe that everyone should reflect carefully about whether they are using that leverage to the best possible effect, on something that matters to them deeply and that will have positive impact on the world. We’re not the only ones that feel this way.

There are so many vital and exciting projects that groups of people are working on and, frankly, I wish I could work on all of them. I’d love to connect people through software, find the cure for cancer, solve global warming, make government more efficient, and build art.

While I can’t do all of these things at once, Asana provides the opportunity to play a role in each of them. If we succeed at our mission, the work we do here makes every one of those groups of people — and millions more — vastly more leveraged and efficient.

We are building the tools that empower those teams of people to move faster, think bigger, and focus their energy on the real work, instead of just the work about work. At Asana, we get to work together to provide that kind of value to every connected group of people in the world. The rest of the post will touch on a few of the areas in which that manifests.

Consumer Internet

“We were quickly able to eliminate the drudgery of sending update emails and reporting on progress in weekly meetings. Now, if I want to know what’s going on with a project or what the status of anything is, I just look at Asana and everything is instantly clear. Asana makes our process so much more efficient. It removes all the waste in communication.” – Rian Hunter, software engineer at Dropbox.

Our software helps run some of the hottest internet startups: Dropbox, Pinterest, Uber, Quora, Airbnb, and Foursquare, to name just a few. We depend on their products every day and, similarly, the teams behind them rely on us to more effortlessly and efficiently coordinate the progress towards their goals.

We consistently hear from these organizations that Asana enables them to become more ambitious, confident that our product will ensure they follow through on a big idea. As Ankit Agarwal, the CEO of Micello put it, “The difference since using Asana is very black and white. Before, projects wouldn’t have happened, and now, with Asana, they do.”

We also work with many of the other services like ourselves that support them, like KISSmetrics, GoodData, and Stripe.

Education

“Asana has enabled BASES to coordinate huge projects involving dozens of students and many moving parts without having to meet in person.” – Charles Janac, Vice President of Stanford Bases

After software companies, the largest category of users leveraging Asana is related one way or another to the university system. We see a variety of groups:

• Student organizations, such as the Undergraduate Council at Harvard and BASES and StartX at Stanford.
• Teachers and TAs, who use workspaces to create and manage complex curriculums for their courses, as well as communicate with their students.
• Online learning platforms, like UniversityNow and Springest.
• Education vendors, like Pearson Education and Blackboard.

Biotech

A few of our customers focus on curing diseases, like Emerald Therapeutics. One of the co-founders, DJ Kleinbaum, told us, “Thanks to Asana, I went from spending all of my time on management overhead to becoming a full-time contributor to the science.”

The world is better off with DJ leveraging his time on science, rather than project management.

Sustainability

The sustainability problems we face in the 21st century are really important and really, really big. So big that they can only be solved through the combined efforts of many groups working on different pieces of the problem.

One of our favorite examples among our customers is the team at Synthetic Genomics, which is developing new carbon-free fuels and environmentally-friendly pesticides and fertilizers. More locally, the marine biologists at Aquarium of the Bay work to raise awareness about threats to members of the S.F. bay ecosystem.

Non-profits

“We use Asana to organize nearly every critical function – from funding to communications to internal finance to program expansion. We’ve eliminated redundancy, miscommunication and confusion about priorities.

With Asana providing a clear trajectory for the work we do, we’ve become more disciplined in our decision making and have magnified the volume and velocity of our output. I have to say that the difference has been mind-blowing.” – Mark Arnoldy, Executive Director, Nyaya Health

One of the success stories we’re most proud of is Nyaya Health, an incredible organization that serves the poor in rural Nepal.

When Nyaya came by Asana to talk to us about how they used the product to manage a highly distributed team, we were puzzled by some completed tasks that seemed to correspond to patients. Justin asked about this in the meeting. “Oh, that’s easy to explain.” replied Mark. “Those people have been cured.”

Asana – The ultimate meta-problem

Finally, Asana helps Asana help our customers do great things. For everything from meeting agendas to bug tracking to the snacks we store in the kitchen, we depend on our own system to get things done. So when we make our product better, we feel the benefit immediately ourselves.

Every time we talk to a new customer, we learn a new way that we’re enabling a team to succeed. By helping people work together more easily, we make it more effortless for groups to coordinate their collective action, so that they can achieve their goals and manifest the missions that drive them. In the next few years, we’ll reach millions of people working in groups to improve the world we all share. Through them, we’ll improve the lives of every person on the planet.

Asana’s customer experience is make-or-break. If our customers love and evangelize our product to their colleagues and friends, we get a chance to win our market. If they have a bad experience, we’re in trouble. Because Asana is so intensely focused on the experience of our customers, we’re trying a different approach to customer and product support. We call it User Operations, or UO, for short.

In this approach, we strive to strike a balance of daily customer interactions – like answering tickets – and longer-term projects – like writing help documentation and building reporting systems. We work with engineers to design and build tools that help us do our jobs. We reciprocate that help by using these tools to investigate bugs and other product issues that might otherwise take up a lot of the engineers’ time.

The way we do things helps to avoid UO burnout, but the main benefit is that we can collaborate closely with the Product Team, ensuring that the customer voice plays a key role in product development.

Becoming an invaluable source of product feedback

When I talk to other people who work in support, I often hear complaints that the product team doesn’t listen. For example, the Support Team will have taken a week to put together a huge and thorough report on issues customers are having with the product. This report will include detailed solutions, and the Product Team will ignore all of it. Then the Product Team will go and do the same kind of research all over again.

One interpretation may be that the Product Team just doesn’t trust the Support Team’s analysis, but I think it’s actually because non-product teams find it easier to suggest solutions, rather than frame problems in ways that help Product do its job.

I have found that the best way to approach this issue is to treat the product team like our client. When we, as a support team, adjusted our lens in this way, we (and the customer voice we represent) instantly became more integrated in the product development process. I believe that through this simple perspective shift (and a bit of empathy and understanding) any modern Support Team can become an invaluable source of input to Product.

At Asana, this collaboration has become a two-way street: we ask what the Product Team wants to know; they give us a heads up to look for specific issues that might come up around a launch. Later, when they are trying to figure out how to prioritize new features, they can come to us to get a sense of their demand.

This has became a continual process that happens on a weekly (even daily) basis. It keeps everyone engaged and flexible, and gives UO variety in our work.

How using Asana integrates UO with the rest of the team

Because our entire company uses Asana, our software provides us a way to distribute knowledge in any direction, to any part of the company. Whether it’s in reporting specific issues to the product team, helping engineers investigate bugs, or sharing ideas for help content with the marketing team, Asana helps UO offer our deep understanding of our customers’ experiences to every part of the organization.

UO can file customer bug reports with reproduction steps in an Asana task. PMs and Engineers can be added as followers and help prioritize the task. The bug’s task can then be Hypertext linked to other relevant existing tasks for more context. We can have discussions in comments about how we’ll fix the root issue and when we expect that to happen. UO can see the process and know exactly when we should follow up with the customers.

We also use an Asana project to distribute weekly reports of customer interactions to the product, sales and marketing teams. These reports come from a combination of automated scripts running on our ticketing system and manual interpretation. They contain both quantitative and qualitative information to give a more complete picture of the customer experience.

By using a combination of cross-functional teamwork, custom-developed tools and the Asana product, we have moved away from the traditional, isolated support model. We have become a more integrated and valuable support organization that has meaningful input into the product development process.

At the end of every “Episode” at Asana, I write an “End Of Episode Summary” that I share with the entire team. In the spirit of transparency, we have started to make these summaries public. You can read more about why we do this here.

In Episode 6, we finished the transition from executing a series of short projects to organizing into longer-running initiatives. In addition to the existing Performance program, we created roadmaps focused on Growth, Big Teams, and Mobile. Even though we may not have teams staffed for them in every episode going forward, these programs will endure and we’ve taken the first big steps down each of them.

We’ve also matured on the operations side. This is the first episode where we really had a complete marketing team, now that Justin K and Jim have joined us and ramped up. Together with Dan, Kenny, and a lot of outside help we’ve relaunched our marketing site, developed new tools, scaled up our SEM program, and more. We also kicked off a real, scalable account management program, with Michael and Jerry working closely with our best customers to make them even more successful and help them spread Asana to other teams in their company.

We experimented with our process this episode as well, holding Polish and Grease weeks for the first time and a longer hackathon too. In some ways, these were disruptive to our pace (exacerbated by being clustered around the holidays), but we’re excited to try again in E7 with an improved schedule. In spite of that drawback, these were periods of high energy and productivity and proved yet again that we can produce a lot of value in a short amount of time when we focus our efforts.

Finally, while the team did not grow very much larger this episode, we did grow closer together. We vacationed as a family in Monterey, we danced at Nihon, and – perhaps most importantly – we <3’d each other’s comments for the very first time.

Read the entire End of Episode 6 Summary.

At Asana, we have a rule: no meetings on Wednesdays. In fact, we call Wednesdays at Asana “No Meeting Wednesdays” or “NMW” for short.

The high level goal of NMW is to ensure that everyone gets a large block of time each week to do focused, heads-down work. The justification is well articulated in a now famous Paul Graham article: Maker’s Schedule, Manager’s Schedule. The gist is that makers suffer greatly from interrupts in their flow time. Managers are generally used to having a schedule-driven day, so it’s easy for them to throw a disruption into somebody else’s calendar. Makers also do this to each other. And unlike many companies, at Asana we generally want our managers to be makers some of the time as well, so they need a structure that ensures they get some flow time too.

What are appropriate exceptions to the rule?

The exceptions that comes up most often are exogenous timing constraints of some kind. For example, a job candidate might only be able to do an interview on a Wednesday, in which case we’re willing to let their schedule take priority over ours.

Sometimes, people on the team may also decide they want to work directly with someone else on a project (e.g. pair coding). This may still be worth avoiding somewhat to achieve the high level goal, but not totally. Often, this is necessary to unblock someone else, which is another form of exogenous time constraint in the end. And sometimes teaming up is just what you both need to do to finish your highest priority work. That’s ok, too.

Essentially, we encourage our team to just use judgement, but please think carefully, and at least try hard to avoid meeting on Wednesdays.

What if people don’t want to participate?

This would be ok, except that by definition a meeting involves someone else, too. It’s tempting to say “well they can just push back if they want to”, but it is easy to imagine situations where it wouldn’t feel culturally acceptable to do so, or an individual wouldn’t feel confident enough (e.g. a newer asana). So basically there is a slippery slope here and thus we want to be very (but not 100%) consistent.

Fittingly, this article was written on a Wednesday.

One of Asana’s traditions is the Learning Lunch, where members of their team share their personal expertise with each other in a casual setting. We move fast at Asana, so I appreciated being able to take the time to put together a little talk on typography in between design projects.

Typography is the study of the way typefaces (or fonts) are designed. Pretty much all the text you see in the outside world has been consciously put together to communicate some concept or another: everything from the labels on the food in your fridge to the major advertising campaigns you see during the Super Bowl.

The fonts we use today have their roots in the earliest forms of writing: handwriting (which developed into calligraphy) and carving on stone walls and tablets. These beginnings have spawned a dizzying array of typeface choices, and the choice you make can have dramatic effects on how your writing is perceived: Do you use a showy font that will instill emotion – the way brands choose fonts in their logos? Or do you use a beautifully simple font that will keep the focus on your message – the way newspapers use the same font regardless of tone?

Share this video with anyone who would be interested in the personalities of different typefaces, and how to use them in compelling, readable text.

If you liked this video, I’ve also spoken about our design process at Asana

This is the status quo at many a fast-moving startup: new engineers plunge into their positions bracing for a harsh reality. Fresh from an environment in which they were confident in their day-to-day work, they must hope to succeed in spite of gnarly legacy code, inadequate documentation, unintuitive raw tools and processes, and co-workers that help only reluctantly (if at all) because they are too busy. It is an awful first impression.

But paying careful attention to the on-boarding experience pays dividends, and is a key to transforming new engineers into strong, effective contributors. Positive patterns are easier to establish early on, not once the engineer has settled into a routine.

At Asana, we strive to build a culture centered on focus, productivity, growth and development—and that starts on day one, not some unspecified time when you become a “real” employee. We’ve put a lot of thought into our on-boarding process, which we’ll lay out below.

Minimize Chores

The first step is to remove as many rote tasks as possible from the new engineer’s list of responsibilities. We want him or her to focus on being a member of the organization, not on doing chores.

To facilitate this process, we have all of the components of their workstation acquired and set up ahead of time. We give them a $10,000 budget to customize it and then get them what they need before they show up. In the days before their first day of work, we set up their desk, install a standard disk image and run a standard setup script on their machine. All that’s left are the unavoidable personal customizations.

The goal of the whole operation is to ensure that the engineer doesn’t spend most of their first day “setting up their workspace.” We have much bigger plans for them.

My Buddy And Me

Those bigger plans start with a buddy. Each new engineer is paired up with a colleague with at least several months of tenure at Asana. For the next few weeks, this buddy will be be the primary person responsible for the new hire’s experience.

The buddy system provides benefit in two ways:

• New hires never have to wonder “who should I ask” and “is it worth taking this person’s time?” When we pair the new engineer with his or her buddy, we clearly communicate that we expect the buddy to spend a significant amount of time and energy on the onboarding process. Meanwhile, we give buddies the leeway they need to reduce their other commitments.
• It puts a single Directly Responsible Individual in charge of the new hire’s experience. Because buddies are invested in the process, they notice when the new hire is struggling with a problem. They facilitate discussions with experts on the team. They spend extra time pair-coding. Since someone is tasked with paying attention, it’s much easier to optimize the experience.

The buddy system also creates explicit opportunities for the new engineer to give feedback to the organization. New hires provide unique value: the ability to see the organization without the curse of knowledge. They cycle in new ideas and help prevent institutionalized biases. Valuing a new hire’s opinions early on sets the tone for their future contributions.

Adding Value On Day One

We have a rule at Asana that all new engineers must ship something on their first day. It could be a tiny product improvement, or a fix to a bug or a typo—anything. But it has to get out to production.

This practice is part of a commitment to continuous deployment and is inspired by other companies who have done the same. The rule serves multiple purposes:

• Demonstrates the entire lifecycle of a change to the software, from idea to launch.
• Provides confidence to the new hire around putting code in front of users. The worst that happens is something actually breaks, the code is quickly reverted, and everything’s okay again.
• Re-enforces the culture of continuous deployment within the organization, which has many of its own benefits.

Meet the Tech and the Team

A lot of what we accomplish together is grounded in trust and in our working relationships. Good tools (like Asana) facilitate these relationships, but are not replacements for them. We kickstart our fellow engineers’ effectiveness by seeding their relationships early on.

During the new hire’s first few weeks, the buddy schedules a series of learning sessions on various engineering topics, such as a walkthrough of our codebase, our cluster architecture, our datastore, reactivity, our testing framework, and so on. Each session is a one-on-one with another engineer.

Like many processes at Asana, the functions of these sessions are stacked, yielding many different benefits from one activity:

• The session leader and the new hire get one-on-one time to discuss something technical, establishing a relationship.
• The session leader gets to exercise being an authority, a component of developing leadership.
• The new hire gets high-quality information about a topic highly relevant to their work.

Of course, to scale our knowledge transfer across all employees (not just new hires) we also maintain a solid base of internal documentation. And each new hire is assigned one of the sessions that had inadequate written coverage, and cooperates with the expert to write up what they’ve learned. This process distributes the onerous chore of documentation, and helps us build our knowledge base over time.

The Starter Project

After a new hire has been exposed to an organization’s principles, tools, and and processes, there is often still a sizable gap between learning and synthesis. Many organizations are content to let this gap close incidentally, in fits and starts, wherever the engineer happens to be focusing their attention at the moment. While prioritizing learning based on needs is a passable default, we think introducing some core concepts in a safer environment can be more effective.

To that end, every new hire gets the same starter project: to build a small chat application using Luna, our in-house framework. They are expected to spend about 2-3 days working on it. The project is fairly open-ended, though the engineer is given lots of hints about things they can try building.

We designed the chat project to expose new engineers first-hand to many of the core concepts of building an application on our framework. The project’s open-ended nature allows engineers to direct their own exploration of the system. Since building a chat app on Luna is very similar to the day-to-day work on Asana, the skills the new engineers learn are directly transferrable. However, because the scope is much smaller and the environment more controlled, the engineer can learn the concepts more easily, without distraction.

Great Success

The benefits of our approach are real: our new engineers tell us that they were invigorated by their on-boarding experience, instead of exhausted, and they are excited by how quickly they become productive. Though our on-boarding process requires a lot of upfront energy, we’ve found that it pays to think carefully about how a new engineer is introduced to the organization, and how the experience might shape their mental model of the company.

They are, after all, its future.

Dustin and I started Asana to bring great product design, great user experience, and even beauty to a place they haven’t gone before — into the part of people’s lives where we spend most of our days, contribute to the world, and do great things.

Back at Facebook, we felt constantly stymied by the friction and overhead of coordination. We tried everything. But from email to expensive enterprise software, existing solutions were too hard to use, or cumbersome, or poorly considered, or just plain ugly. This was shocking to us: these are the tools we all use at work all day. There had to be a better way.

Great user experience is, ultimately, Asana’s raison d’etre.

We’re now looking to add one more person to our talented four-member UX/Product Design team. Someone who is looking for a big challenge to work on a fascinating design problem with a potential for positive world impact, in an environment that’s optimized for turning ideas into reality with speed and joy.

The Impact You Can Have

Enable human achievement. From skyscrapers to software, from vaccines to space travel, greatness is the fruit of human collaboration, of groups of people with a shared vision working together. But coordination is notoriously difficult. That’s why human progress is basically the story of improving the technology of coordination: language, writing, telephones, and email increase the scope of what can accomplish. By re-imagining how teams work together, we want Asana to be the next step in unlocking human potential.

Already, Asana has customers who are building great businesses, curing disease, alleviating poverty, and building large-scale art. Asana isn’t just making them incrementally more efficient; many say it’s fundamentally changed the kinds of goals they can accomplish.

By designing tools that make everyone more effective, we get to play a small part in all of their goals, from curing cancer to helping Dropbox cross the 100M user mark.

Create happiness. I don’t know a single knowledge worker who doesn’t feel overwhelmed and stressed by information overload. How do we create a world where we feel calm and in control — aware of just the information we need and undistracted by all else?

Eliminate drudgery. I often ask people how much of their workday they spend on this “work about work” — like sifting through low-priority email or sitting through status meetings — and frequently hear answers like “70%.” This isn’t just time-consuming; it’s soul-sucking. We believe software can automate most of it, and make all of our lives better.

Solve a universal problem. “Business software” conjures images of faceless IT department in gray buildings, but this is really about software for people, when they’re at work. People deserve great design, not just when they go home, but from 9 to 5, or 10 to 10. There’s an untapped opportunity to build software environments that are beautiful, thoughtful, and humane — particularly important for Asana, which you leave a tab open for and interact with all day.

Inspire love. The upshot is that our core users love Asana. They send us love letters and marriage proposals. They love it in a way that was formerly unimaginable for “business software.” We’re making emotional in-roads into a part of people’s lives they really care about: How do I accomplish my life goals? How do I actualize my potential?

This is a great start. Now we want to make Asana useful for and used by hundreds of millions of people around the world.

The Environment You Can Work In

To help us achieve that impact, we’ve been very mindful about creating a great culture and a great design team.

Design-driven. Asana is a company driven by vision and design, not A/B tests. We look at data, but aren’t slaves to it. We take customer requests seriously, but we interpret them in the context of our larger vision. This vision is developed to a large extent by our design team.

Size & Ownership. At four designers, the team is still very small, especially relative to the amount of functionality in the product. It’s big enough that you have peers to bounce ideas off, but small enough that every person is working on meaty projects that are essential to our roadmap. Our next designer will have ownership on big parts of the product, and even the opportunity to influence the team’s culture and process.

A mindful approach. We value mindfulness and reflection, and are constantly finding ways to improve our process. (Recently we’ve experimented with design sprints.) It’s a highly collaborative environment (including weekly team-wide design critiques), but it also leaves space to be alone when it’s time to do creative flow work.

Mutual mentorship. The team is structured around everyone helping everyone improve their craft.

Great engineering. Asana has a phenomenal engineering team. We look for design-minded engineers, who work closely with designers to bring ideas to life. Working relationships are strong and frictionless. Both the design and the engineering teams have a culture of pride and craftsmanship in getting the details right, but also in moving quickly. We push new code every day, and have invested a lot in Luna, our proprietary technology stack that enables us to go from prototype to production very quickly. The result of that is that it’s not uncommon for someone to have an idea in the morning, design it in the afternoon, and ship it that evening.

The Design Problems You Can Solve

Asana’s day-to-day design challenges require inventing ways to deliver great experiences that strike a right balance between important but seemingly-contradictory impulses. Sometimes balance entails compromise, but we strive for clever solutions that achieve the best of both worlds.

Power and simplicity. Asana enables people to communicate in rich sophisticated ways that weren’t possible before, and to tackle complex goals with many people and moving parts. Delivering this power in a way that’s simple to understand is a fascinating problem.

Efficiency and emotion. Knowledge work is stressful. We spend a lot of time asking: How can we make productivity software that feels warm, engaging, and inviting? How do we create emotional connections not only between Asana and its users, but also among teammates — to help them “feel like a team”?

Power users and casual users. Asana must work for everyone on a team, from power users and project managers to people still getting used to Gmail. How do you give power users a high-powered command center while giving normal users something usable and pleasant? How do you empower them to work at the rate they think, to minimize the latency between having a thought and the computer understanding it? We optimize interfaces down to individual mouse clicks, obsessed with achieving the ultimate efficiency.

Unobtrusiveness and beauty. The user is here to focus on their work, so it’s critical to stay out of their way. On the other hand, users spend so much time living in Asana, it should be beautiful and emotionally appealing in its own right. How do you achieve both?

Information density and serenity. Eye movement is the fastest form of navigation, and it’s useful to be able to process and manage lots of information on one screen. Building something dense — not only in static information but also in interactive elements — that is also simple, clear, and beautiful is hard. There are few other products you can work on as a designer that are as rich with information as Asana.

The Opportunity

Building a great design team is one of the most important things we do, and my hope in writing this essay is to connect with the perfect fit for the role of the fifth Asana designer. Someone who’s stirred by the opportunity to solve intellectually-meaty design challenges, in the service of improving our world. This is a really special opportunity for the right person, to help design the future of how people work together. If you are or know that person, send me an email.
.

Enabling “flow” is critical to the way we work. Flow allows us to have time to think, take new projects from A-Z, and to dive deeper into work without meetings or interruptions that may distract us from completing our goals. Once every episode, we run a hackathon at Asana. We set aside time and encourage everyone really dig into an unplanned project that really excites them. This gives the team space to tackle its most fun and even crazy ideas, to flow.

The idea is to allow for willful intention without attachment to results: if you want to learn a new programming language, design UI for the first time, or build something new, go right ahead. Learn that code, do that design, build that feature. If none of it pans out, no worries, we still ♥ you.

Normally, our hackathons last just a couple of days. This time, we decided to change it up a bit, and built a longer hackathon around Thanksgiving. For six days, from November 15th – 20, we held Thankshacking at Asana. This was the longest hackathon we’ve had since we first became a team.

Because of the hackathon’s length, we made sure to strive for a balance of work and play: we integrated more team bonding experiences, including a weekend feast with home cooked meals, a movie night (we watched “Sneakers”) and a board game night to break up the long work days.

We made it clear that working over the weekend was optional, but included a rock climbing trip and late night pizza to break up the hard work. It worked. As Alex Davies, one our newest engineers put it, “The flexibility and fun aspect is what made this hackathon more enjoyable and more relaxed.”

Here’s what we did to make the hackathon a success:

• We hosted a fun activity every night of the hackathon. This made our office an unusually fun place that week.
• We gave everyone on the team full autonomy.
• We made sure everyone understood there was no pressure to ship.

The results were great. This is what happened:

• Even though weekend work wasn’t mandated, a large percentage of our team, including non-engineers, worked over the weekend.
• I’ve never designed anything in my life, but the icons I designed for one of my teammate’s projects got approved by two of our actual designers.
• One of our engineers took his original project even further than he had planned and built a totally new feature. He said the total autonomy made him even more creative.
• One person on our marketing team mocked up a major new page for the website and another taught himself Ruby.

Hackathons are fairly common on the startup scene, and they usually go like this: the engineering team takes somewhere from 24-48 hours to work like crazy on (usually) unplanned features and/or new product ideas. Pizza, beer, ping-pong, and all-nighters are often involved.

But there are other ways to do hackathons. They don’t have to be 24-48 hour sprints. They can be easier on the body, yet more focused and intense at the same time.

Or, at least, we like to think so.

Last week, we wrote about Polish Week at Asana from the perspective of the changes we made to the product: the new features we launched and the bugs we squashed in one intense week of work.

Today, I thought I’d write about how we think about product polish in general and how we planned and executed a week dedicated entirely to it: Polish Week.

How We Think About Polish

Pragmatic Craftsmanship is one of Asana’s core values, and for good reason: we believe polish and craftsmanship are vital components of a well-designed product. As a wide range of consumer focused technology companies have demonstrated, applying meticulous care to even the tiniest details can help foster mass appeal (and love) for a product and brand. At Asana, we want to ensure that users love using our product day-in and day-out, so we strive to build a product that shines.

To help achieve that goal, we decided to take a week away from our normal schedule, break out the boot black and the shine box and focus entirely on polish. Originally, this would be known as “Polish Kielbasa” Week (for Polish, Kraftmanship, Interesting, Exciting Lame or Boring And Small Avenues), but we shortened it to “Polish Week” because nobody got the Kielbasa part.

Polish Week Goes Live

While we always maintain a strict quality bar before we release anything to the public, we justified setting aside a week dedicated to polish because it gives us time to work on features and bugs that normally wouldn’t get addressed. Improving features that we’ve already launched also gives us the benefit of hindsight: after a feature has been launched, we have a better sense of the issues that needs to be addressed. We also catch problems that we might have missed at launch.

Scoping The Week

While it was tempting to work on other types of projects, we agreed to limit the scope of the week to the parts of Asana that are visible to users. In the future, we plan to hold a Polish Week every episode, though we may decide to shorten the timeframe and/or expand the scope to a larger range of projects. But this time, we decided to focus on delivering immediate, noticeable value to our users.

Communicating The High Level Goals

We wanted everyone at the company to know what we were striving for, so we articulated a set of goals for the week:

• Polish the product. See above for why this is important.
• Focus on the customer. Focusing the entire team on user-facing issues for a week would be a strong reminder that all of our work is ultimately in service of our customers. It gives us perspective when we work on non-product work at other times.
• Unlock value. We knew that if we just spent a little more time on some features, they could become much more useful to everyone. We wanted this week to be about taking these features from good to great.
• Do work that wouldn’t normally get done. We constrained Polish Week to work on large projects that don’t fit into our normal schedule, as well as features and bugs that keep falling through the cracks.
• Ship by the end of the week. This targeted mentality allowed us to work on projects that we knew could be done in a single week and still generate tangible value for our users.
• Build camaraderie. We wanted our entire team, including product engineers, infrastructure engineers, designers, and operations team, to pitch in work on polish. Even our chefs got in on the action, cooking up kielbasa, pierogies and other Polish food, just in case anyone forgot what we were doing.

Setting Targets

We wanted to complete the highest priority work, but we also wanted to give people the autonomy to work on the things that mattered the most to them (including the “pet” bugs that matter a lot to one person, but are sometimes hard to justify to others). So we framed a two-part goal: one around quantity, the other around quality.

For the first, we estimated how much work the team could do in a single week and came up with an ambitious goal of 55 completed tasks. (Each task was a feature, bug or other improvement.) For the second, we set a goal of completing all of our highest priority work. The way we framed our goals meant that everyone would be working on high-priority tasks for roughly ⅔ of their time, and still have ⅓ of their time left over to work on any other polish tasks that interested them.

Making It Happen

When the time came, everyone put their heads down to work on Polish Week projects. Of course, we still did some day-to-day work: our User Ops team still answered support requests; the on-call engineers still solved site issues; and we still conducted a number of candidate interviews. However, all other work was put on hold so the team could focus on polish.

Demos!

We wanted to give people a chance to show off their work, so at the end of the week we held demos. Every member of the team had something to show. It was impressive to see how much our team was able to achieve within a week, and how much better our product feels as a result.

Polish, Polish, Everywhere

We knew it would be an intense week, but we also wanted to keep it fun, so we came up with a range of ways to polish-themed ways to celebrate the work we were doing:

• We ate Polish food. For lunch the first day, we consumed kielbasa, sauerkraut, pierogies, and meat & potato stew.
• We “polished” our faces. We got some neon face paint and made like kids at the county fair. Some people opted for subtle, others opted for intense.
• We polished our nails. Some members of the team polished a nail for each Polish Week task they completed.
• We ate unpolished Jelly beans. The Jelly Belly factory sells misshaped jelly beans that didn’t make the quality control cut. We ate many of them.
• We polished off some scotch. Scotch may not be Polish, but it sure is delicious.
• We listened to the Polish National Anthem. We would have sung along, but we didn’t know any of the words.
• We polished our outfits. Some people dressed in suits, some people dressed in very shiny clothing. Others were just polished in spirit.

All-in-all, Polish Week was fantastic. We hope you enjoy the results of our work as much as we enjoyed doing it.

If you’d like to stay on top of product updates, tips and other Asana content, you should find us on Twitter, Facebook, and Google+.

One week before our public launch last November, we knew we had only a few days left before a lot of people would be seeing Asana for the first time. So, during that last week, we put our larger roadmap projects on hold and focused on making lots of small improvements to the product. We squashed bugs, sanded down rough interactions and added new visual touches, redesigned the signup pages and built a new support site from scratch. It was a fun and satisfying week for our team, and by the end, the improvements combined together to produce a substantially better experience for our new customers.

When we work on a mission and product as ambitious as Asana, it’s important to spend most of our energy on bold changes (like Inbox, our new iPhone app and Subtasks). However, we recognize that the finer details of a product are what bring delight to our users, so we built in time this episode to spend a week doing only product polish. We chose last week (almost the same dates as last year) for our Polish Week, and spent it in a fluid, fast-moving dedication to the really small stuff. One of the rules of Polish Week is that your code had to ship – so all of the things on this list are already in your hands. Taken together, we think the 60+ small changes we made over the week add up to a big step up in Asana’s, well, polish. We hope you enjoy them as much as we do.

Image Thumbnails. We added image thumbnails to task comments and the Inbox. Whenever someone uploads an image (jpg, png, gif) to a task, it will appear as a small thumbnail in the task’s comments and as a larger image in the Inbox.

Drag-And-Drop Subtasks. We’ve made it easy to make an existing task into a subtask (and vice-versa). To demote an existing task to a subtask, simply grab it by clicking on the “drag handle” on the left edge of the task, and drag it into the subtasks area of the right pane for the parent task and drop it in. To promote a subtask into a standalone task, grab it from the subtask area and drag it into the center pane.

Project Notes in the Center Pane. We moved project notes from the right pane to a new field under the project title in the center pane. With this change, every project’s notes are always visible to your team, giving you a great place to explain what the project is, how it’s organized, and how it should be used. This notes area also supports Hypertext, so you can conveniently “@-link” to relevant people, projects and tags.

As part of this change, we decided to remove comments at the project level. If you had projects with existing project-level comments, don’t worry, we didn’t delete them. They are now in a completed task entitled “Project Comments: <Name of the Project>”. You can find the task in the project itself or search for it.

Better Firefox Support. We now support copying and pasting a list into Asana in Firefox (Chrome has always had this feature). We also play nicer with Firefox keyboard shortcuts.

Stripping email subject prefixes. We strip out all the “Fwd:” and “Re:” prefixes from the subject line of emails you forward to x@mail.asana.com, so the subject becomes a cleaner task title.

Copying tasks with links. When you highlight and copy (using CMD-C) a list of tasks, the copied tasks include hyperlinks to the Asana tasks, so you can include them in other documents or emails.

Many more improvements, including…

• Subtasks and Task Comments are now included when you print your project list.
• A small circle before the name in the browser tab indicates a new Inbox notification for the workspace.
• You can add a task to multiple projects when creating it via the Asana API, all with one API call.
• Search and Hypertext don’t show Archived projects in results by default.
• Email address links work in comments and notes.
• Clicking the Asana logo takes you to your My Tasks view.
• Clearer indication of read/unread state in the Inbox.
• Your Later list of tasks is now collapsed by default in your My Tasks view.
• Projects that are private to you now show the privacy icon when you type them in the Add Project field.
• Better support for right-to-left languages.
• Empty tasks don’t credit the creator until someone adds content to it.
• Multiple “<3"s now print as multiple hearts in comments (popular in the Asana office)

If you have other ideas for product polish, leave us a comment, and we’ll capture it for the next Polish Week at Asana.