New Backlog Framework: The "Upflow" way of working

Backlogs are supposed to organize chaos. In practice? They often become chaotic. That’s exactly what I faced at Elaway—and why I built the Upflow framework.

Sep 25, 2025

Over the years, I have worked in several different backlog tools and frameworks. None of them has completely given me:

A single, intuitive space where product managers, developers, and stakeholders can all see the full, same picture: which problems, ideas, and requests have been received, which are being explored, which are ready for prioritization, which are in progress, and which have been delivered.
A structured and simple way to assign value to each problem, idea, and request by weighing its estimated impact against its expected cost.

A couple of months ago—right after I wrote about how we approached this before—I began experimenting with a custom Notion setup. In this setup, problems, ideas, and requests enter at the bottom of the framework and move upward (“upflow”) until, if considered valuable enough for Elaway, they are ultimately delivered.

The framework is built on three elements:

Roadmap stages
Value assessment
Monthly C-level planning and alignment

I call this framework Upflow.

#1 The Upflow stages in detail

Every problem, idea, and request we receive or identify ourselves goes thorugh a set of stages.

Stage 1: Received

This stage stores all problems, ideas, and requests we receive. C-level management is responsible for organizing these top-down in their domains (finance and legal, commercial, operational, and platform), starting with the most important problem and so on.

Stage 2: In discovery

The discovery stage consists of three stages.

Problem discovery:
1. Product management is responsible for working with stakeholders to understand the problems, ideas, and requests received and translating that into the content of the “problem description” that engineering uses to develop potential solutions.
Solution discovery:
1. Engineering management is then responsible for engineering, delivering alternative solutions, and estimating their cost (developer days) based on the “problem description” in point 2. a. UX/UI works closely together with engineering in the cases where user-facing products or features are involved.
Definition of done:
1. When the two above are done, product management, engineering management, and stakeholders need to agree on the “definition of done,” set the impact level on solving these problems, ideas, and requests, and sign off on it.
2. When a,b, and c are done, we know the value (Impact ÷ Cost=Value) of the problems, ideas, and requests, and it is moved into stage 3.

Stage 3: Ready for prioritization

In the monthly planning meetings described further down, management will discuss and prioritize items that are “ready for prioritization” in addition to problems already “in delivery.” Management can easily assess each problem, idea, or request’s estimated value.

To ensure we stay agile and can make minor/medium fixes and additions, smaller/medium-sized items can be added directly to this stage and solved directly without needing to go through planning meetings.

Stage 4: In progress

When problems, ideas, and requests are prioritized, we move them into delivery, and developers start building. Engineering management is now responsible for reporting on progress and solving the problem.

Stage 5: Done this month

When a problem, idea, and request is “solved” (meaning developed and tested), then engineering moves it into delivered, and we celebrate and post to our internal Slack channel #all-deliveries

#2. The cost/impact model we use to value problems, ideas, or requests against each other

Every roadmap item will have two key inputs that together help us understand the value of each item at any point in time (Impact ÷ Cost=Value). This helps us prioritize the most valuable problems Elaway faces:

Setting the cost score: The estimated developer days required to deliver (or “remaining days” if already in progress to ensure “dynamic value”). The developer who sets the cost score can also add a confidence level to the cost score.
Setting the impact Score: A rating from 1–10 that measures the potential effect of the work. These impact levels range from tiny UI tweaks (1) to game-changing shifts (10).
- Impact scale details categories
```
1 – Incremental Improvement
```
```
Tiny optimizations that polish the product without changing core behavior.
```
  - Examples: Text alignment fixes, button color adjustments, typo corrections, and minor UI spacing.
  - Impact: Barely noticeable to most users, but removes small annoyances.
  - Effort: Usually very low, but cumulative value over time.
```
2 – Stability Patch
```
```
Fixes that improve product reliability and trustworthiness.
```
  - Examples: Fixing error messages, resolving crashes, patching broken links, and handling edge cases.
  - Impact: Reduces friction and user frustration, prevents small issues from snowballing.
  - Effort: Can vary, but benefits are immediate and clear.
```
3 – Usability Boost
```
```
Improvements that make the product easier to use and reduce support overhead.
```
  - Examples: Simplified flows, clearer navigation, contextual help, and reducing steps in signup.
  - Impact: Improves adoption and retention, lowers support tickets.
  - Effort: Medium; requires thoughtful design/UX iteration.
