Product backlogs need to die

I’ve been building software for 11 years. I have to admit for the larger part of those 11 years, I’ve used product backlogs to get stuff out the door.

Some of those products were successful, some of them crashed and burn in a huge ball of scrum fire. If there is one piece of advice I give now to new software founders is to first release a minimal product and then iterate based on customer feedback. You see, the software cycle has two phases, you are either:

1. Building your first release
2. Releasing iterations

There’s only one real use for a product backlog: your first release. Here’s why: As you are building the product, you need to go through a backlog of minimal set of features that you are going to launch with (otherwise known as MVP). This backlog will both keep you and track and also let you know when your first product release is ready. After that, backlogs are just ‘busy lists’. They are intended to keep the team accountable by churning out features on a predictable basis. They are definitely not intended to keep your customer in mind and build a product that will sell itself.

What’s inherently wrong with the backlog?

Backlogs are a master list of unvalidated ideas, presumptions and worst of all, stakeholder egos. You know the type of feature I’m talking about: the one than came from someone because they know better than anyone else.

Time to kill it

After your first product release, work hard to get a few customers on board, then stop. Listen to them, ask questions and solve the issues they are bringing up. There, you are now iterating on customer feedback. A happy customer is not only a returning customer but also is your advocate. They will recommend your product and inherently bring more customers.

Iterate, release and measure

As old as the measure word is getting in the software world, it is what it should be. As software builders, we should be listening more, building what we learned more and then measuring. Measuring how many times a feature is used or how someone is using it will give you valuable insight in how it is directly impacting, positively or negatively, your product and business.

This is a bunch of words, Max. How do I do this?

Here’s a very simple way on how you can make it all happen:

1. Release your first product-solution (I’ll write more about product-solution soon) with a minimal viable set of features.
2. Set up the right channels to listen and talk with your customers. (Email? Support desk? Chat, etc.)
3. Set up the right analytics to look at usage, metrics, etc.
4. Get customers in the door
5. Look at data, engage with your customers and their feedback.
6. Prioritize the items (more on prioritizing soon!)
7. Build it, ship it
8. Go to step 5, repeat.
9. Kill ideas & features that are not adding any value to your customers, and inherently, your business.

It’s a straight forward process, with simple communications channels and a spreadsheet.

Changing the release mindset

This all comes with a good price to pay: you (and your team) need yo change the way you build and release software. My invitation here is to opt out of 6 to 12 month product backlogs where you mindlessly churn out features. Instead, have enough roadmap to 2-3 months of work, and release constantly your projects. Tweak your roadmap fast as you act on customer feedback and react way faster than your competitors when eventually the market shifts. Thanks for reading! I’m currently building a product to help product makers prioritize and build a product customers will love. If you are interested in an early invite hit me up at andresmax at gmail.com.

Some of those products were successful, some of them crashed and burn in a huge ball of scrum fire. If there is one piece of advice I give now to new software founders is to first release a minimal product and then iterate based on customer feedback. You see, the software cycle has two phases, you are either:

1. Building your first release
2. Releasing iterations

There’s only one real use for a product backlog: your first release. Here’s why: As you are building the product, you need to go through a backlog of minimal set of features that you are going to launch with (otherwise known as MVP). This backlog will both keep you and track and also let you know when your first product release is ready. After that, backlogs are just ‘busy lists’. They are intended to keep the team accountable by churning out features on a predictable basis. They are definitely not intended to keep your customer in mind and build a product that will sell itself.

What’s inherently wrong with the backlog?

Backlogs are a master list of unvalidated ideas, presumptions and worst of all, stakeholder egos. You know the type of feature I’m talking about: the one than came from someone because they know better than anyone else.

Time to kill it

After your first product release, work hard to get a few customers on board, then stop. Listen to them, ask questions and solve the issues they are bringing up. There, you are now iterating on customer feedback. A happy customer is not only a returning customer but also is your advocate. They will recommend your product and inherently bring more customers.

Iterate, release and measure

As old as the measure word is getting in the software world, it is what it should be. As software builders, we should be listening more, building what we learned more and then measuring. Measuring how many times a feature is used or how someone is using it will give you valuable insight in how it is directly impacting, positively or negatively, your product and business.

This is a bunch of words, Max. How do I do this?

Here’s a very simple way on how you can make it all happen:

1. Release your first product-solution (I’ll write more about product-solution soon) with a minimal viable set of features.
2. Set up the right channels to listen and talk with your customers. (Email? Support desk? Chat, etc.)
3. Set up the right analytics to look at usage, metrics, etc.
4. Get customers in the door
5. Look at data, engage with your customers and their feedback.
6. Prioritize the items (more on prioritizing soon!)
7. Build it, ship it
8. Go to step 5, repeat.
9. Kill ideas & features that are not adding any value to your customers, and inherently, your business.

It’s a straight forward process, with simple communications channels and a spreadsheet.

Changing the release mindset

This all comes with a good price to pay: you (and your team) need yo change the way you build and release software. My invitation here is to opt out of 6 to 12 month product backlogs where you mindlessly churn out features. Instead, have enough roadmap to 2-3 months of work, and release constantly your projects. Tweak your roadmap fast as you act on customer feedback and react way faster than your competitors when eventually the market shifts. Thanks for reading! I’m currently building a product to help product makers prioritize and build a product customers will love. If you are interested in an early invite hit me up at andresmax at gmail.com.