In the startup world, identifying your users’ main goals can be difficult because you’re moving so quickly. However, adapting Gerry McGovern’s Top Tasks method [1] can enable you to quickly identify the overarching trends in your customer base’s goals. In this article, we’ll demonstrate how you can apply this method within the context of a fast-paced startup.
What Is Top Tasks?
Top Tasks is a research method that Gerry McGovern created in 2018 to identify customers’ top goals or tasks. This method is based on the principle that the most important thing to customers is accomplishing whatever task they want to complete. This method is common in the enterprise-software space as a means of trimming down and realigning products that have become bloated and stagnant.
Champion Advertisement
Continue Reading…
Why Top Tasks?
At first glance, it may seem strange that we chose this method, considering that we were working in a medium-sized startup with a product that has been around for about five years. Our product was neither bloated nor stagnant. In fact, it was the opposite, and its market is rapidly growing. However, our organization was at a stage where there was an increasing risk of our focusing on siloed, hyper-valued areas of the product.
Our small, centrally organized research and design team was charged with assessing the product holistically. We needed to figure out how to unify the product’s functionality around a common set of goals. We chose the Top Tasks method not to slice away old, unused portions of the product, but to focus a guiding light on our journey ahead.
How We Modified Top Tasks
Let’s look at how we adapted and applied this method within a fast-paced startup by modifying certain steps from the original approach. These modified steps appear in italics in the following list:
stakeholder socialization—This is the process through which we conveyed the value of Top Tasks and got stakeholder buy-in, as well as the commitment of their time.
stakeholder working sessions—We conducted three 60-minute sessions, during which we had stakeholders compile lists of key tasks.
refinement of proposed tasks list—We asked stakeholders to review our proposed refinements of their task lists. These refinements included the following:
task wording—We updated the proposed language describing the tasks to ensure that we had a list of distinct, highly explicit tasks.
task grouping—We reviewed the list of tasks to identify parent-child relationships. Our goal was to achieve a consistent level of granularity that is representative of the majority of our customers’ tasks.
survey design—We observed the standard Top Tasks approach, in which we asked customers to look at the entire task list, then choose their five top tasks.
survey distribution—We conducted two surveys, as follows:
primary customer survey—We distributed this survey by sending out an email message with a link to the survey to collect responses from the people in our distribution list.
internal survey—We measured alignment between the top tasks of perceived and actual customers.
data analysis—We conducted analyses to identify correlations between tasks and various customer segments, including the following:
cumulative
user persona
department
career level
internal stakeholder versus customer
We’ll expand on our explanations of these modifications in greater detail next.
Modifications in Our Approach
Our modified steps reflect our context: working within a startup supporting a technical problem space. Although McGovern recommends gathering the initial list of tasks from primary customer data such as search terms, Web-site data analytics, and customer surveys, we needed to generate our list quickly and did not have enough longitudinal customer search and interaction data for his approach. Therefore, we instead leveraged our internal stakeholders’ ability to summarize trends that they had observed in our customers. McGovern’s approach also stresses the need to socialize the value of this method. Because of our modification of the stakeholder working sessions and internal stakeholders’ having limited availability to participate, our socialization effort was all the more critical. We created participation opportunities to make the most of stakeholder knowledge during shorter sessions. Thus, we abbreviated McGovern’s recommendation of between six to eight 90-minute sessions to just three 60-minute sessions.
As we refined the list of tasks we received from stakeholders, we quickly discovered that additional modifications were necessary to craft our final list. McGovern recommends not using verbs in task names. However, the list of tasks must also be definitive, employ customer language, and be indicative of the problem space—which, for us, is primarily task driven rather than focused on information gathering. Because most of McGovern’s examples were focused on information gathering, his tasks have these implicit verbs:
search—For example, “search for open hours.”
find—For example: “find passport forms.”
For these examples, it makes sense to exclude the verbs because all the actions are virtually the same. In contrast, our customers’ goals use different verbs—for example: “repair a device” versus “purchase a device.” Therefore, we decided to include the verbs when it made the tasks more explicit, as shown in Figure 1. (Note, McGovern’s examples also include occasional exceptions to his rule.)
Figure 1—Verbs in task names
The use of parentheses is another technique that McGovern recommends using in a limited fashion to improve the clarity of a task definition. We used this approach to provide examples—thus, resolving any confusion that might result from our products’ complex technical space. While the technical terms might be correct, giving examples of them helps our users who have lower technical literacy to understand their definitions.
Limitations and Future Considerations
No research is perfect. There will always be biases or blind spots. One limitation of our approach to Top Tasks was that internal stakeholders were primarily responsible for generating the task list, so we were really at the mercy of the quality of their knowledge. Obviously, this is why McGovern suggests focusing primarily on collecting interaction and search data from the product and just supplementing that with tasks that internal stakeholders generate. Plus, as with any survey, we encountered the limitation of non-response bias. [2]
A significant step of this research is taking the top tasks and benchmarking the five top tasks. Accomplishing this goal proved to be challenging within a startup environment. Our user interface was changing too frequently to get a complete benchmark of all tasks at once. There were also competing demands on the UX Research team’s capacity. We hadn’t initially considered how difficult it would be to benchmark these tasks in a Lean or agile fashion. Plus, testing the tasks individually, over time, can introduce covariants that impact the observed benchmark.
In the future, we hope to figure out how to benchmark the five top tasks. Despite the limitations of our testing approach, it might be most feasible for us and other startups to benchmark a single task at a time.
Conclusion
Although we had to adjust this research method to accommodate our needs, Top Tasks provided extremely powerful data that the company continues to use today. This research allowed us to anchor the organization to a solid foundation of insights that informed our product roadmap and feature requirements.
Building on this research, we immediately started conducting research on how our products’ information architectures supported the five top tasks. This led to a quick revision to the product that improved time to task completion by 22 to 36 seconds and completion rates by 34 to 50%. In addition, we’ve heard testimonials across the product team that, even nine months later, they use it as a threshold for what is user centered.
To all startups out there, we highly recommend the Top Tasks method, applying the few adjustments that we made. The Top Tasks method has provided a wealth of data to direct the product vision and has created a solid foundation for our future research. Top Tasks has truly proven that it can serve as a guiding light to direct future product development, highlighting where to grow your product, in addition to helping you to ascertain where to trim down product functionality.
Bibliography
[1] McGovern, Gerry. “Top Tasks: A How-to-Guide.” Gerry McGovern.com, October 8, 2018. Retrieved February 19, 2023.
Mary is a UX researcher with over a decade of experience conducting research. She provides data-driven recommendations for impactful products in healthcare and information technology. She holds a Master’s in Information Studies and a PhD in Biomedical Engineering Medical Informatics, both from UCLA. Read More
Sarah has over six years of experience in product design, crafting exceptional, holistic experiences in business-to-business (B2B) spaces. She designs software that conforms to people, not the other way around. Read More
