A product backlog is a prioritised list of everything that might need to be built, changed, or fixed in a web application. It is the single authoritative record of outstanding work, from large feature requests down to small bug fixes and technical improvements. Unlike a fixed requirements document, a backlog is expected to change as understanding deepens, business priorities shift, or technical constraints emerge.
Each item in the backlog should describe a piece of work in terms that both the business and the development team can understand. For a CRM system, an item might read: "As a sales manager, I need to see a dashboard of overdue follow-ups so I can reassign them." That description captures who needs the change, what it achieves, and why it matters. The development team then adds technical detail, estimates the effort, and defines acceptance criteria.
The ownership question
In formal agile terminology, the product owner owns the backlog. Ownership here means authority over ordering and content: deciding what goes in, what comes out, and what gets built next. The development team owns the estimates and the technical approach. This split matters because it prevents either side from dictating terms outside its competence.
In practice, the label "product owner" can be misleading for UK businesses commissioning custom software. If you are paying a supplier to build a portal or internal tool, you — or someone on your side — are the effective product owner. The supplier may provide a product manager to help refine items and facilitate decisions, but the prioritisation authority should sit with the business that will use and pay for the system. In a SaaS company building its own product, the founder, a dedicated product manager, or a commercial lead typically fills this role.
What ownership does not mean
Owning the backlog does not mean writing every item alone, dictating technical solutions, or refusing input from developers. It means being accountable for ensuring the list reflects current business value, that items are clear enough to be estimated, and that the team is not left guessing about priorities. A product owner who simply hands over a vague wish list and disappears is not exercising ownership — they are abdicating it.
Custom web application projects
When a business commissions a CRM, portal, or admin system, the backlog typically emerges during discovery. Early items might be broad — "user registration and login" — and get broken into smaller pieces as the team understands the detail. The business stakeholder decides whether document workflows or reporting dashboards come first. The supplier's team sizes the work and flags dependencies. A contract that fixes the entire backlog at the start is essentially a fixed-scope agreement in disguise; a contract that accepts the backlog will evolve is better suited to iterative delivery.
SaaS product development
For a SaaS founder, the backlog serves a different purpose. It holds not only the current build plan but also a longer-term view of subscription features, billing integrations, and onboarding improvements. The product owner here must balance immediate revenue-protecting work against strategic bets. Multi-tenancy architecture decisions, for instance, might sit in the backlog for months before they become the top priority — but they need to be captured and refined before that point.
Legacy modernisation
When taking over or rebuilding an existing system, the backlog often starts with a large volume of "must replicate" items drawn from the legacy application. The product owner's job is to question each one: does this still serve a current business process, or has it survived only through inertia? A modernisation backlog that merely copies the old system's feature list without challenging it wastes the opportunity to simplify.
Who can add and reorder items
Anyone with relevant insight should be able to suggest a backlog item — support staff reporting recurring complaints, operations managers spotting inefficiencies, or developers identifying technical debt. But only the product owner should have the authority to accept an item into the backlog and position it relative to other work. If multiple people can reorder the list independently, the team loses a coherent direction.
Connection to acceptance criteria
Backlog items without acceptance criteria are requests without a definition of done. Before an item is ready for development, the product owner and the team should agree on the specific conditions that will confirm the work is complete. This is particularly important for business systems where a feature might appear to work in a happy path but fail under edge cases — for example, a permissions change that works for individual users but breaks for role-based access groups.
Treating the backlog as a fixed contract
A common mistake in commissioned projects is to freeze the backlog after discovery and treat it as a binding scope. This removes the main benefit of a backlog: the ability to reprioritise as you learn. If a supplier insists on a fixed list, understand that you are not really working with a backlog — you are working with a traditional fixed-scope specification delivered in installments. There is nothing wrong with that approach, but the terminology should match the reality.
Letting developers set business priorities
Development teams will naturally gravitate towards technically interesting work or the path of least resistance. Left to order the backlog themselves, they may defer messy integration work, complex permission logic, or tedious data migration in favour of building new features. The product owner must ensure the ordering reflects business value and risk, not developer preference.
Letting business stakeholders dictate estimates
The reverse problem is equally damaging. If a business owner tells the team that a feature "should only take a day" based on intuition rather than technical understanding, the estimate becomes meaningless. The team must be free to estimate honestly. If the number is higher than expected, the conversation should be about scope reduction or alternative approaches — not pressure to adjust the figure.
The backlog as a dumping ground
Over time, backlogs accumulate stale items: ideas that seemed urgent months ago, features requested by a single user who has since left, or technical notes that no longer make sense. Without regular refinement — reviewing, updating, or removing items — the backlog becomes noisy and the team wastes time discussing work that will never happen. A practical discipline is to review the top 20–30 items before each planning cycle and ensure they are current, clear, and properly estimated.
Items that are too vague or too granular
An item like "improve the customer portal" tells the team nothing useful. An item like "change the hex colour of the submit button from #336699 to #334455 on the settings page" is probably too small to justify its own slot in planning. The right level of detail is a piece of work that delivers identifiable value and can be completed within a single development cycle, however you define that cycle.
Key questions to put to a supplier
- Who will act as product owner, and what decisions will they be authorised to make without referring back to us?
- How do we submit new items or request reprioritisation, and how quickly are those changes reflected?
- What format do backlog items use, and who is responsible for writing acceptance criteria?
- How often is the backlog refined, and will we see the full list or only the items scheduled for the current cycle?
- What happens to items that are deprioritised for a long period — are they archived, reviewed, or left in place indefinitely?
- How does the backlog relate to the contract: is it part of the agreed scope, or explicitly treated as a living document?
Understanding these points before work begins prevents the most common source of dispute in iterative projects: one side assuming the backlog is a flexible plan and the other treating it as a fixed commitment. Clarify the intent, document it in the contract, and revisit the arrangement if the nature of the project changes.