How a Suggestion Becomes a Feature

DevResults prides itself on continuous innovation in response to our users’ needs. Every improvement we make is a response to the feedback we get in person and through our help desk. As our company grows, DevResults works constantly to optimize our own internal processes. We strive for transparency in how we evaluate and execute feature suggestions, and this blog post will offer a peek behind the curtain of our feature development pipeline.

Our Commitment as a SaaS Company (Software as a Service)

When you partner with DevResults to implement an M&E platform, you’re agreeing to use DevResults as-is. We don’t guarantee that we’ll create any particular tool a subscriber asks for.

But you are guaranteed to benefit from the work we do every day to add functionality and improve the software. Standing still is not an option for a SaaS company, because we know that remaining your technology partner requires meeting your ever-evolving needs. How do we approach that responsibility?

First, it has always been true (and will always be true) that there are more feature suggestions than could ever be implemented. This is a fact for all products of this kind because every new bit of functionality produces many new ideas. For instance:

Delivering the data tables feature produced new suggestions for filtering and sorting, row-by-row permissions, offline templates, supporting relational data, and so on (and we did those things!).
Delivering document storage produced new feature suggestions for nested folders, document tags, integration with external document storage; and so on (some of which are works in progress).

We’d love to say yes to everything but no company has unlimited resources. This means that we must be judicious in how we evaluate users’ suggestions and needs. It is our most important obligation to carefully consider how to allocate the resources you invest in us to improve our platform for your organization.

What Makes a Great Feature Suggestion

The vast majority of suggestions that we get are great ideas that we’d love to implement. Here’s a summary of the things we consider when adding features to our roadmap or squeezing them in between larger efforts.

Very useful to most people: We’re most likely to prioritize feature suggestions that would improve the platform for a wide variety of users, organizations, and sectors.
Solves an existing problem: We give priority to feature suggestions that solve an existing need. In short, we receive a lot of feature suggestions from folks who are thinking about adopting DevResults or have just adopted DevResults. Over the years, we’ve found that perspectives shift once a person is using DevResults, and there’s a change in the importance placed on various feature suggestions.
Strategic: There are exceptions to the above. A good example is our recent work toward providing full support for publishing to IATI. Not many of our users publish to IATI, but we believe in the cause and we want to be a viable choice for those who do as well.
Maintains our off-the-shelf commitment: It’s important that every feature we implement be applicable to any sector of international development and work at any scale, even though not every organization will choose to use every feature.
Variety of scale: We try to balance small- and medium-sized “quality of life” improvements with larger releases that provide brand new features.

There's no exact science to this, but in general these are the types of suggestions that don't make the cut:

Le Problème du Jour: This is a suggestion to build a feature that would have solved a one-off need that a user had that day, that they might never have again, and that we’ve never heard of before. An example might be to create a button that lets you add three letters to the start of all your indicator codes. This could be done easily enough using the edit multiple indicators tool.
The Retrofit: This is a suggestion to re-design DevResults or one of its tools to match a system someone used previously, when that way of doing things offers no real net benefits.
The Marginal Gains: Some suggestions are things that we think might be cool or useful, but they’d come at a high cost. If it would be a ton of work for our engineers and add complexity to the platform to do something that makes it 10% easier to do something that you can already do relatively easily, this suggestion probably won’t be prioritized.
The Customization: This is a suggestion to hard-code something into the platform that’s specific to just one organization. An example would be adding a checkbox to the activity definition page to say if an activity is nutrition-related or not. This wouldn’t apply to all of our users and would best be achieved with a sector or a tag, which are designed to offer flexibility for the entire international development space.

We hope it’s comforting to know that we don’t invest scarce resources on feature suggestions like these that don’t provide maximum impact for you and your organization.

Feature suggestions come to us every day. We accept feature suggestions and feedback to our help desk at help@devresults.com from anyone at any time, and that will never change. It’s indispensable to us to hear those ideas and know about points of friction. But as our number of users grow, it’s harder to keep track of folks’ top priorities. We’re currently experimenting with ways to make sure that we’re always aware of an organization’s top suggestions at any given point. In most cases, this will start with a shared Google Sheet.

Historically, we’ve shouldered the responsibility to nail down every facet of every feature suggestion: the problem to solve, who would benefit, how it would work, why it’s needed. We receive a high volume of suggestions, so we’re shifting some of that responsibility to the suggester because they know the context for the problem to solve. We’re going to focus on communicating with users about the suggestions that organizations identify as their top priorities. Then we’ll assess them and queue them for action based on the criteria above.

How We Work

Once we’ve decided what goes into the queue, we face a lot of demands on our time. We’ve organized ourselves in a way that balances those competing demands.

Our engineers rotate through two teams in three-week blocks:

The primary team generally works on a larger, ongoing feature in our roadmap (or planning for one).
The secondary team generally works on behind-the-scenes code updates that are important for speed, security, and work that makes it easier to add new features. Our engineers set these priorities based on software development best practices.
On-call: Engineers take one-week turns to fix bugs or implement small items from a short list of top priorities. They can choose tasks that fit the amount of time they have available.
Freedom Week: Each engineer gets four weeks per year to work on anything they want, whether it’s a feature they’d like to make happen or to hone a new skill. The recent menu update was the result of a Freedom Week.
We also set up pairings between all the team members to spend a few hours on smaller goals. Our new tools for assigning reporting periods to activities was the result of a pairing.

Bottom line, we love to hear from our users, and we absorb a huge number of their ideas into our roadmap and pipeline. We let client organizations define their top priorities. Based on those priorities, we schedule big features for development based on thoughtful criteria. Even so, there’s a lot of flexibility for making smaller things happen if they’re well-defined, tightly-scoped, and of high priority.

Our Roadmap

We prioritize large features on our roadmap and reevaluate periodically. Our queue for larger features is currently:

Notifications: Expanding the options for automating emails about deadlines and updates.
Integrations: Improving options for integrating mobile data collection tools with data tables, plus expanding our documents integrations from just Dropbox (currently) to include Google Drive as well.
Multi-Matrix: Replacing the Pito interface with a multi-indicator version of Matrix.

If you follow our release notes (or access them from the help menu in DevResults), you’ll see that we’re making frequent, smaller changes that get into the pipeline as described above, so stay tuned for the latest DevResults updates!