In the relatively new market of collaborative work management tools, Asana stands alone as a beautifully crafted, enterprise-ready, scalable, and intuitive work management solution that supports clients across the globe. In its most basic sense, Asana adds structure to teams trying to accomplishing work, allowing organizations to mature beyond simple task lists, Excel spreadsheets, or email threads.

As someone who has worked extensively in the project portfolio management space (PPM), the introduction of "collaborative work management" tools have started to expand the scope, capabilities, and depth of tools in the marketplace that seek to meet changing demands from CIO's and beyond. So much so, Forrester tracks tools across multiple categories: strategic portfolio management tools and collaborative work management tools (for the enterprise). While I've traditionally worked with tools in the strategic portfolio management tool space, such as CA PPM, much of my recent experience has been with tools such as Clarizen or ServiceNow (which sit in the collaborative work management space).  ServiceNow is a particularly interesting use case because its product is so broad in capability, it lands in both categories above - and does them both well!

Nonetheless, this simple example is another data point in a shifting market, where tools are becoming more agile and reacting to what I'd call the "productization of IT". This is more so specific to the PPM tool space, but it stands to reason that while strategic tools shift to enhance work execution capabilities, then the same must be true in the other direction.

So where does Asana fit?

PPM Primer

Before understanding where Asana sits, it helps to understand some of the tenants, or capabilities, of PPM, and what they seek to enable in a mature organization.

  • Portfolio Management: managing the pipeline of work, planned and in-flight, with visibility to assess portfolio adherence to strategic objectives.
  • Demand Management: the process by which a request for work is initiated, usually including a business case, scoping, prioritization and fulfillment.
  • Project/ Program Management: managing individual streams of work; monitoring relative progress, understanding risk and issues, resourcing, and timelines.
  • Resource Management: the process by which an organization's labor is effectively utilized and deployed to meet dynamic project needs and timelines.
  • Results Management: a retrospective process, enabling organizations to learn, grow, and adapt from completed (or failed) work. (*this capability is difficult to mature and not usually a priority)

With this understanding, we can start to add structure to the types of activities each capability enables, and where it sits on a spectrum of "strategic" to "execution":

This loose diagram outlines a handful of activities, mapped to their PPM capability, and approximately correlated to a "scale" of enablement. For example, at the far left, the idea of an organization completing some sort of long range planning activity is very strategic, and usually resides in within a "portfolio management" capability. This is not unlike how Asana builds their own strategy (more below on this).

Similarly, on the far right, task management is as close to actual work execution as you can get, and is firmly representative of the "project management" capability of PPM.

Asana in the Marketplace

As a "collaborative work management" tool, Asana sits very firmly on an execution front, and offers a host of features that support team members ability to track and execute work. On the scale above, I would place Asana about as far right as you can go. And this isn't a slight - what Asana does, it does exceptionally well, and is arguably a world leader in. While I've never used Asana in the wild, I know my company does (plus another 50,000), and they clearly derive a lot of benefit from its ability to track tasks, milestones, visually show progress with calendars and timelines, and keep everyone in sync, limiting a need for email conversations.

As a leader in "project management", Asana has and will continue to introduce features that push it closer to the "strategy" scale above. In doing so, Asana is broadening the market of its tool, increasing the value of the application more broadly across an entire organization.

So the remaining question for Asana management and product teams: how do we enhance our product to better meet the "strategic" needs of our clients?

Making Asana more Strategic

I've played around in my environment of Asana for only about a week now. I know it's not nearly enough time to fully judge a tool, but I felt that I was able to explore the tool as would a small startup looking for basic task management. In that world - it's a nifty little tool, fast, smooth, and pretty (and most enterprise tools aren't, so this is a big win). It has struck a near perfect balance of usability and function that few products are able to do.

With that being said, there's one big limitation: there are few, if any, strategic components of the tool that make it valuable across the enterprise.

For most organizations, perhaps that's not why they subscribe to using a tool like Asana. However for the remainder that skip over it because it doesn't cohesively support the scale of work management (seen above), Asana may only be seen as supplemental tool, and not one that can comprehensive redefine how an organization works.

