If you’re reading this wondering why we chose to do one feature over another, please note that you’re not the first (or the last) to shake your fist while shouting this question! We hope that all of our customers are this passionate about our software. I know I am with the products I use, so we expect nothing less!
Unfortunately for you though, we don’t often reveal much about the planned features on our product roadmap. What little we do reveal are those things that we are most confident about delivering. Frankly, we don’t show more because we don’t want to disappoint you! We have a very complex product with a lot of integrations and moving parts. Sometimes it can take a good while to create and test additional functionality. Oftentimes delivery is influenced by changes in the market, current technologies, and planetary alignment. We’d hate for any of our customers to become dramatically attached to a favorite promised feature, and then disappoint them by delivering a different, though equally valuable feature.
I admire many of the approaches taken by the 37Signals team and ran across this line from David Hansson about the dangers of over-promising,
“It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see.”
I want to break down some of our process around how we choose which features to develop, but it’s very interesting to talk about why we choose certain features. I love a line I hear from Simon Sinek, “People don’t buy what you do they buy why you do it.” But this is a topic for another day. So here are the four steps we use to get the right features in the development pipeline: discovery, organization, prioritization, and timing.
Determining the next Moab feature can be overwhelming and it often feels as though we’re looking for a good read while standing in the middle of the Library of Congress. But we relish the fact that we are not alone! We hear our customers loud and clear and know exactly which areas of the product they’d like to see improvements in. We are working on some ideas to improve the quality of feedback we’re getting on this channel. We also work together with our partners to discover and evaluate new synergies and approaches. We are constantly looking for emerging technologies and market opportunities that align with our corporate strategies. And we regularly reflect on our own failures and search for better solutions. There is no shortage of good ideas, and we try to collect them all.
In order to ensure that we deliver real value with each release, we group all of these ideas into initiatives that address end-to-end functionality and practical use cases. We understand from experience that cherry-picking our favorite little features from various areas isn’t viable over the long-term. We try to make sure that we can deliver well thought-out solutions through the features that we provide; something that we can be confident will have a positive impact on our customers and their ability to accomplish to their goals. Once we’ve organized each of the ideas into feature initiatives, we also evaluate iterative approaches that would allow us to iteratively plan for work that might ultimately take more than a single release.
We can’t do it all. We wish we could, and we try, but we really can’t! We know how much we can accomplish in a given amount of time, and we’re always on the lookout for techniques and processes that will improve our development velocity, but we know that it won’t be enough to get everything we all want. Through prioritization we can ensure that the most impactful features are delivered first. This is the phase where we have to argue for our favorites and sometimes let them go. Some of the factors that we consider are: time to implement, degree of innovation, how competitors approach the problem, number of affected customers, bang for the buck, and how long we’ve already been waiting.
We all know from our own personal experience that if we simply work off a priority list, we can miss opportunities to innovate and optimize. For example, I missed seeing the new movie Pacific Rim last week because I didn’t consider rescheduling a high-priority but time-insensitive appointment. By the way, I am not sure if I’m worse off now, so maybe this is a bad example. But as we work out the implementation details of each new feature and its components, we discover multiple opportunity paths that can all lead to “good” delivery outcomes. We take time to plan these out so that we can rest assured that our timing optimizes our efforts and make changes as needed.
Once the timing of each epic’s features is nailed down, we hand the execution off to our capable Engineering team and monitor the progress as we work towards the next release. We can talk more about the engineering process in yet another blog post, but hopefully this gives some insight into our approach on feature planning.