# How I turn business priorities into a backlog Source: https://manaienko.com/how-i-work/business-priorities-into-a-backlog/ Author: Artem Manaienko The order is a judgment, not a scoring formula. Business outcome, cost of delay, the smallest useful change, then the capacity that actually exists. Architecture enters when it changes one of those. ## My principles 08 operating rules 1. [01 A request with no stated outcome waits](#practice-business-priorities-into-a-backlog-principle-1) 2. [02 Cost of delay separates what importance cannot](#practice-business-priorities-into-a-backlog-principle-2) 3. [03 A proposal competes with everything the same months could buy](#practice-business-priorities-into-a-backlog-principle-3) 4. [04 Order the smallest version that still delivers the outcome](#practice-business-priorities-into-a-backlog-principle-4) 5. [05 Capacity is a fact, not a negotiation](#practice-business-priorities-into-a-backlog-principle-5) 6. [06 Architecture enters when it changes cost, risk or future options](#practice-business-priorities-into-a-backlog-principle-6) 7. [07 Write down the decision, the stop condition and the measurement](#practice-business-priorities-into-a-backlog-principle-7) 8. [08 A backlog you cannot reach is avoidance](#practice-business-priorities-into-a-backlog-principle-8) ### A request with no stated outcome waits What changes for users, revenue or risk if this ships. If nobody can answer that, the request is not ready to be ordered against anything else. Often the question alone is what removes it. ### Cost of delay separates what importance cannot Everything on a backlog is important to whoever put it there, so importance orders nothing. What it costs to do this later, and what breaks if we do nothing at all, does. ### A proposal competes with everything the same months could buy Positive technical ROI is not automatically the best allocation. A business under cash pressure is choosing survival, so months of engineering on infrastructure economics lose to work that might move the revenue line first, and a board reasoning that way is doing its job. Tie the ask to the constraint the business is already paying for, and when the answer is still no, come back narrower instead of reopening it. ### Order the smallest version that still delivers the outcome A request usually arrives as a proposed solution wearing the clothes of a requirement. Cutting it back to the narrowest useful change is where most of the capacity comes from, and it is free. ### Capacity is a fact, not a negotiation The order runs against the people who are actually available, not the ones on the org chart. Planning against the headcount you are supposed to have is how a backlog quietly stops being real. ### Architecture enters when it changes cost, risk or future options Then I want the options and it belongs in the decision. When it changes none of the three it is a preference, and a preference does not reorder a backlog. ### Write down the decision, the stop condition and the measurement What we chose, what would make us stop, and how we will know it worked. A decision nobody wrote down gets relitigated every time priorities move, and the second argument is always worse than the first. ### A backlog you cannot reach is avoidance Carrying work the team will never get to looks like commitment. In practice it hides the real order from everyone, the team included, and it postpones a decision that only gets more expensive. ## What that looked like 03 cases ### A backlog that did not exist yet Teladoc Health · 2022-2024 **Situation:** There was no mobile platform team when I joined, so there was no backlog to inherit and no roadmap to execute. For most of that period there was no dedicated product manager or team lead either. The only signal was that product teams kept solving the same problems again in their own stacks, and that was visible only from inside those teams. **What I did:** - Refused to write the roadmap from outside the work. Went to the product teams and to the engineers to find which repeated work was being paid for more than once. - Chose the first products of the function by repeated cost rather than by how interesting they were: shared CI/CD, SDK delivery, PR checks, quality gates and code standards. - Took on release governance and deployment architecture across the white-label estate, because a shared release risk is the kind of thing no single product team will ever own. - Kept the roadmap defined with the engineers as it grew, rather than handing one down once the function had a name. **Outcome:** A function that did not exist became the shared delivery path for the product teams, and it kept its scope through four reorganisations. The order held up because it was built out of work the teams could name, not out of a plan I had written for them. I never measured how much duplicated work this removed. No adoption telemetry existed in that environment, and building it is the first thing I would fix. How the function itself was built and run is on the platform practice. ### Positive economics that still lost ASKfm · 2016-2021 **Situation:** I proposed moving inactive-account media and text into cold archival storage. Lower storage cost, a smaller active index, less RAM, eventually less physical data-centre capacity. The long-run economics were good. The Board rejected it. **What I did:** - Accepted the rejection instead of relitigating it. The work needed several months, the business was under cash pressure, and near-term product investment had higher survival value. - Reframed the ask against the constraint that was actually binding, memory on owned hardware, rather than against the better long-run return. - Came back with a bounded engine migration that could be funded on its own terms, and it was approved. **Outcome:** The narrow proposal got funded precisely because it was tied to the immediate constraint. A proposal never competes with doing nothing. It competes with everything else the business could buy with the same months. The migration came in at roughly half the RAM reduction I had forecast, and I reported the miss. That part is on the practice about reporting results. ### Roughly 400 items the team was never going to reach Teladoc Health · 2024-2026 **Situation:** After mergers and layoffs the platform group kept its broad scope while stable capacity dropped. The backlog held roughly 400 items: defects, integrations, product priorities. Most of it the remaining team was never going to reach. Carrying it looked like commitment. In practice it was avoidance. **What I did:** - Triaged against the capacity that existed rather than the capacity the scope implied. - Made the reduction a stated decision about capacity, not a quiet cleanup. - Kept a ranked order underneath it, so it stayed legible what the team would and would not work on. **Outcome:** Backlog roughly halved, to about 200 items. When I left, the feedback from the team was specifically about this. Priorities were clear and it was understandable what they were working on, in a period when very little else in the organisation was. Backlog counts are approximate recollection, and the departure feedback is direct and qualitative rather than a performance record. How the decision was delivered to the team is on the practice about decisions people will not like.