```
4 – Operational Efficiency
```
```
Tools or workflows that make Elaway teams more effective.
```
  - Examples: Internal dashboards, CRM integrations, better reporting, and easier customer onboarding processes.
  - Impact: Saves employee time, improves accuracy, and reduces manual work.
  - Effort: Medium–high; requires alignment across teams.
```
5 – Feature Addition
```
```
New visible capabilities that expand what users can do today.
```
  - Examples: Adding a booking calendar, payment method options, richer customer profiles.
  - Impact: Differentiates Elaway’s offering, strengthens customer value proposition.
  - Effort: Medium–high; touches product, design, support.
```
6 – Process Automation
```
```
Scaling by removing repetitive, manual work through automation.
```
  - Examples: Automated invoicing, background syncing of systems, proactive customer notifications.
  - Impact: Unlocks growth by reducing cost-to-serve and human dependency.
  - Effort: Often high upfront, but strong long-term payoff.
```
7 – System Upgrade
```
```
Significant backend or infrastructure work that unlocks speed, security, and scalability.
```
  - Examples: Migrating to a new cloud service, refactoring core services, improving uptime and resilience.
  - Impact: Invisible to users initially, but enables faster feature delivery and reliability.
  - Effort: High; often requires deep technical coordination.
```
8 – Platform Enabler
```
```
Foundational work that makes entirely new product directions possible.
```
  - Examples: Introducing an API layer, a unified customer identity system, and a modular product architecture.
  - Impact: Unlocks multiple future features/lines of business, but value is indirect until leveraged.
  - Effort: Very high, but critical for long-term strategic flexibility.
```
9 – Transformative Shift
```
```
Reinventing how Elaway delivers value, changing customer perception of the product/company.
```
  - Examples: Moving from a charging hardware provider to a full-service EV ecosystem operator.
  - Impact: Changes the market positioning, drives step-change in growth.
  - Effort: Extremely high; requires org-wide alignment and execution.
```
10 – Game Changer
```
```
A disruptive leap that alters Elaway’s trajectory and potentially the industry landscape.
```
  - Examples: Becoming the de facto marketplace for EV charging across Europe; redefining home energy solutions.
  - Impact: Entirely new business model or category creation. Sets Elaway apart as a leader.
  - Effort: Massive; high risk, high reward.

Why does this impact scale work

Instead of debating revenue forecasts or cost savings that are often uncertain, we use a shared language of impact. This removes friction and keeps discussions grounded in long-term value rather than speculative spreadsheets. This scoring system makes trade-offs transparent: we can see whether an item with moderate cost but very high impact is worth prioritizing over something cheaper but less transformative.

This gives us automatic dynamic values

Once we start working on something, we update the “estimated remaining developer” days every other day. This means the value of finishing the item is always based on the latest reality; if it turns out to take longer, its relative value may go down; if it’s quicker than expected, its value may go up.

This dynamic view ensures we prioritize with the most accurate cost-to-impact picture, not outdated cost estimates and other assumptions.

What About Strategic Bets, then?

It’s true that in this model, long-term high-impact items often look less attractive when compared purely on value-per-day. To handle this, we break big strategic bets into smaller, deliverable chunks. We also give impacts 8 and above a 1.5x boost. This approach not only makes the work easier to prioritize alongside shorter items but also brings tangible progress faster. The company benefits from earlier impact, and the team benefits from clear milestones that keep morale high.

#3 The planning setup with our C-level stakeholders

During a month, we do two planning activities:

The monthly planning meeting:
1. At the start of each month, product management, engineering management, and CPTO meet the C-level management group to:
  1. Celebrate and review what has been delivered in the previous month
  2. Review items currently “in delivery”
    - Based on dynmaic value scores and other factord (regulatory, legal et cetera) decide whether to continue, pause, or stop based on progress, learnings, or shifting priorities.
    - This helps us avoid sunk-cost thinking and ensures we’re not afraid to pivot.
  3. Review new candidates in “ready for prioritization”
    - And decide whether any of them should be moved into delivery for the coming month.
Mid month check in
1. In the middle of each month, the Head of Product meets with the CCO, COO, and CFO to:
  1. Identify any missing items that should be in the “received” stage.
  2. They also discuss whether any items need to be fast-tracked to “ready for prioritization” so they can be addressed in the monthly planning meeting.

As Notion is not giving me absolutely every feature I want, I am currently working on building Upflow as a SAAS service. If you want to stay updated on that subscribe to this newsletter.

Wesentlich

Discussion about this post