P0: Effective Prioritization
Prioritization happening live

We have massive ambitions for General Task. We want to improve the productivity of knowledge workers across the world. And we want to build every feature (and I mean EVERY feature) that can help with this goal. We want a full code-review experience, a Superhuman-level email client, the best calendar, and a superb task management experience to name a few.

It would take years to build out everything we want. But as a startup, we have a limited window in which we can demonstrate value (until we run out of money), and thus, we can’t simply build our product in the darkness for years and come out with a perfect suite of all of the features we want. Instead, we wanted to launch early, and ship the best improvements at a breakneck pace.

In order to operate at speed, we need to seriously prioritize. Outlined below is our framework for doing so.

Target Market Interviews

We built the product with our target users (software engineers at startups) at top-of-mind. We wanted to validate that our ideas would work, before taking them to market and putting hours into building each of our new features.

This is how we built our app, from the ground up. We would do a series of target market interviews, and build new features based on the feedback we received. We probed users on their pain-points at work, and then thought of innovative ways to solve these problems in the app. This worked great pre-launch, and as such we have continued this user interview process, even post-launch.

In the post-launch days, we have our design team create some prototype mocks of our proposed feature. Then, we use a tool called UserInterviews, which allows us to access a pool of reviewers/interviewees in our market of startup software engineers. We show these users our prototypes over the course of a few minutes, and gather their feedback.

This has been immensely helpful in terms of deciding our next big bets in terms of new features.

However, this method has a few drawbacks. Namely, these interviewees are not General Task users. And the interview process is short. This means that we must present each feature in isolation of the entire app. This leads to obvious issues, in that our users don’t have the context from the rest of our app. How useful are recurring tasks without any concept of a task manager?

Listening to Users

When we launched, we were lucky enough to quickly get a very vocal user-base. This was a massive gift for us! Our users frequently tell us what they love about our app, and what they hate about it. And it’s amazing! From this feedback, we can find the next task manager to integrate with, the most important bug to fix, and the UI tweak to make people more productive.

We treat this feedback as hugely important. It is top-of-mind every sprint, and we prioritize these tasks quite highly.

However, there are some potentially unexpected downsides to this feedback. The main problem is that you can’t expect people to ask for something they have never seen. It is not up to our users to be innovators. They are doing enough by telling us how to improve what we already have built. Thus, while this feedback is immensely helpful, we can’t solely rely on our users as the source of truth.

Listening to Ourselves

The previous two methods both are extremely valuable, but there may be some additional decision-making required. What if our target market interviews are telling us one thing, and our users are telling us the opposite? As the final tie-breaker, we, of course, rely on ourselves. This is perhaps obvious, but I think we do it slightly better at General Task than at most companies. At General Task, the majority of our team is in our target market!

We have everybody on our team use some version or other of General Task. If we feel some feature would improve the product for us, it, more than likely, would improve the product for similar startups. We run weekly meetings in which the entire team pores over proposed designs, and determines whether the proposed features would work in our own workflows. Then, we build, and we ship. This has worked very well for us thus far!

Conclusion

Through these three methods, we are able to pretty confidently choose the next best thing to build. If you have any features to suggest, please let us know. And, as always, feel free to check out the app at https://generaltask.com!

P0: Effective Prioritization
Older post

Speed in a World of Latency

How can an ambitious startup decide what to build next?