Pete Brumm, CTO at Kindful

I prefer software development to be prioritized based on greatest need, taking the smallest steps possible. We do this by fixing or improving components, and avoiding over-engineering. Getting enhancements into our users hands quickly is very important.

Oleg Verhovsky, CTO at CodeFresh

Most of our activities are driven by business. We have a backlog with all important functionality that is very dynamic from one side but very organised from the other.

Our activities are separated by supporting the important use cases (pushing the business ahead) and infrastructure improvements.

Dale Wickizer, CTO at ParkMyCloud

The starting point of our software priorities is business priorities. Our team discusses the various business priorities with sales input, marketing input, product management and engineering input, CEO & CTO input—things like SWOT analysis of our market, what features we need to lead the market, and what features are “table stakes.” These discussions generally result in a list of product features, a priority for those features and very rough timelines.

Once we have those, we discuss them with our board of directors to get their agreement. From there, stories are written and added to the sprint board, sized and executed. We also factor in a lot of feedback from our customers along the way.

Nick Zhu, CTO at Yroo

We have a very integrated environment. An engineer isn’t just working on a list of tasks. Every engineer has a clear understanding on what impact a task working on has. We come up with hypotheses, and each has to be well-explained (including its potential value).

The process is pretty collaborative; anyone in the company is entitled to contribute. During prioritisation, we consider the following aspects:

• Potential gains
• How much effort it requires (Also considering the investment/return ratio)
• How likely it could be true

We bring together every hypothesis with investment, potential return and probability, and this is how we determine our priorities.

Sheng Yang, CTO at Logikcull

We try to take a more holistic approach to software prioritization. It’s easy to focus on business requirements and simply knocking out features left and right. But as you scale out your team, not having the proper engineering process can be a road block for your team’s productivity and satisfaction. I tend to think of all aspects of software development as technical to-dos, so when we prioritize, we tend look at all areas of software development and prioritize them based on need. It can be improving our code release process, scaling out our data processing pipelines, working on SOC 2 compliance, and of course, building out features. Below are our areas of focus.

• Features
• Data processing
• Infrastructure
• Engineering productivity
• Security

Kai Yen, CTO at PurpleSquirrel

We only build things that we hypothesize will have a measurable impact on our 2-3 key metrics, which are primarily conversion points in our signup and purchase funnels.

Sammy Deveille, CTO at Glisser

The very first question you must ask your product owner (or client) is, “What is the fundamental business value behind the request, feature or task?” Do not commit to building anything until you understand the value behind it.

Not only will it help your product owners to clarify the client requirements, but it will also provide your team with a good starting point from which to deliver a product that meets expectations and stays aligned with business goals.

You should come out of this exercise with a clear picture of the most important outcome in the eyes of the client and the product owner, with a relative order of importance of everything else.

1. How long is this going to take to build?
2. What’s the scope?
   1. Functionality: How much is this feature going to affect my platform?
   2. Architecturally: What will be the affected components?

Alec Zopf, CTO at Wellthapp

We have a backlog containing the feature ideas we come up with. We also have a longer term roadmap, so as we build out a product, we have a sense of how the next four-five months look like in terms of features we want to build. And we order those in terms of what features can satisfy new or existing customer needs. There are natural dependencies so we have to complete some things ahead of others.

We take into account the strategic priority of some features. Are there some hypotheses we really want to test in the near term because they might be important new areas of business or they might be new possibilities for users? Is there a simple way to test out what resonates with the users and then we can build it in a larger way?

Aaron Welch, SVP Product at Packet

A lot of it is defined by the management team, which balances user and market feedback against the vision of the company.

At Packet, we prioritize engagement with our community to solicit feedback and gauge priorities. This community includes current customers, prospects, partners, and colleagues. To channel that feedback, we have a publicly available Trello-based roadmap where we encourage people to suggest and vote up features they want to see.

We also have a lot of technical partners who help to drive our business, so we meet with them regularly to solicit feedback and to help us prioritize features.

Eventually, our management team makes the prioritisation decisions based on these inputs, considering budget, people resources, product cycle and timeframe.