This weakness is an opportunity: Asana has an ability to extend its brand, reach, and impact by growing the capabilities of their product to support more strategy and planning activities, rather than just execution. I believe a good place to start is rounding out Asana's project management capabilities.

Discover: Comprehensive Project Management

In enterprise, project management is a big deal. IT projects fail all the time, for starters. Modern businesses demand visibility into their portfolios and in-flight projects, data to make informed and strategic decisions about project priority, and the ability to deploy resources efficiently and accurately. While there are a host of capabilities that make this possible, an excellent starting point is status reporting. Effective status reporting enables timely visibility to stakeholders, implicitly provides approvals and oversight on progress, manages risks and issues as they arise, and keeps a project on track.

Dashboards? (click to expand)
I upgraded my basic Asana instance to the business instance (in the trial) in order to see what I was missing out on. As I read through the doc's, I came across Dashboard's. The functionality sounds good - an ability to view status of multiple projects, like you might expect from a portfolio, with some level of analytics. However, no matter how hard I tried, I couldn't find this page. Even clicking the direct link took me to portfolios.

This link didn't work as expected.
It's not clear to me if this is new functionality that isn't fully rolled out, or depreciated and not removed from documentation. Regardless, it seems like a great step towards adding executive visibility options to Asana, but it hasn't made a full debut that I can investigate. It is very cool though!

Asana includes functionality called "Progress", meant to act as a way for project managers to provide timely updates on their projects in an exceptionally concise manner:

"Progress" status update in Asana.

Simply provide a short write-up with the latest status, and select an overall status for your project. It's deceptively simple, includes options to "remind" users to update on a weekly basis, and has great integration throughout the app, including on the project itself as a sidebar card, and in a weekly status email for portfolios of projects.

Define: Progress v2

To make it clear: I love the existing options, but most companies have structure in place that would make it difficult to truly adopt this and find value. The interesting part here is that the help text provided ("What's been done? What's next? What's blocked?") is a really good approach for a status report. Let's break those down quickly:

  • What's been done? - In project management terms, what are the latest accomplishments of a project? These accomplishments are likely just the status of upcoming milestones. Why can't this form pre-populate recently completed milestones (or tasks) here?
  • What's next? - Another easy one: what are the upcoming milestones for this project? Can't this information be pre-populated if the project plan has been built correctly?
  • What's blocked? - I liken this most to risks and issues. If a task if off track, you put milestones at risk, and thus the project. Risks to a project can either be mitigated or turned into issues that need to be resolved. Since Asana has no formal ability to track risks/ issues, the only place they ever become visible is if a project manager lists them freely on this list.

While I like this list, you can start to see how it can be improved. To take it a step further, we might explore what else good status reports keep updates on:

  • Overall - Asana nails this with the overall indicator. However, imagine if you had other indicators that rolled up to the overall one based on rules?
  • Schedule - This is another way of saying is the project on track? Risks and issues can impact schedules, but changes to scope, resources, and even unforeseen events (such as employee sick days) can threaten a project's schedule.
  • Scope - While specific to larger, less defined projects, sometimes it's easy for projects to balloon in scope by adding/ changing requirements. Being able to assess the scope of a project in real time is valuable in understanding the health of a project.
  • Risks/ Issues - If there are formally raised risks or issues, this is a good time to disclose them. Leadership want to know what's blocking a project and what they can do to help.
  • Resources - Are project resources available and working as expected? Lengthy and large projects can suffer from resource availability for a host of reasons including PTO, vacations, sick days, jury duty, or even other project responsibilities.
  • Budget - Good projects are completed on time and on budget. If a project works on a budget, wouldn't you like to know how you're trending each week?
  • Accomplishments/ What's Next - Something discussed above and something Asana already requests through free entry, but can easily enough be auto-populated with milestones of certain criteria.

Design (fit): The Pyramid of Clarity

Jackie Bavaro, Asana's head of product, regularly provides insights into product-specific components of Asana on her blog. While I've enjoyed reading many articles she's posted on their PM blog, there's a specific article which gives insight into how Asana builds their product roadmap. What I particularly appreciate about the article is the breakdown where Jackie explains the difference in approach between the two companies she's worked at previously (Google and Microsoft).

