What is a backlog? A non-technical founder’s guide

A backlog is the prioritized list of everything still left to build in your product. Why it belongs to you, not your developer, and how to read and prioritize it without reading a line of code.

Camila opened the Trello board her agency had shared with her and counted. Two hundred and forty cards. Every one of them tagged with a red “important” label. She scrolled for a minute, closed the laptop, and realized two things at once: she had no idea what was shipping next month, and worse, nobody else did either. For six months she had treated that backlog as the technical team’s business. That backlog was, in fact, her product.

A backlog is the prioritized list of everything still left to build in a product: new features, bug fixes, improvements, and tweaks, arranged in the order they should be done. In software, it’s the single record of future work. Everyone building your product pulls their next task from it. If the backlog is confused, the product ships confused. That’s why it can’t be a detail you delegate and never look at again.

What a backlog actually is

Forget the Scrum-manual definition for a second. In practice, the backlog is where everything you promised to build and haven’t built yet lives. The social login screen you asked for in Tuesday’s meeting. The bug your first customer complained about. The payment integration blocking the launch. The idea you had in the shower and messaged your developer at 11 p.m. All of it becomes a backlog item, or should.

Two things usually go wrong for non-technical founders, and they’re opposites. First: you treat the backlog as the developer’s private to-do list, never open it, and find out too late that what was being built isn’t what you pictured. Second: you dump every idea that crosses your mind into it, the board swells to two hundred items, and nobody can say what matters anymore. Either way, the result is the same. You’ve lost control of the most expensive thing your company is producing.

The backlog isn’t a task list. It’s a queue of decisions.

Here’s the shift that separates founders who use the backlog from founders it uses. A backlog item isn’t a task. It’s a bet. Every card says, implicitly: “this is more worth building right now than everything below it.” When you put “push notifications” above “export report as PDF,” you didn’t organize two tasks. You decided one customer will wait longer for the report so another gets the push first. That’s a business decision, not a technical one.

That’s why the order matters more than the content. A backlog with the right items in the wrong order builds the wrong product, just slowly. And ordering is exactly the work a founder can do without knowing how to code, because the sorting criterion is value to the business, and you understand that better than any developer.

Who owns the backlog?

The question that comes up most is “who makes the product backlog.” The short, uncomfortable answer: you do. There’s a difference between who maintains the backlog and who owns it. The developer, the product manager, or the agency maintains the board: they write the cards with technical detail, estimate effort, break a big item into three smaller ones, close what’s shipped. That’s the “how.” But the owner of the backlog is whoever decides priority, the “what” and the “why.” At a ten-person company with no PM, that owner is the founder. It can’t be outsourced.

In the vocabulary of the Scrum Guide, this role is called the Product Owner, and the rule is clear: one person answers for the order of the backlog. You don’t need to adopt Scrum to respect the principle. You just need to accept that if five people can reorder the queue, nobody has decided anything. Choose who holds the pen. If you don’t have a PM you trust, the pen is yours.

What a healthy backlog looks like: the funnel shape

A good backlog isn’t a flat list of two hundred equally detailed items. It has a funnel shape.

At the top sit the five or ten items that will be built next. Those are expensive to prepare and worth the cost: well written, with clear acceptance criteria, ready for someone to pick up and start tomorrow. In the middle sit the items for the next month or two, sketched but not finalized. And down at the bottom sit the loose ideas, one line each, some that will never leave the page. That’s healthy. The bottom of the backlog is your graveyard of ideas, and ideas that are cheap to note down should be cheap to discard.

The anti-pattern is Camila’s board: two hundred and forty cards, all at the same level of detail, all “important.” A backlog like that isn’t an inventory of work. It’s a monument to indecision. The rule of thumb: the higher the item, the more detailed it needs to be; the lower, the vaguer it can stay. If you’re writing a meticulous spec for something that might not ship for eight months, you’re spending the company’s scarcest resource, the attention of whoever decides, in the wrong place.

How to prioritize without reading code: the next-month test

The objection every non-technical founder raises: “how do I prioritize if I don’t know what each thing costs to build?” You don’t have to. Prioritization is the split of two columns: value to the business and effort to build. The effort you ask for. The value you define.

