Deciding which product features fit into your product roadmap can be a tough decision that requires thoughtful consideration of numerous variables. Below are some things that we think about at CoffeeBreak when considering adding a new feature or addressing user pain points.

Refer to the product goal

When considering new features, refer to your team’s product goal to gauge whether or not it supports the current focus. It’s natural to be juggling multiple priorities, so it’s important to create categorized goals/themes (Trello is a great tool for this, but we’re using Github) and add feature requests/comments to the corresponding theme. It’s a great way to view which topics need the most attention, while also having a handy list to quickly refer to when goals shift.

Weigh the feature (impact, time, resources)

Evaluate a feature by cost (time, resources) against impact (business, user experience, etc.). If your team is constrained by time and resources - think about which features are low hanging fruit. These small wins could be features that are low in cost and bring user delight, or a heavily requested feature to show we’re listening.

For instance, CoffeeBreak meetings were originally ordered chronologically by creation date. After hearing feedback around poor discoverability of older conversations, we added additional logic for “meetings” with new activity to float to the top. The measured cost for this change was less than other features we were looking at, and provided significant real and perceived user value - win win.

Look at data

Data can be a starting point that inspires a new feature, and it can also help determine whether or not to move forward with a feature request. Look at which features have the most and least usage. Be comfortable cutting the ones that aren’t working. Often data can show when a current iteration is ok or great, which leaves room to work on new features. Improve and iterate on existing features that are working and have positive feedback (flywheel method) to “spin” faster and faster leading to positive growth and impact.

As a small startup we don’t always have product history to refer to or related data, which means we sometimes have to use our product intuition, but being a startup also means we’re agile and set-up to run experiments. These product hunches are great cases to run tests as we don’t have a strong indication of how the change will affect users.

Dig into user feedback

Collect and parse feedback to understand user sentiment at different phases of the user journey. Feedback can come in the form of interviews, social media posts, app store reviews, and product suggestions. Analyze the good and bad reviews together as they’re equally valuable. Ask follow up questions when possible. As you collect feedback, label or bucket it into categories as mentioned above. It’s possible there will be contradicting feedback, so seeing where the majority of the feedback falls helps. Also taking a closer look at the personas of the people within each bucket will give further insight, and help determine what should be prioritized. Although a larger feature, the decision to add in-app scheduling was a result of feedback from many of our users.

Examine impact to the existing flow

Think about how a feature will impact both existing and future users. Iterative changes that seem small can really enhance the user experience. Small tweaks we’ve made to CoffeeBreak include adding a toast after people send requests, adding the red notification dot to in your circle suggestion tab, and so many more. These features were driven by feedback from users around the flow being confusing. Committed features should rarely be net new. Side note - before building, try and understand how user-friendly the feature will be. If the new feature requires more effort than reward, it may not be used - even if it fills a need.

Scope and spec it

A good spec is a well thought-out written document that takes the points from above into account to help decision makers make a knowledgeable choice. Our specs aren’t too formalized, but we have a template that makes it easy for us to record what exactly is changing, how much effort there will be, what we think the impacts (positive and negative) will be, and how to measure the impact. We also use these specs to get everyone on the same page as to what, why, and how we’re wanting to build new features. There’s usually a scrappy and ideal version of the feature. Don’t be afraid to create multiple specs for different product versions/iterations. As a startup with a “launch it broken, fix it live” mentality, we like to test and learn quickly, so we like to start with writing and implementing the scrappy version first.

Ultimately, focus on what’s right for your company and users. Think about which features will move the needle the most in the eyes of your users and investors. What you and your team say “no” to today could very well turn into a “yes” next week.