She uses the two companies as examples to show how strategy and execution of work differed, and how Asana works to strike a balance between these two approaches. Ultimately, Jackie explains the concept of "The Pyramid of Clarity":

Source: Jackie Bavaro, How We Build Our Product Roadmap at Asana

I would encourage you to read Jackie's explanation of the pyramid, as it gives a lot of context to how ideas are structured. Jackie gives one example about how a challenge is routed from the bottom up, relying on the relatively more fixed objectives, strategy, and mission of near the top of the pyramid. I've transposed the example into a simple flow:

As Jackie explains in her post, this is the "mapping" a challenge or new idea would fit into. I've materially simplified the idea, but it remains consistent and inline with the pyramid of clarity from above.

Using Jackie's methodology, with the weakness I described above (executive value/ status reporting), I created a similar flow for understanding how (and if) this challenge fits the companies overall mission:

Challenge: how to make Asana more valuable to leadership?

If we think about where Asana fits in the landscape of other collaborative work tools, Asana exceeds in the execution component of work - the lowest level of execution. However, one area that is particularly underdeveloped is the reporting or status component of that work. When you consider the stakeholders at each level within an organization, there's varying "needs" of reporting, or status:

  • Team Member: how many tasks are on my plate today? Is there anything preventing me from doing my job?
  • Project Manager: are any tasks slipping? Risks/ issues? Are we at risk of missing deadlines?
  • Portfolio Manager: which of my projects are on track/ off track? Why? Budget/ resource/ schedule/ scope/ etc. Do they remain inline with the portfolio strategy?
  • Executive: is our investment proportionally delivering the expected value from the underlying portfolios of work?

With Asana's currently available status capabilities, project managers are left to largely manually report status in an unstructured manner (free text), with a single overarching identifier of a project - are we on track, at risk, or off track? (more detail on this later)

I particularly love the simplicity of this approach. However, I can't think of one Fortune 500 client I've worked with that would have executives appreciative of this approach. Lacking structure is both a great strength of fluid organizations, and a tremendous weakness to larger ones that rely on standardized approaches to keep projects moving.

So the question still remains, how we do we leverage all of the data Asana is producing and present it in a manner that is valuable all the way up the chain of leadership at any organization.

Key Result: more comprehensively report project status

While this isn't quite as quantifiable as doubling loading time, you can quantify the value of the existing "progress" functionality as a component of its usage. Some questions I would ask that could be baselined and measured:

  • What percentage of organizations actively utilize "Progress"?
  • What percentage of projects actively utilize "Progress"?
  • How often are status reports printed?
  • Of projects that use "progress", what is the average time between each update?
  • What percentage of users have enabled/ disabled the "remind me" function of status reporting?
  • What percentage of users have a title of "Manager", "Director", "Vice President", or "Chief" in their title? (it's my hypothesis that many of these levels do not directly receive value from Asana as it is today, so I'd expect this to be low, but grow if you can show value)

All of these quantifiable numbers point to ways that you can deliver more value to a broader group of users. If you don't make a team members job any harder/ more complicated, but you enable more visibility and transparency into the status of a project, you open up a whole new level of interaction with Asana.

Sidenote: Asana License Types (click to expand)
As a small side note, Asana currently doesn't differentiate with "types" of users. Billing is standard between any type of user - whether they are a team member, actively tracking tasks, or a project manager, who oversees progress. Finally, any level of executive is treated just the same as a team member, which at many organizations, is overkill. Perhaps a more broad challenge should be how Asana can broaden the scope of how they define a "user"... this might be changing their pricing model, however. I suspect there's a good chunk of this that already happens at the "enterprise" tier.

Objective: Increase product depth

I would imagine that at an Executive level at Asana, they are hard at work trying to figure out how to grow their share of the market. Many great products make reasonable expansions as they begin to mature in their original offerings, and it's not unrealistic to think Asana has started conversations on the topic.

For example, I had an opportunity to work with the product team at Clarizen (on behalf of a client) as they tried to build out the financial management capabilities of that tool. In the same vain, I can see from Asana's pricing page that resource management is coming soon. As a primary component of project portfolio management (PPM), I would expect that Asana is already in the mindset of finding ways to expand the depth and breadth of their tool.

