How We Prioritize Which Features To Add To Our SaaS App, MoonClerk

At this point in the life of MoonClerk there are no “easy” features to add. Our platform is fairly complex so any features we add aren’t siloed — almost every feature touches multiple areas of our application and interface. And, since we have thousands of paying customers now, any changes we make and any bugs that new features cause aren’t minor. On top of that, while we are profitable and growing, we’re still a small team, which means development time and man-hours are two limiting resources.

Because of our limited resources, we have to make wise decisions as to what features to add to our product. For the past 2 years, we’ve undertaken the full process of prioritizing which features to add once a year at our annual anniversary retreat.

In this blog post, I’ll explore the process we use to decide which features we’re going to work on.

Defining The Purposes

First and foremost, we define the ultimate purposes any feature has. So far, we’ve defined the following purposes — Features that:

• Reduce pain points for our current customers
• Reduce our churn
• Increase our conversion rate from trialing customers to paid customers
• Attract larger customers
• Automate our business internally
• Scale our system architecturally
• Increase payment volume flowing through our system
• Help us in marketing
• Open MoonClerk up to new industries

I’m sure over time, we’ll add even more purposes.

Prioritizing The Purposes

Once we’ve established what the purposes are, we prioritize which ones we want to focus on. At different times in our business’ life, we’ve prioritized different purposes higher than others. When we reached over a thousand customers, we realized that we needed to spend some time inside our app improving it internally so that it would scale moving forward without hiccups. So, we did things like moving exporting data from the dashboard to background jobs. Earlier on, we needed more exposure, so we focused on features that would allow us to market ourselves better, such as integrations with third party services. At other times, we’ve wanted to get our average revenue per customer up, so we’ve focused on features that attracted and retained larger customers, like adding customizable, dynamic email notifications.

Defining The Potential Features

Next, we list on a whiteboard all of the potential features we could add. This process is really just transferring everything from a digital format into a physical format. Digitally, we use a Github plugin called Waffle to help us track our potential features. The very first column is an Ideas column. Throughout the year whenever we have an idea for a feature or hear an idea for a feature from our customers, we put the feature into the Ideas column. Our goal is to keep a running list of potential features without having to constantly discuss them and get off focus. We want to keep a running log so we can batch-discuss everything.

Assigning Purposes To Potential Features

Once we have all of the potential features on the whiteboard, we establish an abbreviation for each purpose. Then, beside each feature we use a marker to write which purpose applies to each feature.

For instance, we recently launched a feature that allows our customers to resend email receipts to their payers. That feature was part of the “Reduce pain points for our current customers” purpose. Nobody outside of our current customers has ever really asked for that and we aren’t necessarily losing customers because we don’t have it. But, the lack of this feature has been a pain point we’ve heard from our current customers. We want to keep our customers happy.

Another example is a feature that includes digital delivery of content. That’s a feature some of our potential customers have asked for and would fall under the “Open MoonClerk up to new industries” purpose. The businesses that ask for this feature usually aren’t MoonClerk customers and due to our lack of it, don’t sign up for MoonClerk.

Sometimes multiple purposes will apply to a single feature.

Eliminating Low-Priority-Purposed-Features

This step is pretty simple. If, after defining the purposes for each feature, we see that the feature falls under a lens we aren’t going to focus on, we remove that feature from the whiteboard. We’ve already decided which lenses we’re going to focus on, so removing the corresponding features creates less clutter.

Assigning A Difficulty Level To Potential Features

Beside each feature and the purposes for that feature, we use the marker to write an estimated difficultly level — from 1–4. A “1” means the feature is epic. A “4” means it’s relatively easy. We also use a “0”, which means we don’t know the difficulty level. A zero means we’ll need a “spike” — a 1–3 day investigation period for a developer to really dig in and guesstimate what the difficultly level is.

Our development team really takes care of this part since I’m not a developer and can’t estimate how difficult it might be to add a feature.

Listing The Demand For Each Feature

In the past, we’ve just based the demand for features off of our perceptions while doing customer support. We had a general idea of which features customers were asking for more than others. Earlier this year, we began tracking the number of times we receive each feature request. So, at our next annual meeting we’ll be using actual data rather than perceived demand.

In order to track this demand data, we’ve wired up a few web-based services. We run all of our customer support through Desk.com. Whenever a customer support case comes in where a current or potential customer requests a feature we don’t currently provide, we assign it a “Feature Request” label. Then, we have custom fields for feature requests. We have drop down menus with common requests so that it’s easy for whoever is doing support to easily categorize the request. We also have a text field to type in a new feature request we haven’t heard before. So that we can analyze the requests we’ve received, we’ve wired up a Zapier integration that sends all of this data from Desk to a Google Drive spreadsheet. For each new feature request, we create a new row in the spreadsheet with the customer’s name, email address, the feature request, and a link to the case in Desk.

When we meet as a team to prioritize which features to add, we’ll look at the number of requests for all features that are still on our whiteboard. We rank them by the demand we’ve seen for them.

Estimating Each Feature’s Impact

In the same way that we define the difficultly level of a feature from a 1 to a 4, we also assign each feature an impact level and write the impact level beside the feature. The goal is to estimate the impact the feature would have on our overall business if it were in our product. A “4” means it will have a big impact and a “1” means it won’t have much of an impact.

Deciding Which Features To Work On

Finally, we decide which features we’re going to be working on. We add up every feature’s difficulty level, demand, and impact level. The ones with high scores mean they are high impact, high demand, and low difficulty. Sometimes those exist and sometimes they don’t. Sometimes the only high impact features are ones that are very difficult. And, sometimes a feature may only have a mid-level impact but it’s so easy to add and we get so many requests for it that it’s a no-brainer. So, we don’t base our decisions solely off the scoring system but the score does give us a good idea of any low-hanging fruit.

Documenting Our Decisions

After we’ve hashed everything out and decided which features to add, I write up a detailed analysis of our discussion surrounding each feature, both the ones we decided to work on and the ones we decided against. I email my notes out to everyone so we’re all on the same page. It’s amazing how often we forget how we arrived at our decisions so these notes are invaluable.

Also, after the meeting, we move the features we’ve decided to work on from the “Ideas” column in Waffle to the “Ready” column.

Conclusion

This entire process is really about helping make our decision easier through elimination and prioritization. Once we’ve narrowed things down, at the end of the day, we rely on our gut as well, so that plays into it a bit.

Sometimes, in the middle of the year, we will change our decisions on which features to add. However, we’ve found that in most cases when we’ve done that, it’s been a mistake. It’s best to stick to the game plan we created.