airfocus

Building a new tool for smarter roadmap prioritization.

Summary

I worked with two friends on a private project to make prioritisation easy and fun. I did all the initial UX & UI design for the project as well as being highly involved in the general product decisions. Later, this project turned into a real company and a full-grown product. As of today, I am still involved as a UX designer and consultant.

Background information

Prioritisation is a key aspect of product management. From high-level roadmaps down to individual user stories, product people need to prioritise properly and regularly. As it turns out, doing so is not that easy.

While working inside Product Management, me and a colleague noticed that it is very difficult to prioritise right. Even though we tried many different tools and approaches, it’s tricky and somewhat cumbersome.

A typical example: All the product guys sit together, discussing current projects and trying to prioritise them using various factors and criteria. All of that information is gathered inside a spreadsheet and then later on turned into a business matrix.

Now that you have a beautiful document with lots of information, you’d like to share it with stakeholders. Files are sent around, together with lengthy emails to explain how it works.

One month later, a new project comes in. While discussing it with the team, somebody points out that you should now update the business matrix to reflect the changes. Going back to the spreadsheet, several criteria need to be updated as well.

We noticed that even though the initial set up and creation of these kinds of documents gets done, constantly updating and sharing them is a nightmare. It’s usually not considered to be worth doing, simply because it’s a lot of effort (and, let’s face it, nobody likes large spreadsheets anyway).

However, we all value proper prioritisation and we all know how important it is for the overall strategy. So we asked ourselves: Could there be an easier way to do this?

Starting situation and goals

When we sat together for the first time, we collected all the things that we noticed about our last attempts at creating and maintaining a business matrix and similar documents. Here are some examples:

• Maintenance is very difficult, because there are only a few people who understand the calculations in the background and can update the sheet without destroying it.
• The matrix is difficult to share. Maintaining one file on the server requires people to actively look into it and sending updating emails is annoying, especially if they lead to follow-ups and email discussions.
• Whenever you want to present the matrix, you need to show the full spreadsheet. That’s pretty much impossible on a tablet. Besides that, it does not look very nice.
• The matrix feels kind of “left out” of our process because it is not connected to the other tools we use for development like Jira and Github. Changes done at either side are not reflected back automatically.

After these discussions, we looked for alternative tools specialised for these kinds of things. While we found some, none of them really delivered what we expected. It was either really ugly and outdated or just a simple, one-dimensional list.

We came to the conclusion that it would be an interesting side project to build a tool that fixes those issues. An easy to use, good looking application that enables you to quickly create proper prioritisation.

The target group

The main target group would be product managers, project managers, product owners and everybody else planning and executing products or projects. We figured that such a tool could also be used by executives or sales and marketing guys, but since we tried to solve our own problem, we were mainly focussing on product people.

First explorations

I started to outline what we thought would be the most simple user flow necessary to achieve a proper business matrix. Why a business matrix? We quickly came to the conclusion that starting with one type of prioritisation document would be enough for an MVP. We picked the business matrix as it can be used for a variety of projects and processes. It seemed to be the most generic starting point and it was what we had the most experience with.

Based on that flow, I created sketches for the different screens trying to figure out how those could look like.

Basically, we imagined users to log in, create a new project (or select an existing one) and then see the matrix immediately (either with their content or with some example stuff). Besides the matrix, they could access a table view with the items, factors and criteria. This would also be the view where they would make changes, add new items and rank them.

The matrix would then reflect these changes, showing the overall priority of each item in a visual way. Due to the nature of the business matrix, there are three dimensions (x-axis, y-axis and bubble size).

Last but not least, there would be a settings view where users could change the weighting of criterias and add or remove them to customise the matrix to their own needs (for example, you do not always need a criteria for effort). We’d provide default ones to give users a good start, but from our own experiences it would be necessary to change these.

With the first set of mockups in place, we started to develop a working prototype. While doing so, we naturally discovered several flaws and room for improvement. While the first version was still in development, I started to refine some things, so we could easily shift course while developing.

Furthermore, I started to work on a simple landing page, mainly to explore the visual design. In the beginning, the page was only used to collect potential users and interested people using a simple email signup.

Once the first working version was ready, we realised it would make things easier for users if we’d get rid of the project idea altogether and simply let users work in documents only (before, you could have multiple documents as part of a project).

Apart from that, I created a first real visual design for our MVP.

Lessons learned

While it’s a lot of fun to work on your own project with some friends, it’s also very demanding. When you come home after work, it’s very tempting to prefer the couch instead of your laptop for the evening and on weekends you may not always be in the mood to do additional work.

On the other side, the project proves the power of having the right people involved. One full stack developer may be all you need (in the beginning, at least) to deliver a working solution. Keeping the scope focussed allows for fast iteration.

Thanks to modern collaboration tools like Github, Slack and Zeplin, we came up to speed very fast. Brainstormings and discussions still work best in person, but many things can easily be done remotely.

On the other side, it can still be tricky to coordinate and sync everybody and I could imagine that this gets worse the more people you work with. With the three of us, it’s manageable, but I doubt that it scales well.

Conclusion

While I am involved in the project as a consultant and external designer since it was launched, airfocus is still alive and kicking. Go have a look for yourself at airfocus.com!