Background
Asana has a simple but effective product used for any task management platform, ranging from the workplace to design projects to college students. While each of these groups has different specific needs, Asana has chosen to make a homogenous platform to fit across every group, presumably to create a consistent brand and make deployment/development times much faster. To supplement the needs of big individual use cases, Asana has worked with third party developers to add integrations on top of the platform, such as GitHub for error task management.
Target Market For Additional Features
From a product perspective, building new features would be most useful if they fit across the entire platform or something on top of the platform that is inherently useful for a pretty big subset of Asana’s users given the homogenous nature of the platform.
Asana Time Spent on Task Feature
For those in corporate America, but especially the tech industry, one of the primary problems across deploying software features is trying to account for how long it takes to implement the initial version of a feature when accounting for bugs, deployment, etc. While almost all software products have unique problems, having a general sense of how long something took in the past might give teams/companies the ability to more accurately craft a quarterly product roadmap, especially for teams working on legacy products (i.e. Microsoft Excel).
One interesting solution for tasks on is adding a small feature that will allow people working on a project the option to estimate the time it will take to complete the task, and after finishing the task, the amount of time it actually took to complete the task which will ultimately keeping track of how long it took to complete certain aspects of a project (image below). Despite the feature being super useful for software specifically, having a measure on task times might be a good thing for any sort of employee using Asana.
Existing Solutions
There are various QA tools used to test deployment times on code and internal tools used by companies to measure the total length of time a project took. The advantage of Asana over all these other platforms is the ability to measure the time spent on each specific task on a project so that it is easier for teams to pinpoint exactly where production times are falling short and where to allocate/dislocate resources in future cases, which could be invaluable.
Implementation .
From a UI perspective, for a user who is merely estimating and adding their task times, it makes sense for the UI to be as similar as possible to what they are already using. A possible solution would be to merely add the estimation feature as another optional feature to add when they are creating a task, like so.
When the user is marking a task, complete, if they had added an estimation time, there would be a simple one question popup to see how long the actual task took, and the rest of the UI flow would remain the same.
The admin of the project, who would likely be a director or product manager who is concerned about task times and the roadmap for future products would have a clean UI that would sort the tasks based on their subcategory within their product and the total amount of time allocated to each tag, whether this is marketing, bug fixes, or however narrow of a subcategory of tags the manager chooses to assign to. This would happen in a new tab only available to the project owner called history, which keeps a running count of all tasks.
In terms of the existing board, there would be no differences except that there would be the completion time given under completed tasks that the specific user could view.
Testing
There would be two different groups for testing. 3-5 Asana teams would test the product initially because they would be required to use the product and thus test the features and results of the task management accurately and then 10-20 external Asana using teams would test the product to test levels of engagement and add to the dataset of accuracy of test results.
The Asana teams would be evaluated on the following metrics:
Deviation between estimation and actual times
How similarly teams view individual tasks
Based on previous metric, how accurate the feature was for predicting similar future tasks
% of team members who thought feature was useful
If the Asana metrics were strong, non-Asana teams could then be tested on
% of tasks created that teams use time feature on, relative to other task features (i.e. file drop, due date)
A/B test UI flow to see if it changes above metric
How accurate of a predictor past task times were for future tasks
Manager survey on how useful they believed feature was
Deployment/Introduction to Users
Given all tests are successful, for full deployment, users would be given a pop-up introducing the feature on their next login and project owners would get an email notification introducing to features with a follow up a couple of weeks later so that they were aware of the feature.
Potential Engineering Challenges/Downsides
Teams don’t use feature because they can’t recognize a pattern of similar tasks and thus think the feature is useless
History of tasks page is super time intensive for engineers and slows down page load times because it requires aggregating and sorting the time and tag of tasks prior to the page loading
People working on projects don’t actually have a measure on the time they spend on tasks or fabricate results, which leads to very inaccurate results, making the feature counterintuitive.
Asana Whiteboard
Background/Existing Solutions
Asana has a document that talks about how Asana can be used for brainstorming. However, most brainstorming in groups takes the form on unstructured long discussions, used with plenty of diagrams, loose bullet points and whiteboards. Although I don’t have internal access to Asana’s metrics, I can imagine that the number of use cases for brainstorming is not particularly strong. The current whiteboard solution might be to take a picture of a whiteboard, upload it in a Slack channel, where every team member has to scroll repeatedly to find it, or even worse, forget about the whiteboard and have to reproduce the results from memory.
Solution
One solution to this problem would be to create a primarily mobile/tablet tool which allows teams to move their disorganized offline whiteboard sessions to organized reusable boards which can be assigned to specific tasks or tags within Asana that can be viewed by anyone working on a team at any time. The easiest way to describe this would be Google Docs for whiteboards that would work instantly with Asana and within the framework of other projects. Obviously, this is a large-scale project so it would take a lot of testing time before implementation.
Pre-Market Research
Before creation of an MVP, because this is a relatively large product, market research would have to be done to make sure this a reasonable level of demand for the product. This would involve polling existing Asana teams to see what their existing solution for brainstorming is, whether they use whiteboarding on a consistent basis, and whether this specific feature would be useful based on mockups. If the levels of interest are comparable to those to that of other Asana features implemented in the past, an MVP could be created.
MVP Implementation
Any user could view the whiteboards they are part of and the other collaborators on the board, not too different from Asana’s existing boards solution, except under a different tab.
Each board is labeled, and when a user clicks on the board, the board is loaded in full screen (this is mobile/tablet) in order to maximize the amount of space for collaboration on the whiteboard. The full-screen board would be super simple, at least in a first implementation. The board would give users the option to change the color on their pen, be touch responsive to mobile, add text to any part of the board, and assign the board to a task.
Each board could be assigned to a specific task, which will serve to better organize projects using Asana’s platform. This could be done in an easy way, where a simple popup dialog emerges on the assign to task button being clicked, giving the user the option to assign to either a tag or a task.
Testing/Deployment:
Unlike the first feature highlighted, which was relatively minor, this feature could become an integral part of the Asana platform and thus would require a ton of post-MVP testing.
Stage 1 Testing:
The first stage of testing would be to test an MVP as a stand-alone product amongst a relatively group of existing users. Some of the metrics to measure in this test would be:
Ease of usage
Useful or not
A/B Testing amongst different UI Flows
Stage 2 Testing/Deployment:
If the first level of testing was successful, the product would be integrated into Asana mobile apps for a number of willing participants to test responsiveness and for any unforeseen bugs.
Stage 3 Testing;
Given everything goes well with stage 2, Asana could implement a beta test for some users on just the mobile/tablet platforms. This is where it could be decided whether the product could be converted to real product based on the metrics of:
% of users who use features once
% of users who repeat engage with features
Average number of sessions per user, per whiteboard
Number of users who assign whiteboards assigned to tasks
Deployment:
Granted the above metrics were successful, the product would be rolled out to broader mobile/tablet population. If the product stays consistent with metrics, a read only web version of the product could be deployed.
Potential Challenges/Downsides
Creation of collaborative software that can be used by multiple users at once is a technical engineering challenge
Integrating the standalone collaborative whiteboard with the Asana API holding task information likely requires modifying existing API and is a challenge and could have ramifications if bugs not identified early
Between introduction to implementation, has potential to be a 6-12 product cycle, where an existing solution could emerge