Ask the developer for a rough effort estimate, in T-shirt sizes: S, M, or L. Nobody needs to nail down hours. You bring the other half, the value, and that you understand: how many customers it unlocks, how much revenue depends on it, what’s a promise made to an investor or an anchor customer. Cross the two. Start with what’s high value and low effort, let high effort and low value die at the bottom of the funnel.

When the list is still tied, apply the next-month test: if only one thing could ship next month, which is it? Answer, put it at the top, and repeat the question for what’s left. It’s a question so simple it sounds dumb, and it’s the one that exposes on the spot when “everything is a priority,” which is the same sentence as “nothing is a priority.” To turn that queue into a sequence you communicate to the team and your partners, the product roadmap is the next tool; and to choose between items of the same size, a formal method of feature prioritization helps.

The signs of a sick backlog

You don’t need to be technical to diagnose a bad backlog. The symptoms are visible to the naked eye:

• Everything is P1. If every label is red, you didn’t prioritize, you painted. A queue where everything is urgent isn’t a queue.
• Fossilized items. Cards from six months ago that nobody opens or deletes. A backlog is alive. What won’t get done should be deleted, not kept out of politeness.
• Bugs and features in the same pile. Fixing what broke and a new idea are decisions of different kinds and compete for different attention. Mixing them hides what’s debt from what’s ambition.
• You can’t find where a promise lives. You guaranteed a customer the export ships in March and you can’t point to the card. If the promise isn’t in the backlog, it doesn’t exist for whoever builds.
• The board grows, the product doesn’t. Two hundred items in, two shipped a month. The backlog became a warehouse, and a warehouse isn’t prioritization.

One of these signs is noise. Three or more and you don’t have a backlog, you have a wish list nobody is managing.

Backlog, roadmap, and scope: who’s who

Three words founders confuse, and that do different jobs. The backlog is the prioritized list of everything left, alive and reorderable at any moment. The roadmap is the reading of that list over time, the sequence you show partners and customers. And scope is the boundary: what’s in and, more importantly, what stays out of a project. The backlog feeds the roadmap; scope defines where the items entering the backlog come from. When those three things become one messy spreadsheet, that’s when the project starts to swell without anyone having decided.

The backlog is where your product becomes concrete, item by item, decision by decision. Treating it as the technical team’s business is handing over the wheel of the most expensive thing you’re building. It’s yours. The good news is that the hard part, deciding what matters, is exactly the part that doesn’t require code.

Frequently asked questions

What does backlog mean?

Backlog is an English word for "accumulation" or "dammed-up work." In software development and product management, it became the name for the prioritized list of everything still left to build or fix in a product. It's a term used without translation across the global tech industry.

Who makes the product backlog?

Whoever maintains the board day to day is usually the developer, the product manager, or the agency. But the owner of priority, whoever decides the order, is a single person: the Product Owner. In small startups with no PM, that role belongs to the founder. Maintaining is technical; prioritizing is a business decision, and it isn't outsourced.

What is a product backlog?

It's the most common kind of backlog in software: the official, living list of everything a product needs, from new features to fixes. It differs from the "sprint backlog," which is the small slice of the product backlog the team commits to in a short cycle of one or two weeks.

What is a company or customer backlog?

Outside software, "backlog" shows up in other contexts: in sales, it's the volume of closed orders not yet delivered; in finance, contracted revenue not yet recognized; in support, the queue of open customer tickets. The logic is the same everywhere: work already committed to that hasn't been fulfilled yet. This guide covers the product backlog.

How do I create a backlog from scratch?

Gather everything already promised or requested in one place: features, bugs, ideas. Separate fixes from new work. For each item, define the value to the business; ask the team for a rough effort estimate in S, M, or L. Order by value over effort and apply the next-month test to break ties. Detail only the items at the top well. Tools like Trello, Jira, or Linear all work; the discipline of prioritizing matters more than the tool.

Are a backlog and a roadmap the same thing?

No. The backlog is the prioritized, living list of what's left. The roadmap is the sequence of that list over time, the document that communicates the order and approximate timing of deliveries to partners and customers. The backlog feeds the roadmap; it doesn't replace it.