What is new in .NET 11, and should you move from .NET 10?
A fair tour of .NET 11 and C# 15 as released on 10 November 2026, the breaking changes to read first, and a decision guide for production teams on .NET 10.
· 7 min readThe decision meeting is on Thursday, and everything on the list is important to someone. Each item arrived with a good reason and a colleague attached. There is one team, one budget, and room for perhaps a third of it this year.
Deciding what comes first is where roadmaps succeed or stall. It is also where people feel most exposed, because every "not yet" lands on a colleague who asked in good faith. This article offers a practical way to decide, and to explain the decision so that it holds.
It follows our pieces on how to build a product roadmap and how often to review it. If you are not sure how a roadmap differs from a project plan or a backlog, start with that comparison.
Prioritising is a business decision
The order of work is not a technical question that the developers should settle on your behalf. It is a decision about where the organisation puts its money and attention, and the people who carry the responsibility should make it. Engineers can say how big something is, what depends on what, and what could go wrong. Whether it matters more than the alternative is yours to decide.
Treating it that way has a practical benefit: a decision made openly, with reasons, is much easier to explain than one that appears to have emerged from the technical team.
A handful of plain criteria
You do not need many. Five questions cover most of what matters:
| Criterion | The question to ask |
|---|---|
| Value to the business | What changes if we do this: revenue, time saved, customers kept, errors avoided? |
| Risk reduced | What could go wrong if we do not, and how likely and how serious is it? |
| Effort | Roughly how much work is it, in small, medium or large? |
| Dependencies | Does something else have to happen first, or does this make other work possible? |
| Time-sensitivity | Is there a date after which this loses value or becomes harder, such as a customer deadline, a regulation or the end of support for a framework? |
Time-sensitivity deserves particular attention. A date set by someone else, such as the end of support for a framework you depend on, is not a preference. It will arrive whether or not the work has been done.
Do not treat risk work as optional until it is urgent
A common trap is to rank risk work below features, because features have an enthusiastic sponsor and risk work does not. Upgrading a framework, adding automated tests, fixing the backup, or moving a system off an unsupported server all invisibly protect something. Nobody asks for them, and the day they are needed, it is too late to start.
A useful discipline is to reserve a fixed share of the capacity for this kind of work, agreed in advance, rather than negotiating for it each time against a more exciting request. Decide the share together, record it, and revisit it when the roadmap is reviewed.
A simple way to score and discuss
A score is a good way to start a conversation and a poor way to end one. Three well-known approaches, each with strengths:
- MoSCoW sorts items into Must, Should, Could and Won't (this time). It is quick and easy for a group to use, but nearly everything gets called a Must unless someone enforces the limit.
- A value and effort grid plots items on two axes, so you can see quick wins (high value, low effort) and expensive items of doubtful value.
- Weighted scoring gives each item a number against your own criteria, weighted by how much each criterion matters to you. RICE, a formula developed at Intercom, is a fixed variant: reach times impact times confidence, divided by effort. Both look objective, but the numbers are still judgements, and a confident guess can look like a fact.
A sensible approach for most organisations is to score each item on the five criteria above as high, medium or low, put the results on one page, and talk it through. Where the scores disagree with your instinct, look closer: either the scoring missed something, or your instinct is worth questioning. Either way, a score informs a decision. It does not make it.
From a feature list to outcomes
A request usually arrives as a feature: "add an export to Excel", "a dashboard for the regional managers". Before ranking it, ask what problem it solves and how you would know it was solved.
"Regional managers spend half a day each month assembling figures by hand" is a problem with a measure. It might be solved by the dashboard, by a simpler report, or by fixing the source data. Written as an outcome, the item can be compared with others on its merits, and the team is free to find the best solution. Written as a feature, it is a commitment to one particular answer.
For each item on the roadmap, try to write one sentence on the problem and one on the measure of success. Where you cannot, you have found something that needs more thought before it is scheduled.
One roadmap, three audiences
We looked at who reads a roadmap in why have a product roadmap. For prioritisation, the point is narrower: the board needs to see the reasons for the order and what is deliberately not being done, customers need direction without dates you may not keep, and engineers need the detail, which lives in the backlog. Keep these as views of one set of decisions, rather than three separate documents, and they cannot contradict each other.
Saying no, with reasons
A flat refusal starts an argument. A refusal with reasons, shown against criteria everyone has seen, usually starts a better conversation.
- Say what you scored it on. "This would help, but three other items reduce more risk or save more time this quarter."
- Say what would change the answer. A new deadline, more evidence of value, or a cheaper way to do it.
- Keep a short parking list of "not now" items, each with a one-line reason. It shows that nothing has been lost, and it gives you something to revisit when the roadmap is reviewed.
- Record the decision and the reasons in the same place as the roadmap, so that the question is not reopened from scratch in three months.
When a senior opinion overrides the order
It will happen: the chair or the managing director asks for something to go first, and it was not at the top. That is their prerogative. The discipline is to record it openly as an exception, with the reason and what was displaced. The roadmap stays honest, the trade-off is visible, and the next review can ask whether it was worth it, without anyone being blamed.
A sensible first step
Take your current list and do three things:
- Write each item as a problem and a measure, not a feature.
- Score each against the five criteria as high, medium or low, and put it on one page.
- Start a "not now" list with a one-line reason for each.
Then share the page with the people whose requests are on it, before the decision meeting rather than after.
If you would like help running that process, our product roadmap service covers roadmap planning, and our software care page explains how we look after the systems the risk items relate to.