Christian Hansen, CTO at Cobalt

Our management team decides what will be built in the next 6 months. In very broad terms, we highlight the areas we’re going to focus on. Based on that, we work in six-week release periods. We try to build a couple big features that support the 6-month goals.

This 6-month focus plan is broken down into 6-week release periods and 2-week sprints.

If the feature falls into our long-term goal, we build it. If just one client requests something, we probably won’t build it unless we have a contract or more clients are requesting it. And the feature has to make sense for our product.

We split our energy 50-50:

• Modernising our product (not new features, rather scalability, stability)
• Building new features (we know the clients are asking for this)

Niklas Gerdt, CTO at Zervant

Prioritisation is done constantly, almost every day. Of course we have long term road maps and that guides our software development. But because things change so often in development, we do minor adjustments and re-prioritisation very often.

Teams use whatever methodology they find best for them. All teams use daily meetings, because they see value in those. Most common methodology is mixture of Scrum and Kanban where there is a goal for next few weeks, but prioritisation is done daily.

Teams also sit in open space together to avoid anything blocking clear communication. People are given freedom to work remotely, but almost everyone prefers to come to the office, because communication is so much better then.

Pete Brumm, CTO at Kindful

I find agile development to work nicely, but it requires commitment and resources to do correctly.

All the tools I have used have the same issue though. Once you get over a hundred or so tasks in a lane, the tool isn’t useable. Don’t blame the tool though, because it is a sign that your process is broken. Have someone manage the board and only put things on the board that can get completed in a couple of sprints.

If you need to look further ahead, use an epic board to represent the bigger picture.

Oleg Verhovsky, CTO at CodeFresh

Set of mind: business first.

We’re trying to adopt the needs, learning the market and once we decide something is important, we prioritise and push ahead. We have thousands of customers using the service, and they provide feedback.

Weekly iterations provide visibility and clarification about what we’re going to do. We try not to change during the week. Every Sunday, we take the most important stuff from the backlog.

We have the ability to speed up the environment on demand so we encourage everybody in the team and customers to provide early feedback. Even if the future is currently in development mode, we’re capable of encouraging customers and getting feedback.

Dale Wickizer, CTO at ParkMyCloud

We use a “modified agile process” for development with 2-week sprints.

Along the way, we have had to learn to be flexible. Things can happen in the marketplace, which have caused us to shift priorities. Sometimes these can be major (e.g., the need for better pricing models or worse, the entire architecture needs to change, etc.).

Sometimes the changes in priority can be relatively simple, like changing the registration flows and improving UX to make it simpler for users to adopt and pay for the product.

Sometimes we get a new idea from our customers and find a way to squeeze it in along with other larger stories.

The bottom line: be agile and be flexible.

Sheng Yang, CTO at Logikcull

Overtime, we tried various things (agile, Pandora’s feature buy, etc.), but in the end, I think we just wanted something simple. Now, we take a more continuous approach to prioritization. The reason for simplicity is to reduce the overhead on planning.

We don’t map out in advance for an entire quarter or anything like that. Instead, we focus on the next 5 projects and stack-rank them. As soon as we move one of them into current development, we add one more to the stack. Once a project is moved to development, we spec it out and break it down in phases (phase 1 usually is the MVP).

With the spec in hand, we start the implementation discussions, eventually breaking down the project into a list of actionable tasks (we use Trello right now). The tasks then get estimated so we have a completion time to report on.

Marc Fletcher, CTO at Echobox

We’ve tried loads of different approaches, and we still don’t feel we’ve arrived at something optimum. What we found worked worst was when a small number of people made product decisions in isolation and allowed decisions to be reversed frequently. Trying to involve as many people in the process as possible and ensuring we try to maintain a planning horizon that is at least one month out helped smooth a large number of issues out.

Valentin Sawadski, CTO at Proglove

We start each release by talking to sales and our customers about which new features and improvements are most valuable for them right now. We also consider which “under the hood” refactoring work is needed on our product. For all possible tasks, we estimate the amount of work required.

Finally, we get stakeholders from sales, service and tech into one room and present them with the following:

1. The amount of engineering resources we have available in this release.
2. How long each item will take.

Then we discuss which items are the most important and will be considered in the release. During the release, the engineering teams decide on their own how they will prioritise their tasks in order to make fast progress.

While this seems a bit old-fashioned, so far this has worked well, because starting with talking to our customers helps us keep an eye on what’s important for them!

Alec Zopf, CTO at Wellthapp

We don’t have a formal process; we have an agile-like process. We operate in sprints, have daily standups, and have a backlog we pick from, though it’s organized like a roadmap. There’s a little bit of waterfall to it.

We’ve tried a handful of different ways to execute on our backlog and we’re constantly perfecting our process. At the end of the sprint, we look at the process and think: what would we change? How can we do better next time? Shall we change time frame? Prioritising? The way we estimate?

We have tried a bunch of little iterations on our process. We mostly stabilized on it now but we’re still working on what is the best way to prioritise, especially as we start to get more feature requests and ideas from our business development team as we get more customers.

Oleg Verhovsky, CTO at CodeFresh

We have a 2-month backlog where we put epics and use cases according to priority, categorised by team or some other area. We try to estimate them and add some clarification of the use cases, complexity and effort estimate.

Then we create a logical version. We split for sprints, which is required only to make some kind of boundaries. Basically, once a feature is ready, even if it was split into several sprints or is in the middle of sprint, we push ahead.

Once the feature is ready and passes a short workflow involving review and feedback, we push to production.

Advice: The definition of done is very important; this is the minimum requirement to call a feature ready.

Nick Zhu, CTO at Yroo

1. Collect ideas from the stakeholders of the company
2. Determine the value of each feature suggestion (also considering investment, potential gains and its probability)
3. Prioritise them
4. Put the most important ones into the backlog
5. Schedule them into sprints

Joao Graca, CTO at Unbabel

We collect information from different teams in the company: sales, marketing, customer service and community. Then we check priorities for the product coming from the team and from the product performance last quarter. We check the effort of each feature and the potential outcome, and we go from there.

Marc Fletcher, CTO at Echobox

Step1: Break things out into implementable user stories as much as possible.

Step2: Collate all user stories based on feature sets into epics.

Step3: Assign the following values to each epic:

• New MRR – The estimated additional monthly revenue completing an epic would bring (in GBP).
• Risk MRR – The estimated monthly revenue we might lose if we don’t build an epic (in GBP).
• Strategic Value – How well a particular epic is aligned with our strategic vision as a company (1-20).
• Total Story Points – The implementable story points are aggregated at the epic level into a total. This encapsulates the effective cost to build something.

Different areas of the company are each individually responsible for assigning these metrics to tickets they feel are important. At monthly planning sessions we then review all the available epics, typically sorting by New MRR first (as those are normally our biggest wins), and pick epics based on a comparison of the other metrics.

Alec Zopf, CTO at Wellthapp

We don’t have a formal process. In some ways, it’s me looking at all the things coming out and sorting them according to biggest business impact for us. I want to get small and important tasks done first. But after that, the way we rank it is more an art than science.

Everything runs through a filter: do we know enough about this yet to start? If the answer is NO, it’s pushed to backlog/feature request for further requirement discovery.

Everything kinda gets ordered based on intuitive priority. Things usually naturally fall into line.

Aaron Welch, SVP Product at Packet

1. We have a weekly management meeting where we discuss the community’s feedback and other suggestions
2. We use an internal Trello board to track the roadmap (similar to public roadmap)
3. Head of engineering help us know what can we achieve (timeframe, capacity) and what additional work we need to put in the pipeline to deliver a given feature.

Christian Hansen, CTO at Cobalt

1. Gather feedback from clients after every engagement and also collect internal and external recommendations
2. Does it fit in our 6-month strategy? If it does, we build it. This is decided by the management team.
3. Create stories and epics for ideas, features. For this we use Clubhouse.

Conclusion

In this post, we tried to feature as many different software prioritisation approaches as possible. Our intention wasn’t to find one best way to do it but rather to show different approaches that inspire you.

If you’re a tech leader working for a startup, feel free to share your approach in the comments below.