Isaac Souweine

This post first appeared on Flatbook’s Medium page  

Like all departments at Flatbook, our product and engineering teams rely heavily on Asana for task management and documentation. Though we fire up Google Docs often, Asana provides the center of gravity for our product development process. Over the past year of heavy usage, (Sprint 23 and counting), we’ve used Asana to support all major phases of our product cycle, from roadmapping and speccing to sprint planning and bug reporting. By centralizing our work within a single environment, we’ve managed to reduce complexity while maintaining structure. We’ve also found Asana’s features help us promote transparency and collaboration. While our product development processes are constantly evolving, we hope this snapshot of what we’ve built so far proves interesting, to other product teams using Asana, and to the larger conversation about the tools we use to build products.

Roadmaps

At Flatbook we build quarterly roadmaps. Naturally, each roadmap begins with an Asana project. At the top of the project are a few overview tasks, e.g., a list of key themes for the quarter. The rest of the project is a long list of features, one per task. The Asana interface is a hybrid of spreadsheet and wiki design patterns. This mixture turns out to be ideal for working on priority-based roadmaps. In the list view, features can be viewed as a whole and reordered with drag and drop or keystrokes. Tags and sections make the list more readable. In the detailed view, there is enough space and formatting options to allow for a terse but readable description of the feature.

Asana has also helped us make the roadmapping process more transparent and collaborative. Each feature/task in the roadmap has its own comment thread that lets stakeholders and engineers discuss and contribute. The sub-task system lets PMs request reviews or get input on open issues for a particular feature. And the hearts feature provides an easy way for anyone in the company to vote up a task that they like.

Here’s what the top of a typical roadmap project looks like:

Here’s the format for an individual feature:

Specs

Once prioritized, roadmap projects need to be specced. Again, we start by creating an Asana project. The top half of the project corresponds to what you might find in a Confluence page or Google doc, with sections such as KPIs, epic stories, and feature lists. The only difference is that these sections are split into individual tasks, allowing PMs to bring others into comment or review a specific section.

The bottom half of the spec is a command center for the speccing process itself — interviews to conduct, data to gather, meetings to hold. Because these are actual tasks meant to be closed, they are well suited to Asana’s core feature set. Each task can be assigned to the appropriate person and closed when complete. Comment threads allow for discussion within a task when appropriate.

Here’s what the top of a typical spec looks like:

Here’s the bottom half of a spec. Since this spec is old, most of the research tasks have been completed:

Stories and Sprints

The ultimate output of the speccing process is a set of user stories grouped together into a sprint. We track each sprint in a separate project. User stories are written in the description field and then given a summary headlin that shows in the list view. PMs work closely with engineers on story writing. The goal is for each story to communicate a clear sense of what a user needs and why she needs it, while leaving space for engineers to dictate how the need should be addressed.

When the stories for a project have been solidified, we run a poker planning session to bid them. Asana supports bidding by letting users add numbers in brackets next to each task. Highlighting a set of tasks produces a sum of all points in the tasks selected. The system is a bit awkward but functional. We use tags to make the list more scannable and to generate data (crunched in sheets) on the amount of engineering resources we are spending on each part of the business.

While the bulk of each sprint consists of stories and bugs, we also add documentation tasks at the top, such as sprint planning notes and debriefs. This easy integration of documentation and tasks is one of Asana’s great strengths, as it allows us to centralize planning and execution into a common interface.

Here’s what the top of a typical sprint looks like:

Here’s what it looks like to count points in a sprint:

Bugs and Feature Requests

The widespread adoption of Asana at Flatbook has made it easy for us to support bug reporting and feature requests. Once again, we begin with a project, called Tech Requests, Ideas and Bugs. (In fact, all teams at Flatbook have their own Requests and Ideas project). Anyone in the company can add a task to this project. We train stakeholders to write in story form and when to escalate bugs that need urgent attention. Urgent issues get fixed immediately or are triaged and added to the sprint. Less urgent bugs and all feature requests are triaged every two weeks or so and added to a sprint, the general backlog, a feature-specific backlog or an engineering backlog for refactoring and infrastructure issues. All bugs are tracked with a special tag so we can keep track of how many bugs we are fixing per sprint.

Asana’s system of task following and inbox updates has helped us ensure that bug fixing and feature development remain highly transparent. Stakeholders who have reported a bug or requested a feature receive updates in their Asana inbox as the request moves through the triage, backlog, sprint planning, and development phase. This steady stream of passive communication keeps stakeholders aware (if not always happy) and cuts down significantly on the need for proactive communication by PMs.

Here’s what our Requests and Ideas project looks like:

Conclusions

As Marshall McLuhan famously stated, “the medium is the message”. While McCluhan was writing about media, his claim seems equally relevant for the software and techniques that we use to develop products. Pivotal, Confluence + JIRA, Base Camp, Trello, Google sheets, paper index cards — the tools that a team chooses both reflect and enforce norms for how that team works. So — what message is contained inside the Asana interface? Over the past year, we’ve seen a few themes arise.

Rigorous Simplicity

Balancing the need for rigor vs. simplicity is one of the core tensions in contemporary product development. In Asana we feel this balance is maintained beautifully. On the side of rigor, Asana provides a robust interface that supports task management and documentation and can be massaged to address key product use cases like velocity tracking. On the side of simplicity, we love working with a single, cloud-based interface which forces brevity on the speccing side and leaves out the sort of powerful but often underused features that tend to clog up purpose-built tools like JIRA.

Transparency

Transparency is essential to a high functioning product organization. Stakeholders want to know how to engage with product team and what the team is working on. PMs and engineers want to maximize awareness across the company while easily looping folks into nitty gritty product questions when appropriate. With Asana we have a tool facilitates all of these use cases and more, with a strong emphasis on passive information flow.

Collaboration

Collaborative teams build better products. Asana’s core features help us foster a spirit of collaboration. The core principle of task ownership ensures that we have clear accountability around every user story, spec item, and qa task. Within each task, a discussion layer of comment threads, @ mentions and hearts allow for productive interaction between all interested parties. Augmented with a heavy dash of slack channels, we’ve found that Asana helps us foster solid teamwork both within our product organization and between product and the rest of the company.

Of course, building products with Asana is not all candy and daffodils. For all its great features, Asana is a general purpose tool. As such, it’s missing useful product development features such as velocity tracking and burndown charts. We also share the pain of many Asana users in terms of overall platform performance. (More servers, please?!) Overall, however, we find that Asana’s tool set and core design principles have been instrumental in helping us develop a product development process that we can believe in.