Category: product

A Jar of Rocks – a Product Backlog Analogy

I was in a meeting with my manager the other day, and he said something that really stuck with me – he said that I needed to make sure that I was thinking of the product backlog as a jar of rocks. He went on to recount the story that we all heard back in 5th grade science class, and reminded me that the order in which you put the rocks into the jar matters! It directly determines how many rocks you will be able to fit into your jar. You have to start with the big rocks, and then pour in the sand to fill up the rest of the jar. If you do it the opposite way, and start with the sand, you’ll never be able to fit all of the big rocks in.

This directly applies to planning items that will be worked in future sprints. Start with the big rocks, and then pour in a little sand each time. The rocks being big feature components, and the sand being the little fixes and small things that can wait.

What’s a product backlog?

For those of you that are not familiar with product management, a backlog is essentially your list of things to do, broken down in digestible chunks of  work. If you’re using tools like JIRA then you can then sort the items from top to bottom, with the most important things on top, and the less important items on the bottom. The top / bottom ranking, in my opinion, is very valuable because it forces you to rank items in the order that they will be completed. It sets clear expectations of what and when something will be worked.

How to manage a product backlog?

Managing the items in a product backlog can be really really hard. That’s simply because you usually have waring stakeholders – business people want business things, data people want data things, and your users typically want a completely different list of items. As a product manager, you’ll always have to balance the demand of different stakeholders – and this really comes to light when you’re planning the work on the backlog.

I always start with priority of the items on the backlog first. ‘Blockers’ are the first items that you should complete. A blocker is something that breaks some core functionality of the product, and it typically prevents some user from being able to complete their core task. That could be a serious data error that prevents Business Intelligence from being able to run an analysis, a product user from being able to complete their core function, or something equally as bad. A blocker is NOT something that someone simply wants, but it should instead have some serious implication that can be easily measured or seen by many users. Blockers are typically shipped outside of sprints, in a hot fix release.

After you get past any known blockers, you have to start with the ‘big rocks’ that are in your product backlog. These are the features or items that you know will help improve the product or meet some new business objective. They are typically larger items that will take one engineer most of a sprint. Put these items at the top of the product backlog first, and then start squeezing in the smaller items. Some of those smaller items might be user interface bugs, text change requests, and other small tweaks that will usually take a small amount of time for an engineer to complete.

Sorting out your backlog in this way will really help your team stay focused and complete the items that are core to your product’s value prop. Filling in the remaining free time with smaller fixes will create some little wins along the way, as well.

How to groom a product backlog?

If there’s one constant in product management, it’s change. Anyone that’s ever worked on any software development team knows that change – and they change regularly. This means that your backlog should also change regularly! I suggest that every week you review the backlog with your lead dev, and / or any other essential stakeholder. You can then review the items that are on the backlog, and move them up or down as the team sees fit. Performing a backlog groom regularly will help make sure that the team is focusing on the items that are truly necessary, and will keep the sand from building up. Remember, blockers stay in the number one spot – so if you find your team shuffling it downwards, it’s probably not truly a blocker. If that happens, bump it’s priority downward.

Having your product backlog nicely groomed will make sprint planning with your engineers go even easier, as well. When your team can clearly see what’s going on, and they know exactly what they should be tackling, you will see your velocity increase – which is what every product manager wants!

As the product manager, you’re in charge of the process and the flow of the team. Having a clean and ordered product backlog creates a clear list of objectives and tasks that teams can then easily work their way down. This provides clear insight into what needs to be accomplished to the team, external stakeholders, and yourself. As you’re reviewing the product backlog, make sure that you see plenty of big rocks, with the little stuff squeezed in around the edges.

I was recently asked to analyze a product that someone was building, and it left me wondering how exactly I would explain the process to a non product person. It seemed like this interaction could make a nice blog, so without further ado, here’s my two cents on the questions you should think through when you’re analyzing a product:

Analyzing a Product: The Basics Questions

Ask “Why.”

If you’ve read some of my past blogs, then you already know that you should always start with a why. Why would someone use this product? Starting with this simple question, you’ll begin to force the person that you’re speaking with to boil down the idea. This will help you better understand what pain point they’re trying to solve, which in turn will help you craft a product that truly meets a need.

Who will use this product?

If the “why” didn’t get you there, it’s usually helpful to ask who explicitly the creator sees as being the primary user of the product. I dare you to think through the answer that you’re given, and make sure that the persona identified has the need described in the “why.” Identifying the “who” will also help you confirm if the product should be  a web product, a mobile product, etc. Knowing who the intended target of a product is will be essential in your process of analyzing a product.

What do you think your customers want?

People who are developing products in their free time have a tendency to only show their creations to their closest of friends. Which means, some of these core questions are rarely thought that far out. So, when you ask these questions, I would recommend that you dig in a bit. Don’t take the defined target as accurate or right – but instead challenge the person you’re speaking with a bit. If they say that their target market are young moms, think through the user with them, and challenge them on if it’s the right market. This will help you surface thoughts that the person you’re speaking with has been thinking, but hasn’t explicitly said yet, which will ultimately help get you to the core of the product even faster.

Analyzing a Product: Identifying the Problem

What problems will this product help a user solve?

I am a firm believer that people use products to solve some problem. So, when analyzing a product, it’s essential to identify this problem as immediately as possible. If a core problem cannot be identified, then this product might not have a true need – which means that it will most likely not be a successful product. Sometimes the problem is not as ‘surface-level’ as you’d hope, but dig into why the person created the product in the first place, and you might stumble upon the core problems that users face.

Analyzing a Product: Reviewing the Competition

What are the existing products lacking?

When analyzing a product, you have to ask what the existing products on the market lack. This will help you get to the core of the value prop, which is truly the heart of the product and it’s resonating message to future users.

What other products on the market would a user consider using instead of your product?

This question is really just to see what the creators used as their early ‘vision’. Knowing this will help you learn about the creators, and also help you understand the look and feel of their original inspiration. It can also help you more quickly identify if the V1 of the product should be mobile or desktop.

Analyzing a Product: The Switch

What would help motivate someone to switch to your product?

Why the heck would someone use the product!? There better be a dang good answer here – because if there’s not, then you know the product is going to fall flat on its face. This again gets at the value prop of the product. Can you tell how important getting a well rounded answer here is?

Would the user even consider using your product if they are already using a competitors? 

This question is typically a good followup question to the one above – only because it forces the creator to really emphasize the core value prop one again, and usually more concisely than the first answer.

How difficult is it for the user to switch from the other product?

Switching is terrible. There’s a reason we all keep the same crappy cable contracts, cell phones, etc, and that’s because switching is hard! You’ve invested time into all of the things that you use… so why would you be willing to go through this painful period again? Getting to the crux of this question will again force the creator on the idea of the value prop. At this point, if you feel like you have a good impression of the value prop, you can leave this one out.

Analyzing a Product: A Few Other Thoughts

Have you asked many people about your product? What do they say?

Creators should be asking everyone about their products! If they’re not, then they’re afraid of something – and if they’re afraid of something, then they typically know something that they’re not telling you.

What would you Google to find this business?

This one is more about helping the creator boil their concept down to a few word phrase. This is again about getting at the value prop – which is essential for the creator, and the product person! You must know what drives your user!

Analyzing a Product: That’s All!

There you have it! The above are the initial questions that I typically ask when reviewing a product with someone. These questions are only intended to be guiding questions, and they are by no means a required list of questions that you must ask in a certain order – instead, they’re just guiding questions that you can use to help get to the core of a product, and better feel out the creator of the product. Have fun analyzing products, and let me know if you ever have an additional questions!