Do You Have a Product Backlog?

Picture yourself as an eager entrepreneur with a strong vision for a software product that is going to solve lots of problems within your industry. You work through the early phases of testing your problem-solution fit and develop your minimum viable product (MVP). It’s post MVP launch, and you start learning some things. The software product world is new to you, but you do your best to make adjustments based on early market feedback.

Are you there in your head? Great! Now let me ask you some questions:

1. How are you collecting your feedback?
2. Where are you tracking it?
3. How are you analyzing and prioritizing it?
4. How are you deciding what the product needs next?

If you know the answers to all these questions, you are ahead of the game. If you don’t, that is OKAY.

Most startups are focused on launching a business and all the things that go with it; managing the product is not always the first thing on their minds. But fear not, I am here to help provide you some guidance to these questions and set you up for success as you navigate your product journey. Putting these things in place early will prompt your future self to thank your past self because, let’s be honest, that is a wonderful place to be.

Collecting Feedback

Regardless of where you are on the product journey, feedback will be coming your way. This can come from various people and channels. The information you receive will fall into different informational categories.

• People. When we think of feedback, we typically think of user feedback, and yes, this is information you want to have and be intentional about collecting. But internal feedback is valuable, too. Here are some different groups that you might want to start collecting from (while managing expectations):
  • Development
  • Quality Assurance (QA)
  • Sales
  • Marketing
  • Executive Leadership
  • Designers
  • Product
  • Customer Support
  • Training

• Informational Categories. Here are some of the main categories of product feedback:
  • Overarching market pain points. This is gold. Existing market pain points means problems to be solved. If solved properly, this will lead to market differentiators. This is a great path to move past product-market fit into business-model fit.
  • Feature Requests. Receiving these in a steady flow is a good indicator of product-market fit; people are using your product. “Features” are what you would expect them to be: adding new functionality such as a reporting tool or generative AI.
  • Change Requests. I break these out separately from features because they normally add or change how a feature or functionality works. These aren’t bugs. Your team launches a feature, you get it in the hands of users, and you learn that a subset of your group needs a slightly different workflow from an existing thing. This is a change request.
  • Bugs. To be short, these are defects. Bugs can range by type: functional, performance, usability, security, logic, localization, design, compatibility, etc.
  • Technical Debt. Software needs to be maintained, frameworks and libraries need updating, the product needs to support something that was not originally considered, and other factors that happen when managing developers at different skill levels at different parts of their journeys. Technical debt happens. Ignoring it can cause larger issues later for the product. Just like you would do maintenance on your house or car, you also need to maintain your product.
  • Design Debt. Tradeoffs will happen when you are looking to launch a product or feature in the market quickly. This can result in reducing the level of effort on the product, design teams being constrained by time and budget, or needing to come back to implement a scalable design system. Just like Technical Debt, Design Debt should be prioritized and accounted for.

Regardless of who is collecting the feedback, a few things should happen:

• The “why” questioning. When anyone adds to a backlog, there should be a small questioning session to discuss it.
  • “Why” do they want this thing? What is the root pain point being felt, or what is the benefit that the user will experience? You might have to ask this a few times to get to the bottom of things. It is human nature to often jump to a solution vs. exploring the actual need. While it is still worthwhile to hear the solution, the thing you care about more is the pain or need. Solving the underlying need and doing it in a way that keeps to the product strategy will maintain alignment with the business strategy. Your product identity needs to be maintained. There will be things you never build because it’s not what the business or product is. It’s a fine balance to defend the product vision and know when it’s time to evolve.

• Capture who is providing the feedback. There are additional things that may be helpful. At a basic level, you should capture:
  • External. Customer segment, persona, organization, title, strategic importance to the company.
  • Internal. Department, title.

• Document, document, document. There is a chance that you are not the person who uses the information later, or the backlog item sits long enough that you need a refresher. The more you can capture, the better off you are. Some tips here:
  • If you are lacking time, at a minimum, you can use the standard user story format:
    • As a [Persona], I want to [Goal] so that [Benefit].
    • There are other templates out there, but this is a commonly used format.
  • Titles. Name this something that makes sense and describes what it is at a glance. This will help with deconflicting duplicates later.
  • Description. When lots of information has been collected, context can get lost. Document as much as you can, with the mindset that you may not be available to back brief someone later.

• Place information in a location that can be accessible, used, and analyzed.

Tracking Feedback

We all stay busy, even busier if you are wearing multiple hats. Where and how you track feedback can be a lifesaver for you. Getting in the habit of documenting things as you hear them and having others do the same will pay dividends. It sounds simple, but when you collect feedback from various sources and categories, it can get messy.

Here are a couple of options for tracking feedback (there are MANY out there) at varying levels of cost. Every company will have different needs. Do some digging and see what might work best for you.

