Slope Blog

How We Handle Feature Requests at Slope

[fa icon="calendar"] 3/28/18 2:50 PM / by Kyle Gostinger

We hear a lot of feature requests here at Slope. A. Lot. Any sales call inevitably ends with the customer suggesting some kind of addition to the product, and it can be difficult to prioritize the feedback. As a startup, we need to be very intentional at how we allocate our resources and time when choosing which features to add into the product and when. Here’s some insight into our process when we receive feature requests. 


Does the feature fit the intent of the product?

The first step in deciding if we should build a new feature is to ask if the feature fits the intent of the product. So what the hell does that mean? This is the easiest part. Does this feature fit the general category of project management? Yes? Great. Next step.

Does the feature positively impact the the intended user without negatively impacting other users?

Secondly, we need to decide if we SHOULD build it. Does this feature positively impact the the intended user without negatively impacting other users? This is where it gets a little more complicated. Sometimes we get a request that might technically improve the bottom line, but negatively impacts an organization’s employees. Example: while doing research into creative project management in the early days of Slope, we ran into a company that added a timer to every image their artists needed to edit. They were given one minute to edit each image. While this improved the volume of images that were completed in a day, it led to stress and reduced moral for the team’s artists. Not great. These are the scenarios we avoid at all costs. So does our new feature request help without hurting? Yes? Great. Next step.

How do we prioritize the feature with all the other requests?

So now we’ve decided that our new feature request fits within Slope and is also a positive addition to the product. Awesome! It’s now on our product roadmap, but there’s one problem. It’s all the way at the bottom of the list. It’s not a small list. We need to prioritize our new feature request against all of the other requests customers have asked for, as well as all the internal projects we want to do on our end. This is the hardest part.

Every department in the company has their own opinion on priority. Sales wants whatever the current customer is asking for. Design wants to improve the user experience and remove any usability problems. Who knows what software engineering wants. The customer always wants their request first (obviously). Sounds fun right?

So how do we go about prioritizing considering all these conflicting opinions and desires? First we categorize the request. We could be adding a brand new feature, improving usability, or any number of things. Product growth best practices dictate that you should service as many different categories as you can before circling back and hitting the same category again. This rarely happens in practice, but it’s something we keep in mind as we’re sorting our backlog.

Who is the feature for?

The next consideration is the user persona. What user persona is this for? Executives? Managers? Team members? We take an approach similar to the last step in which we try and add value to each of our user personas before coming back around. Once again this is a great idea, but doesn’t always go to plan in the real world. The better we get at this the more well rounded our product will become.

Will the feature increase revenue?

In the end, after we go through all of these processes (again and again each time there’s a new feature) there’s one thing that can supersede all others. Will this feature increase revenue?  In the end we want ur customers and potential customers to find as much value as possible with our product. The easiest way to prove value is to see if people are willing to pay for a specific feature, or for a subscription to the entire product because of a feature. As a startup, willingness to pay is a great indicator of what we should spend our time building for customers as we work through all of these steps.


I hope that gives you a little insight into the product team’s process here at Slope. We’re always ready to listen to new requests from our customers. Do you have an idea? Let us know! It might just be great enough to skip to the front of the line.

Topics: Product

Kyle Gostinger

Written by Kyle Gostinger

Head of Product at Slope