Product backlogs can become overwhelming and disorganized, but creating future sprints and using divider tickets can help manage them. It's important to prioritize grooming and reviewing tickets and sync with the development team on backlog management preferences.
Team Producter: Hello Clement! Would you tell us a bit about you and your career path in product management?
Clement: I’m currently the founder of Product Teacher, a product management education company with the mission of making product management easier for everyone.
My career path into product management was somewhat accidental; yet, the overarching theme of my career path has always been to “find and address unsolved pain.”
My first job out of college was business consulting, but I accidentally pivoted into user research in that role.
My fellow consultants and I provided recommendations to client-side senior executives through an analytics platform, but this analytics platform was difficult for our clients to understand and use.
I captured feedback from my clients and shared it with our engineering team to convince them to create more intuitive user experiences. Together, we prototyped different workflows and ran them by clients to validate them, and we successfully shipped a new generation of intuitive products.
My engineers asked me to serve as a user researcher because I had found and addressed an unsolved pain, and I accepted.
I then accidentally pivoted from user research into product management.
As a user researcher at a real estate company, I had identified a high-potential customer segment that we could build unique offerings for. But, our executive team wasn’t yet ready to act on this customer segment because it was a potentially risky bet.
I conducted market research, ran competitor analysis, and spun up financial forecasts to prove that this segment was worth tackling, and I convinced my leadership team to fund this new business line.
They asked me to serve as a product manager because I had found and addressed an unsolved pain, and I accepted.
I made yet another accidental pivot from product management into entrepreneurship.
In my early years as a product manager, I struggled to figure out the basics - how to write a spec, how to conduct user research, what data to analyze, etc. I decided to write down everything that I knew, so that other people wouldn’t run into the same problems that I did.
Once people found my essays, they started to email me and call me, asking me to help with PM interviews, getting promoted, and other career services. I decided to try running a business to help as many PMs as I can to succeed.
My customers asked me to serve as a founder because I had found and addressed an unsolved pain, and I accepted.
I’ve written in much more depth on each of the different stepping stones of my journey into product management. You can read more here.
Team Producter: How do you manage product feedback? When it comes to integrating feedback into the product, what steps do you go through from the start?
Clement: Crucially, as product managers, we have to focus on the underlying pain points represented in the feedback, and not just simply accept the feedback at face value.
Not all feedback is created equal. While the customer pain behind every piece of incoming feedback is valid, their feature suggestions may not be.
What do I mean by this? Here’s an example.
If someone asks you to build a purple circular button on the top left-hand corner that lets them skip one of the fields in your workflow, that person has a real point of friction when it comes to “needing to skip a field.”
Maybe they don’t have access to that information, or maybe they don’t feel comfortable entering that field, or maybe capturing that information is not the best use of their time because there are higher-priority fields to capture first.
But, even though their pain is valid, it’s not valid to build a solution exactly the way that they requested. PMs, designers, and engineers are all equally responsible for ensuring that the products that they build are scalable, consistent, and coherent; accepting every feature request at face value causes fragmentation of the product.
Therefore, to ensure that feedback aligns with the product strategy, we must evaluate the feedback against the product vision and roadmap.
Sometimes the feedback from your customers makes sense to build out, while other times it may not make sense at face value. Understanding which customer segment the feedback represents, and how broad and deep the pain point is, can help assess whether it aligns with the product vision and roadmap.
To manage product feedback effectively, we should establish a regular cadence for evaluating new product hypotheses, e.g. every two weeks or every month, depending on the scale and complexity of the product. This regular cadence ensures that the feedback that is informing our decisions is still fresh, and that we haven’t missed any crucial or urgent opportunities.
But, managing product feedback can be overwhelming, especially at scale. After all, product feedback can come in various forms, such as feature requests, bug reports, and user suggestions.
One way to reduce this mental overhead is to spin up a running list of “buckets” of feedback. That way, instead of having to assess every piece of feedback on its own, we can look for themes and trends, and we can focus on identifying new buckets rather than diving into the nuance of each individual piece of feedback.
This bucketing can also be helpful for turning qualitative feedback into quantitative metrics. We can count the number of points of feedback in each bucket, and we can track trends over time.
Depending on the maturity of your product, you’ll need to use different processes and systems to handle feedback. At a small scale, you can read every piece of feedback, but at a large scale, it may not be feasible. In such cases, having tools that synthesize or tag the feedback can help make this flood of information more manageable. Alternatively, having a filter can help weed out irrelevant or duplicate feedback.
Keep in mind that customer feedback is the lifeblood of every product strategy, every product roadmap, and every set of product goals & metrics.
Whenever we go through annual or quarterly planning exercises, we should start from customer feedback. Whenever we decide which experiments to tackle in the next sprint, we should start from customer feedback. Whenever we decide which kinds of metrics to measure the progress of our product, we should start from customer feedback.
Feedback provides valuable insights into the customer's pain points, needs, and wants. However, not all feedback can or should be acted upon.
Our job as product managers is to make the difficult decisions on which points of feedback will truly advance the strategy of our product, so that we create as much value as possible for customers while simultaneously capturing as much value as we can for our businesses.
For a more comprehensive system on using feedback to set up product strategy, OKRs, and experimentation hypotheses, we recommend using a mental model called the “opportunity solution tree.” In case it’s helpful, we discuss this mental model in depth in this recorded course.
Team Producter: What subjects or areas do you document while developing products? How do you benefit from these?
Clement: Solid product documentation enables your product development team to keep track of what they're currently doing, what they've already done, and what they need to do next. I’ve found that the key product documents to establish and maintain are the product strategy doc, customer/user research, product specs, and the decision trail for design and engineering.
A well-defined product strategy is critical as it provides a clear direction for the team. It should outline the product's goals, objectives, and the problem it seeks to solve. Documenting the product strategy ensures that everyone is on the same page and aligned towards achieving the same end state. We dive deeper into how to write a compelling product strategy one-pager here.
Clear user research notes are also essential for product development. User research helps to uncover insights into the user's behavior, preferences, and needs. Documenting this research helps to ensure that the team has a solid understanding of the user and can make informed decisions. User research should be documented so that we can quickly onboard new members to the team while also creating institutional knowledge that empowers our cross-functional stakeholders to empathize more deeply with our customers.
Another crucial document is the product spec, as the spec identifies which customers we’re solving for, what pain points we’re addressing, and what sort of solutions are in scope vs. out of scope. By having a product spec, we can ensure that the team has a clear plan for developing the product and helps to minimize miscommunication. We won’t wind up in a place where people are building unnecessary scope or are solving for the wrong pain or for the wrong customers.
And, decision trails are helpful for designers and engineers to track the various execution-oriented decisions they’ve already made, so that they don’t need to reinvent the wheel. For example, should a given function be synchronous or asynchronous? Should a user experience have a floating sticky panel, or should the panel be in-line with the page and scroll accordingly? Tracking these decisions helps reduce mistakes and conflicts.
One overlooked area of product documentation: creating documentation for setting up products for customers or internal testing can also be helpful. This documentation ensures that the team can efficiently set up and test the product without any hiccups, and it saves time and prevents costly errors in production environments.
Team Producter: How often and how do you keep a changelog? If not, are you considering starting? Why?
Clement: A changelog is an effective way to document changes and ensure that everyone is aware of them. However, the update frequency and the content of the changelog should vary depending on your target audience.
Keep in mind that different audiences will have different changelogs, because they need and want different kinds of information from you; therefore, you shouldn’t be surprised if you’re maintaining multiple changelogs at the same time (e.g. one internal changelog and one external changelog).
For example, in B2C or SMB, creating marketing excitement for customers is crucial. In such cases, a weekly changelog can be effective in keeping your customers engaged and informed about the latest updates and releases. This weekly changelog should be relentlessly upbeat and demonstrate forward momentum over time.
On the other hand, in enterprise B2B, customer adoption is crucial. Businesses can take weeks or months to adopt new products, so providing a weekly changelog is going to be overwhelming for them. In such cases, a monthly changelog can be effective in providing regular updates to the customer while ensuring that the changes are tested and stable.
For internal tracking for cross-functional stakeholders (e.g. sales, marketing, support, etc.), a monthly changelog can also be effective; but, the cadence that you use depends heavily on the velocity of your product. In some cases, quarterly changelogs are sufficient.
Team Producter: Is there an ideal way to keep a backlog? How long should unstarted tasks remain in the backlog? Is it necessary to add every task to the backlog that comes to mind?
Clement: Product backlogs serve as a crucial tool for capturing ideas and inbound bugs from various stakeholders and customers. As product managers, we rely heavily on our backlogs to prioritize what's ready to be loaded into the next sprint, which ideas need further grooming, and which initiatives should be postponed.
However, a common problem with product backlogs is that they can quickly become disorganized and overflowing with tickets that never get reviewed, causing confusion for stakeholders and slowing down the development team.
Typically, backlogs hold three kinds of tickets:
1) groomed but deferred,
2) prioritized but not yet groomed, and
3) not yet reviewed.
First, for groomed but deferred tickets, it's helpful to create placeholder future sprints such as N+1 and N+2 before the current sprint N ends.
For example, let’s say I’m currently in Sprint 25. I’ll create Sprint 26 and Sprint 27 and load both of them with tentative priorities.
Then, as soon as I close Sprint 25, I’ll kick off Sprint 26, create Sprint 28, and load Sprint 28 with tentative priorities.
By doing so, these tickets are lifted out of the working area of the backlog, allowing the backlog to be meant solely for items that require additional thought and review. Additionally, creating future placeholder sprints provides clarity across the organization on what the team plans to tackle next.
Then, to manage prioritized but ungroomed and not yet reviewed tickets, creating dummy "divider" tickets in the backlog can be helpful. These divider tickets provide a visual cutoff for categorizing the tickets in the backlog.
Here’s how I usually name these dividers:
- — PRIORITIZED NOT GROOMED —
- — NOT REVIEWED —
- — END OF BACKLOG —
For any tickets that sit below “prioritized but not groomed” (but above “not reviewed”), they should be groomed in priority order and then loaded into the appropriate future sprint. Don’t spend any time grooming non-prioritized tickets, because those tickets are not necessarily the highest-value work items.
For tickets that sit below “not reviewed” (and above “end of backlog”), those should be reviewed and placed into “prioritized but not groomed” in priority order.
And, any tickets that sit below the “end of backlog” line are ones that need to be re-organized into “not reviewed”, as they typically came in through non-standard channels, e.g. someone within your company filing a ticket into the wrong queue.
Depending on how your team uses backlogs, you might decide to keep all unstarted tasks in the backlog forever, or you might decide to clear out the backlog on an annual basis; check with your dev team to see what their preference is.
Similarly, some dev teams prefer that every idea is added to the backlog so that they have full visibility; other dev teams prefer that only ideas that have been validated by the PM with a clear business case should be added. Sync with your dev team to determine what makes the most sense for your needs.
Producter is a product management tool designed to become customer-driven.
It helps you collect feedback, manage tasks, sharing product updates, creating product docs, and tracking roadmap.