• Microsoft Excel. The basic of basic options. If you need a place to start and are unsure where, this is always an option. It is not always a great collaboration tool and can be more manual than other tools and/or requires more knowledge to set up something more useful.
• Atlassian Jira or Microsoft DevOps. When working with a development team, it is highly likely one of these platforms is already available to you. Both tools can be customized to meet your needs and will integrate nicely into your Software Development Life Cycle (SDLC). Some might find it intimidating at first, but it is worth learning.
• Atlassian Trello. They offer a free version, but the good stuff comes with a paid tier. It is an easy-to-use option that allows for customization and automation and is great at collaboration. It also has a mobile app, for easy use when you are away from a computer.
• Monday.com. This will have a similar feel to Trello, but the layout is different. This also has automation options when operating on a paid tier.

Additional things to consider when you have multiple backlogs to prioritize: collaboration with team members, tags, places to capture estimates, adding attachments, automations, notifications, etc.

When researching the options above, think through which features may help streamline your processes.

Analyzing & Prioritizing

I am only going to scratch the surface here. When we say analyzing, we mean applying some level of critical thought to the items within your backlog. Over time, that backlog will grow. Not everything will stay relevant. Applying some sort of backlog review will aid you in assessing what should stay and go (insert music queue…should I stay or should I go now…). Additionally, there will be things that need more immediate attention and should jump to the front of the line depending on product and business needs.

You could have a wide range of items to review from various informational categories. Suppose you have enough people within your company with the right subject matter expertise. In that case, you can lean on them to be a product owner for a particular backlog category (think design debt belonging to your product designer or your architect for the technical debt backlog, project manager or QA for bugs, etc.). Want to learn more about the role of the product owner? See my blog post, “The Life of the Product Owner.”

If you are a team of one or don’t have others to assist you, it will be up to you to categorize these things and prioritize what gets done. This can be challenging at times. You will feel the pull from various directions – the market, business objectives, product vision, software things that need to be addressed, and so on. Having these items in a proper category places you in a position to prioritize each grouping, and then you can weigh things based on short-term and long-term objectives.

Not all things are created equal. Your architect or development lead can give you a rough order of magnitude (ROM) on those items in your backlog, and it may help you determine where those things fall within a ranked priority. Be warned, you will have scary ROM items, and there will be times when the cost is well worth it. Don’t be afraid to make those decisions, especially if they will set you up for long-term success.

There are some out-of-the-box methods to aid you in prioritizing your backlog, RICE scoring being one of them. See my post, “One Tool to Consider When Tackling the Dreaded Backlog” for additional information. Another method is called MoSCow (Must have, Should have, Could have, Won’t have). Your AI chat of choice can help bring you up to speed on this and others.

Overall, staying current on your backlog and prioritizing it will aid you as you look to develop a product roadmap.

The Product Roadmap

A product roadmap is a tool to tell the story of where the product is going, create alignment, and communicate high-level timeline goals. It is not meant to be set in stone. However, if there is a lot of volatility with your roadmap, you could lose trust, and it becomes a less effective communication and alignment tool.

There are lots of templates out there for creating a roadmap. PowerPoint has templates you can use, your favorite search engine can provide you with examples, and there are various products that want to sell you tools to help you automate this.

Below is a very basic template for a roadmap. Roadmaps don’t have to be fancy as long as they fulfill their intended purpose: communicating the product strategy and direction, setting expectations, and gaining alignment.

Along the top, the template provides high-level quarters for a timeline. We are intentionally not applying dates to help manage expectations. The left side provides categories. These can be adapted based on the product’s needs.

• Strategic – Reflects the items that align with the long-term product vision and the business objectives.
• Annual Initiatives – Because most businesses will have things they want to address on a yearly basis.
• User Feedback – Provides a method to respond to user feedback should it fall outside the top two things.
• Tech Debt (Tech Debt and/or Design Debt) – These are not bad words. Maintaining a product for the long term means you will have debt. As mentioned earlier, it is no different than car or house maintenance.

The product roadmap should be communicated within your organization. It can be hard at times to communicate everything that goes on in the world of the product and backlog. This is a great tool to gain buy-in from higher-level leaders and provide transparency to others in your company.

Remember the four questions at the beginning of this post? Hopefully, you not only have an idea of how to answer them but are now equipped to care for and nurture your product. While starting something new is often the hardest step, this tactical work will lay the foundation for executing a product strategy that aligns with your vision and business objectives.

Lindsey Hruby-Yardley Project Integrator

Lindsey was born and raised in Lincoln, Nebraska. Her career started at 17 when she joined the Nebraska Air National Guard. Nineteen years later, she is currently serving as the Director of Innovation. On the civilian side, Lindsey worked at the Nebraska State Patrol as a Crime/Intelligence Analyst, then switched to the private sector. Before joining Don’t Panic Labs as a Project Integrator, she worked as a Product Manager, Business Development Manager, and spent some time as a Product Strategy Director for a retail subscription box startup company.

See Full Bio