As such, I would reasonably conclude that expanding the capabilities of Asana's status reporting (progress), would be in service to a company objective to increase the range of clients Asana can be used by, as well as a product objective to increase the capabilities of the tool to better support existing customers. A win-win.

Strategy: Make a product for all teams

This one is a little more straight forward that the last as we higher up the pyramid. Jackie describes in her post three primary "strategies" Asana works towards:

  1. Make a product that makes teamwork effortless
  2. Get that product to all teams
  3. Make Asana the best company at doing 1 & 2

In the context of increasing product depth, I would argue this is in service to 2) get that product to all teams. "All Teams" is just broad enough that I believe it covers the vertical hierarchy of teams, much more so than different execution teams (e.g. sales, marketing, IT, engineering, product, etc.)

So if you're designing new functionality that is specifically designed to enhance existing capabilities to deliver more value to project managers and executives, then you're most definitely contributing to the strategy to make a product for all teams.

Mission: Help humanity by enabling effortless work

I won't dwell on this once this mission and strategy are pretty fixed at Asana, and already fit nicely together. Since we've justified how our enhancement fits a key results, serves an objective, and aligns with a defined strategy, then I think we can agree this we are in service to Asana's broader mission.

Develop

I think there's a hundred different ways to solve this problem. The great part about working with teams where everyone is as dedicated to the product as you are, is you get a rich dialogue and discussion around any type of change, no matter how small. While I'd expect any such brainstorming/ design session to include a wall of sticky notes, sketches, and wire frames, I jumped a bit ahead and threw together a few simple ideas. I won't back these as the best approaches, but something to start a conversation.

1) More input detail

In this mock-up, I've added stoplight "indicators" to the many categories of a status report I described in the above section. While we've made a project managers job a bit more difficult, you're allowing them to quickly generalize the status of a project against a range of criteria, and you're doing it in a tangible, defined manner. Some other considerations:

  • What if the list of project attributes was customizable? Perhaps not all projects are concerned about scope, or budget. Could be simple enough to drop those fields.
  • You could auto-populate the stoplights based on last weeks selections, or make automatic selections based on other data. For example, if a certain amount of tasks are past-due, then "schedule" might be yellow/ red.
  • Have new tasks been added recently by a non-PM individual? Perhaps the scope is yellow.
  • Ultimately you can use the stop lights of this criteria to automatically determine overall status.

2) Status from a glance

Now that you've captured weekly detail on each of these items, you can show them right inline on the existing status report. In this mockup, I'll left the free text field for entering anything, but you can see icons relative to each of the items above. In this screenshots, risks/ issues is yellow and resources is yellow, but the overall project is still green. As an executive, this is infinitely more telling (more visibility!) about the health of a project, even though it's still green.

If the project suddenly goes yellow next week, that same executive won't be caught off guard and can quickly pinpoint the issue, without ever having to read a sentence. This is especially valuable because that free-text has no rules. The "current accomplishments" and "what's next" I've written above is in no way standard. Imagine the headache of a executive who has to read a dozen different summaries all formatted differently.

3) Risks and Issues as Objects

While Asana doesn't have a published data model, I'd venture that it's actually pretty simple: portfolios, projects, milestones, tasks, users, files. In theory, this hits all of the necessities for work management, but there's some notable items missing, specifically for projects: risks, issues, action items, and decisions (RAID).

In the mockup above, I've transposed risks and issues onto the project main page as sidebar "objects". Tracking risks and issues as their own records enable even basic levels of tracking, including assigning owners, mitigation dates, severity, and more. That information is now immediately actionable (trigger emails, promote follow-up), reportable, and trackable.

If projects can have templates to get started, doesn't it seem realistic that similar projects might suffer from the same risks? Tracking these allows such a deep level of visibility and reporting, you can prevent any project in the future from battling the same issues again.

Conclusion

Asana is a beautiful, collaborative work management tool that supports work execution well, but offers little functionality that provides strategic insight. While this isn't necessarily Asana's goal, I believe there are opportunities to mature product functionality (such as project status reporting) that would make it more valuable to leadership and executives that drive and support project work and execution. In doing so, Asana has an ability to become a more full featured product that works more comprehensively across a business, and cements itself even further as a critical business asset.