Why We Ditched Features-Based Planning

A lot of founders we talk to want to know how long it will take to develop a very specific, long list of features.

This is how a lot of the development world operates. You bring a list of features to a developer. That developer tells you how long it will take and how much it will cost to develop that specific list of features.

So it’ll sound pretty crazy that we stopped signing contracts that agree to specific feature sets.

We know it sounds absurd, but we've actually won all our clients over to our point of view (they wouldn't be our clients otherwise ;)). When it comes to agreeing to a specific set of features, we've noticed a couple primary issues. Before we dive into those, let's review what a feature is. 

A feature is the most granular unit of functionality within a software product, describing a specific user-facing capability or behavior. Features dig into exactly how a platform is going to work for users.

The Issues with Feature-Based Planning

To illustrate the problem, let's consider an example:

Your boss is in town for a client meeting, and you’re driving them from the hotel to your client’s office. Your boss is running a few minutes late, jumps in the car, and tells you to jump on the highway.

Because of your keen, local sensibilities you know the highway is under construction right now and is always a mess this time of day. Taking the route through town will actually get you to your clients office 10 minutes faster. 

Your boss told you to "take the highway," but what they actually meant was "get us to the client's office as soon as possible." And since you have a better understanding of the landscape you're operating in, you know the best way to arrive at that objective. 

Features Dictate How, Not What or Why

Features provide an opinionated look at how to solve a problem. In the above example, "take the highway" and "drive through town" were two solutions to solving the problem of getting to the client's office. Based on the circumstances, one solution was markedly betted than the other. If you're handing a list of features to an engineering team, then you have not consulted that team on their opinion for how to best solve your problem. You're basically asking them to blindly follow your lead without strategically considering why. 

Features Change

As the smallest unit of measurement within a software product, features are the most susceptible to change. We've built over 100 apps, and we've never worked on a project where features didn't change. In the above example, the solution changed because there was construction on the highway. That hadn't always been the case, but the current market demanded a new solution. Change comes from a myriad of reasons - learning new things about the market, hearing from users, pivoting the business, changing your mind, etc.

How can you involve your technical team to create even better solutions to your problems? Since change is inevitable, how can you be better prepared for it when it comes?

 A Better Alternative to Feature-Based Planning

The alternative to planning your product roadmap around features is to orient your product planning around user outcomes.

User outcomes are the specific thing you want your user to be able to accomplish when using your product. From the example above, the objective was to arrive at the client's office in as little time as possible.

If you prescribe how to achieve that outcome by giving your engineers a specific list of features, you’re missing a possible better way that your tech team is aware of. You’re taking away their creative freedom to take part in the design of your problem-solving and the necessity to be flexible to change and respond to the market and user feedback. 

Don't Fret, We Still Love Features

 We say none of this to completely banish features. Once you align with your team on user objectives, features play a major role in product development. However, they should fall in line after user outcomes at the end of a planning process. They shouldn’t drive the planning.