Prioritization is going to be one of the most difficult challenges you face. Even as your team grows, your ambitions will inevitably grow too, and you’ll always be faced with choosing which work truly matters.

Between your own vision and suggestions from your customers, you probably won’t ever have a shortage of ideas, but knowing what to work on next can be incredibly challenging. Priorities shift, and new opportunities arise that constantly distract you. Questions and doubts may surface. Are you simply hearing from the vocal minority? Does the idea align with your vision? How many customers will use it if you build it? How frequently will they use it? How much will they gain from it? And that doesn’t even touch on internal projects to help you manage the business. Those need time too.

Over the years, I adopted some strategies to help me with this. Even today, I still feel that this is the most difficult part of running a web application. How do you apply your limited resources to create the most value and happiness for the largest number of customers? The answer is simple–but it’s easier said than done.

Avoid “Flavor of the Week” Prioritization

It’s all too easy to work on the first thing that pops into your head when you’re done with a project. Sometimes it will be a customer request, other times it will be something that sounds fun. But you have to make every idea compete with all of the others. Ideas have to make a case for themselves and justify the time you’re about to spend implementing them.

Remove the Rose-Colored Glasses

All features have consequences–whether to some of your customers or your codebase or your focus. You must be objective with features. At times it can be entirely too tempting to look only at their upsides. It’s often easy to decrease the priority of a given feature relative to others if you have a clear picture of the drawbacks that come with the feature. Don’t look at just the benefits of the feature. Think carefully about the level of effort to build, support, and maintain that work.

Don’t be too afraid of ambitious features, but make sure they earn their keep before you set out to build something that could drastically increase support or negatively affect performance.

Understand the Ripples

All features have consequences far beyond what’s immediately obvious. I like to think of this is as the ripple effect. Imagine you were to throw a single stone into a pond: you’d see predictable rings of concentric circles in the water. If you were to throw two or three rocks, all those waves would begin to haphazardly interact with one another. The same thing happens with software. As far back as I can remember, no matter how simple an enhancement may have seemed, it invariably created ripples I couldn’t foresee until I started writing code.

To lessen the blow of any unexpected side effects, whenever I got the itch to add something, I’d often create a branch in source control, and I’d just start hacking on it. That probably doesn’t sound all that unusual, but I’d start that branch with every intention of deleting it and throwing away the work within a few hours. I consider it merely an exploratory expedition–which means the feature has to earn its way into the main code branch rather than fall into it by default.

I’d rarely spend much time on these hacking expeditions, but they helped me understand these types of features and where their ripples might occur. This won’t work with everything, but it often came in handy when I needed more information to make a decision about an enhancement’s priority.

Let Ideas Percolate

Most of the time, you’ll have a gut feeling whether a feature is a good idea or not. These initial reactions can be overwhelmingly for or against that idea. But if your hunch were to be a strong no, you could end up dismissing what turns out to be a key feature. And if your feeling were to be a strong yes, there’s a chance you might commit to a feature that’s not going to work out. Neither of these is good.

No matter how good or bad an idea might seem at first glance, give it a week or two to settle. Think about it. Sketch it out. Let your subconscious mull it over for a while. You could be in bad shape if you were to take an idea and implement it too quickly, or dismiss an idea without giving it enough thought. Don’t let the idea rot, but don’t always trust your gut either.

Time-Box It

When a feature’s development begins to drag on, it can drain your team’s motivation. If you think a feature will entail a prolonged development cycle, it needs to be more important than all the other features it would delay. This can create dilemmas if your larger features were constantly pushed back because of their scope. In such cases, try to break down your more ambitious initiatives into smaller steps that can gradually get you closer to shipping the larger feature without blocking development of the smaller ones for extended periods of time.

A good goal is to ship something meaningful every couple of weeks. You don’t need to ship new features every two weeks, but you should ship code that gets you closer to your vision. Perhaps while you’re working part-time in your early days, that might mean two weeks’ worth of development time rather than two calendar weeks; but the goal is to ship incremental improvements regularly.

Use Data to Drive Decisions

You can also let the data help you decide. As a small company, you’ll have unprecedented access to data that can help guide your decisions. This data may be in the form of cancellation exit interviews, logs, database queries, or third-party tools. When faced with a decision without an obvious answer, your safest bet is to go with the data. We probably didn’t do this enough, but were always glad when we did.

Tie Prioritization to Business Goals

I’ve found that one of the best ways to prioritize features and new work is to have quarterly goals and objectives. Every quarter, define the overarching theme, and then prioritize according to that goal. For instance, your goal may be to reduce support requests, so projects fixing usability errors or adding self-service features will move up your list.

Prioritizing Features: Who’ll Use It and How Often? Des Traynor from Intercom puts feature prioritization in context by going over how usage and audience should influence your features’ priorities.

Features and Physics Envy Des Traynor has another great article about prioritizing features based on their combinations of development effort and customer value.