There’s a common view that Product Managers shouldn’t spend their time managing the backlog or being the team’s Jira admin.

And it’s true — that’s not the full scope of the job.

But it doesn’t mean we can ignore it entirely.

I’ve seen teams accumulate hundreds of backlog tickets simply because tidying up is “not my job”. And when it’s everyone’s job to manage the backlog, it quickly becomes nobody’s job.

You don’t need to hire a backlog administrator. But someone does need to take care of it — and that someone might be you.

Here are a few tips I’ve picked up.

1. Don’t add tickets “just in case”.

A ticket should exist to achieve an outcome or deliver some kind of value. If it’s vague, or “we might need this later”, consider keeping it in a doc instead.

2. Prune the old stuff.

That one-off bug from six months ago that hasn’t happened since? If your logs don’t show it keeps happening, let it go. If it’s not something you’re going to fix right now, leave it to your logging tools to tell you if issues recur - rather than keeping a ticket you’ll probably forget about.

3. Watch out for duplication.

If one ticket superseded another, great — close the one one. The backlog shouldn’t be a museum of your product’s past lives.

4. Keep an eye on the total size.

If you’ve got hundreds of tickets, chances are you’ll never look at most of them. Decide on a healthy limit and trim when needed.

5. Practise good refinement.

Spend time on tickets that matter. Don’t overthink low-value items. Use your time (and your team’s) wisely.

You don’t have to spend hours in Jira every day. But a tidy, well-maintained backlog can keep your team focused, aligned, and a lot saner.

Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.

If you found this post useful, why not subscribe below?

Subscribe now

Our roadmap looked good. But week to week, the team was working on too many different things.

Everything we did was valuable — but it didn’t always feel that the product was moving forward.

Tickets were scattered across multiple themes. Epics dragged on. Sometimes, it was hard to explain what we’d achieved the week before.

Our priorities seemed clear, but our attention was fragmented. We were trying to do too many things in parallel, and context-switching was slowing us down.

To solve this, I made a small and simple change: focus weeks.

What’s a focus week?

A focus week is when the whole team agrees to work on one problem area or theme — and only that.

One of our early candidates was a theme where we had lots of small, but interconnected tasks. Tackling them one by one could have led to rework or confusion.

But by focusing on the theme as a group, we could solve a group of problems pragmatically — and completely.

How did it go?

We didn’t necessarily get more done than usual. But the type of progress changed.

Everyone was connected to the same goal. The priority was clear. We made steady, meaningful progress against the theme.

In fact, we ended up extending the focus week into a second week. The momentum was there, and it made sense to keep going.

By narrowing our focus, we cleared a high-impact set of tasks, and gave the team a stronger sense of purpose.

Try it yourself

Want to run a focus week?

Start small. Pick one clear goal. Communicate it clearly, and clear the decks.

You might be surprised how much chaos you’ll cut by helping your team to focus.

Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.

If you found this post useful, why not subscribe below?

Subscribe now

As a Product Manager, it’s not unusual that I find myself doing delivery tasks — writing documentation, updating tickets, testing new features, and checking in on progress. It’s especially common in scrappy startups, or teams without delivery managers.

But just because I’m happy to run standups or keep the board tidy, doesn’t mean I’m the team’s Scrum Master.

My real goal is to cut through chaos so that product priorities are clear, actionable, and solve real problems for our customers.

On occasion, members of my team have asked if I can raise a ticket for something, to make sure we have one logged. Sometimes I’ll do it — other times I’ll remind the team they can raise tickets too. We’re all on the same team and we can all contribute to the process.

Why you need process in product management

Structure can help with making sure we have documentation, such as product requirement docs (PRDs) and decision logs. This means you don’t have to rely on your memory to explain why you took one route over another.

Putting the most important tickets at the top of the list helps the team to know what to pick up next. However, this is only a small part of the process. It’s super important that the team also understands why something is a priority — and not just that it’s the topmost item.

Following a process doesn’t mean we are project managers. Don’t be afraid to spend time getting the process right. What worked for you in the past may not work for every team. And once the process works, you don’t have to spend much time on it going forward. Just stick to it — and tweak it as needed.

A few of my process tips

Keep your backlog short

As I wrote in last week’s post, the first thing I recommend is having a tidy backlog.

Your backlog shouldn’t contain user feedback, undeveloped ideas, known issues that have little impact, or low value items that you’re keeping just so you don’t forget about them. Move all of these to documentation — or archive them altogether. Be ruthless — only allow refined, worthwhile tickets onto the backlog.

Use themes, not just epics

Adding a field to group tickets together is incredibly useful. An epic should be considered as a defined, clear block of work that you start and finish. A theme can be broader — think of it as a category. For instance, “add referrals to onboarding journey” is an epic, whereas “onboarding journey” is a theme. You can also group tickets by problem or opportunity, rather than simply by sprint, or “phase 1” / “phase 2” — which is likely to cause more confusion.

Link delivery to the roadmap

Make it clear which tickets relate to items on your roadmap. Your team then immediately sees which are the big ticket items that move your product forward. You can also identify which tickets don’t relate to the roadmap, and clarify how they came about — e.g. client requests, bug fixes, or other unplanned work. This will help if you want to track how much of each type of work your team is doing.

Keep decision records

