How I turn business priorities into a backlog

I start with the business outcome, cost of delay, risk and available capacity. Then I turn that into the smallest useful engineering work, with clear priorities and a way to check the result.

My principles

06 operating rules

Understand why the work matters

I want to know what changes for users or the business if we do this, and what happens if we wait. With platform work, that often means talking to the engineers who deal with the problem every day.

Make the useful version smaller

I look for the smallest change that would actually help. A proposed solution can arrive as if it were already a requirement. Architecture matters when it changes cost, risk or future options.

Plan for the people we actually have

When the team gets smaller, I need to cut the work too. I want engineers to understand what comes first and what we will leave alone, without having to guess between hundreds of urgent tickets.

Compare the cost of waiting

Two requests can both matter. I compare what a delay costs and what happens if we do nothing. I also check dependencies and the future maintenance cost each choice creates.

Write down the decision

I record what we chose, why, when we would stop and how we will check the result. An unreachable backlog hides those choices; I make the cuts explicit.

Accept that my proposal can lose

I can believe in a technical proposal and still understand why the business chooses something else. I have had to accept that myself. Then I look for a smaller way to address the problem within the decision that was made.

How I made those choices

03 cases

Starting without a backlog

Teladoc Health · 2022-2024

Situation: When I joined, there was no mobile platform team and no roadmap waiting for me. For much of that period there was no dedicated PM or team lead either. Product teams were solving similar problems separately, so I started there.
What I did: Worked with product teams and engineers to understand the systems and find problems that teams were paying to solve more than once.
Built the first roadmap with the engineers around shared CI/CD, SDK delivery, PR checks and quality controls. The order followed repeated cost rather than technical interest.
Took on shared release and deployment work across the white-label apps because no single product team would own that shared release risk.
Outcome: We built a platform function that other product teams could use. The priorities came from problems we had seen in their work, and we kept defining the roadmap with the engineers as the scope grew.

I did not measure how much duplicated work we removed. I would set up adoption and delivery measures earlier next time.

A proposal I believed in that did not get approved

ASKfm · 2016-2021

Situation: I proposed moving inactive-account media and text into cold storage. It could reduce storage costs, shrink active indexes and eventually free data-centre capacity. But it needed several months of engineering work, and the business was under cash pressure. The Board chose near-term product work.
What I did: I disagreed with the choice, but understood it and accepted the decision. The savings would take time, and the business needed a chance to improve revenue sooner.
Memory growth still needed an answer, so I came back with a smaller engine-migration proposal tied to the hardware limits we were already facing.
Outcome: The narrower migration was approved and completed because it addressed the immediate hardware constraint. The archival proposal stayed unimplemented, so its expected savings were never realised.

The migration delivered roughly half the RAM reduction I had forecast. I reported that miss; the details are in the section on reporting results.

Cutting work the team could not get to

Teladoc Health · 2024-2026

Situation: After mergers and layoffs, the platform group had fewer people and still had a broad scope. We had roughly 400 backlog items: defects, integrations and product requests. We were never going to get through all of them.
What I did: Triaged the backlog against what the remaining team could actually deliver.
Made the cuts explicit and kept a clear priority order for the work that remained.
Outcome: The backlog went down to about 200 items. When I left, people thanked me for defending the team and keeping the priorities clear. That feedback mattered to me: there had been a lot of uncertainty around us.

The counts are approximate recollection. The feedback was qualitative, not a formal performance measure.