Instead of relying on Slack messages or agreeing something on a call, try to keep light documentation to record things that have been decided, and why that decision was made. They can be part of a wider document such as a PRD. Without decision documents, you’ll keep revisiting past decisions. If someone asks why you made a decision — it’s liberating to be able to send them a quick link, rather than try to recall the details and type it all out.

Good processes are there to support product managers — they aren’t there to create busywork that we do blindly.

In summary

Bringing order to chaos is a product skill, not a project skill.

Process is a tool that product managers use - it’s not our whole job.

When structure helps the team build the right things faster, that’s product leadership — not ticket admin.

Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.

If you found this post useful, why not subscribe below?

Subscribe now

Product inputs can come from many different places. However, not all of this data is equal and actionable. Dumping all of it directly into your backlog will only lead to chaos.

How can you effectively manage this feedback without your backlog ballooning into an unmanageable mess?

Backlog vs Feedback

I think of the backlog as a list of actionable items that we definitely should be doing. An actionable backlog item should have a clear problem statement, acceptance criteria, and an owner. The backlog item should be refined/reviewed with the team, and sized.

The backlog can contain spikes - discovery work - if they are clearly defined and timeboxed.

The backlog should not contain unclear tasks, ideas, feedback, or anything that’s a “maybe”. A sure sign of a task that does not belong on the backlog is one that has a title and no description - or very little in the way of details.

Feedback does not belong on the backlog. As a product manager, it’s up to you to filter this information and make decisions based on it - which can include deciding to take no action. Your job isn’t to simply log all the feedback as tickets.

What are the different types of product feedback?

User feedback: This can include general comments, usability issues, wishlist items, or even complaints.

Client and stakeholder requests: These can come from your sales teams, support staff, or senior stakeholders keen to get features onto your backlog.

Bugs and technical debt: Quality improvements to your product, tidying up after taking shortcuts to get something out the door, or routine refactoring due to library upgrades, performance issues, or simply things your team didn’t know when the code was first written.

Opportunities and bets: Big ideas that don’t neatly fit elsewhere.

So how can you store feedback, and make decisions on it?

User feedback can be held in a central database. This can be as simple as a Notion database, or a dedicated tool such as Google Sheets. You can look for common trends such as opportunities or emerging problems: if several people mention the same thing, maybe that’s worth pursuing. Don’t react to every single comment if only one person says it, unless it clearly aligns with your vision - or is simply a great idea!

Client and stakeholder requests can be held in a similar database to user feedback - though likely not the same one. Unlike user feedback, client and stakeholder requests are the types of feedback you’ll normally need to respond to. You don’t have to do everything immediately, or even at all, but you need to consider the requests and respond with clear reasoning as to why. Keeping track of past decisions can be beneficial if the same requests come up, so you can review your previous response and also consider whether things have moved on since then.

Bugs and technical debt may live on the backlog, if they are things you will be addressing soon. You could also maintain a database of known bugs and tech debt on Notion or a similar tool. This means you don’t lose the information, but you aren’t holding onto a long list of tickets for when you eventually get to them. Creating documentation can also help with planning how to address this type of feedback, instead of looking at individual tickets in isolation.

Opportunities and bets: again, these could live in a database and should be reviewed periodically. Along with most other, these should be quantified. However, quantifying the impact of a bug is different to looking at the potential value of a bet. Bug impact is a lagging impact (it’s in the past) whereas opportunities or bets are a leading impact (we’re trying to predict the outcome). So, even if a bug affects 100 people and a bet could benefit 100 people, they aren’t identical value. Fixing a bug removes a known issue, whereas a bet has an unknown benefit.

In summary

Don’t put feedback directly on the backlog. Filter it first.

A structured feedback system helps you cut through chaos, stay focused, and build a stronger product — without drowning in backlog clutter.

Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.

If you found this post useful, why not subscribe below?

Subscribe now

Our products are long-running things. They have a vision, a strategy, and a roadmap. Projects on the other hand, exist for a fixed period of time.

If we take a bet and want to pursue something new for our product, we might think of this as a project.

A project normally requires more dedicated time and focus from your team than a singular task would. As a result, it’s important to allow sufficient space to work on the project, and also not to run several large projects at once. Ideally, you should run one at a time to avoid splitting focus across multiple objectives.

A new project can be both exciting, but daunting. Where do you start?

Miro is your friend here.

Starting a Miro board

By starting a new Miro board with a blank canvas (or a template) the sky’s the limit. We start with the basics: what is the problem we are trying to solve?

We can then start adding details to the board. We can use post-it notes to quickly jot down ideas and get all of the points written down.

This is an exercise I have run multiple times with stakeholders - to gather details of what’s important to them. I then share the board with my product team, so they can identify any issues and start thinking about the implementation approach.

Prioritisation

We can also use a value–effort matrix to prioritise the ideas. Prioritisation is essential to ensure we are working on the most impactful things first - and avoiding low impact tasks, possibly altogether. Engineering capacity is precious and should not be wasted on “busywork”.

Having all the ideas in one place allows stakeholders to see where the project might go, and can help to identify the most valuable items vs what’s a nice to have.

In summary, by starting a Miro board at the start of your project, you’re taking the time to organise the inputs to your project instead of diving right in. And by prioritising the tasks you want to focus on, you’re maximising the value of what you ultimately deliver.

Hi, I’m Ben Barden. “Cutting Through Chaos” is about organising messy, chaotic information in product management. Head over to the About page to find out more.

If you found this post useful, why not subscribe below?

Subscribe now