Category: Methodology

Categories
Methodology Product Management Software

From Ideas to Outcomes: A Practical Framework for Product Value Management

Shipping features is easy. Creating value is hard. This article suggests a practical framework that hopefully will be useful for every product owner (PO).

While working on our products we face very similar questions:

  • What (which feature) should we develop next?
  • How do we justify our plans (the product roadmap)?
  • How do we balance (and compare) initiatives that generate revenue and that bring technical improvements?
  • How do we communicate to stakeholders that reducing technical debt is equally valuable as building new functionality?
  • And maybe the most important one: How do we know if we create value at all?

Teams, while working on their products, estimate business value, prioritize features, deliver functionalities, and than move to the next backlog item. The challenge is that these activities are rarely connected into a continuous value management process.

The proposed framework connects three essential activities performed by every PO. Together, these activities create a continuous feedback loop that supports informed product decisions rather than intuition alone.

  1. Value Estimation – understanding the expected value delivery for every initiative.
  2. Feature Prioritization – deciding which initiatives to be delivered first.
  3. Value Tracking – verifying whether the expected value has actually been realized.

Value Estimation

We need to think what does “value” actually mean before discussing value delivery. One can intuitively associate value with revenue. However, in reality products create value in multiple ways.

Some initiatives generate new business opportunities such as increased revenue, new customer acquisition, higher retention, or faster market expansion. Other initiatives improve the operation of organization by e.g. reducing infrastructure costs, lowering licensing costs, reducing development effort, lowering cost of poor quality (CoPQ). Both are valuable.

POs deciding between new functionality and annual cloud costs reduction will make exactly the same decision. They will need to choose where should the organization invest its limited development capacity. Thus, value estimation requires looking beyond financial metrics alone as successful products create value for both the business and its users.

Feature Prioritization

When the value has been estimated, the next challenge is deciding what should be done first. Fortunately there are several frameworks (e.g. Weighted Shortest Job First, WSJF) that can be very handful. Traditional WSJF evaluates such aspects as Business Value, Time Criticality, Risk Reduction or Opportunity Enablement, and Job Size. It has been successfully implemented in many organizations as it balances value against effort.

However, modern digital products face another important aspect. Business value is rarely created directly and it is realized through successful customer and user interactions. Basically it means that no adoption means no revenue, no task completion means no productivity improvement, no engagement means no retention. One needs to acknowledge that customer value precedes business value. This observation brings the need to extend the traditional prioritization approach to consider both business outcomes and user outcomes.

Value Tracking

Delivering a feature does not necessarily mean that value has been delivered. In many organizations one can see that the value is not measured any longer when the feature is put into production. In product management that should not be of common practice.

Instead, every business initiative should answer three questions:

  • Did we deliver it?
  • Did users actually adopt it?
  • Did the expected business outcomes materialize?

These questions correspond to three different kinds of evidence. This closes the feedback loop. The results of value tracking become inputs for the next round of value estimation. Based on that Product Owners can improve future prioritization using evidence rather than assumptions.

References

  1. K. Schwaber, J. Sutherland, “The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game,” November 2020.
  2. Scaled Agile Framework (SAFe) Knowledge Bas, “Weighted Shortest Job First,” , SAFe 6.0.
  3. K. Rodden, H. Hutchinson, X. Fu, “Measuring the User Experience on a Large Scale: User-Centered Metrics for Web Applications,” in Proceedings of the 28th Annual Meeting on Human-Computer Interaction (HCI), 10-15 April 2010, Atlanta, Georgia, USA.
Categories
Methodology Product Management

Strategic Product Roadmap: 5 Key Functions Every Product Owner Should Know

Most product roadmaps fail because they focus on what will be built, but ignore why it matters and how it will be delivered at scale. A strategic product roadmap fixes this by connecting business outcomes (why) with clear initiatives (what) and the architecture runway and technology direction (how) needed to enable them across the next 3–4 PIs. Instead of acting as a static plan, it becomes a practical decision framework that helps Product Owners align stakeholders, prioritize effectively, and translate strategy into coordinated, executable work that delivers measurable value.

Translate strategy into actionable initiatives

Translating strategy into actionable initiatives is where a roadmap becomes useful for delivery, not just direction. Strategy is often too abstract to execute, so Product Owners must turn it into clearly defined initiatives that teams can understand, plan, and break down into backlog-ready work. This step creates a shared bridge between intent and execution, ensuring that multiple teams move in the same direction instead of solving problems in isolation.

  • From abstract goals to concrete initiatives – Reframe broad objectives (e.g. “improve UX consistency”) into specific initiatives (e.g. “standardize components, unify navigation, define design tokens”).
  • From initiatives to executable work – Decompose initiatives into epics and features that can be directly reflected in team backlogs and planned across PIs.
  • From isolated tasks to coordinated direction – Ensure initiatives are cross-cutting and aligned across products, so teams contribute to shared outcomes rather than fragmented improvements.

Focus: Convert each strategic (direction) goal into roadmap initiatives and break them down into epics (or features) that can be added to the backlog.

Align delivery with business outcomes

Aligning delivery with business outcomes ensures that teams focus on creating measurable value, not just shipping features. A strategic roadmap makes this explicit by linking every initiative to a clear purpose, expected impact, and success metric. This shifts the conversation from “what are we building?” to “what are we achieving?”, helping Product Owners prioritize effectively and avoid low-impact work.

  • From outputs to outcomes – Define the expected result of each initiative (e.g. increased adoption, reduced effort, faster delivery), not just the feature being delivered.
  • Tie work to measurable success – Connect initiatives to concrete KPIs or signals, so progress can be evaluated beyond completion.
  • Prioritize based on impact – Use outcomes to decide what to do first, focusing on initiatives that deliver the highest business value rather than the loudest requests.

Focus: Define one measurable outcome for every roadmap initiative before bringing them to a PI.

Prioritize and sequence work across PIs

Prioritizing and sequencing work across PIs ensures that delivery is focused, realistic, and unblocked, rather than reactive and overloaded. A strategic roadmap helps Product Owners decide not only what is important, but what should happen first, what can wait, and how work should flow over time, balancing business priorities with dependencies and technical readiness. This creates a clear path from strategy to execution while keeping flexibility in later PIs.

  • Prioritize based on value and constraints – Balance business impact, dependencies, and technical feasibility to decide what truly deserves focus in each PI.
  • Sequence for flow, not urgency – Plan work so that foundational elements (e.g. research, architecture runway) come before dependent features, avoiding rework and delays.
  • Keep future PIs adaptable – Define near-term work clearly, but leave later PIs at a higher level to allow learning and adjustment without overcommitting.

Focus: Order roadmap initiatives based on value, dependencies, and technical readiness – and explicitly decide what will not be done now.

Connect strategy to execution and communication

Connecting strategy to execution and communication ensures that everyone – from leadership to delivery teams – is aligned on where the product is going, why it matters, and how work translates into results. A strategic roadmap acts as a shared reference point that links high-level goals with day-to-day activities, while also providing a clear narrative for stakeholders. This reduces misalignment, improves decision-making, and keeps teams focused on delivering meaningful outcomes.

  • Create a shared understanding – Present initiatives in a way that is clear for both business and technical stakeholders, so everyone aligns on priorities and direction.
  • Bridge planning and delivery – Ensure roadmap initiatives are directly connected to epics and backlog items, making strategy actionable for teams.
  • Communicate intent, not just status – Use the roadmap to explain why work is prioritized and what value it will bring, helping manage expectations and build trust.

Focus: Ensure every roadmap initiative is linked to backlog items and can be clearly explained to both stakeholders and teams in one sentence.

Sync with the architecture runway

Synchronizing with the architecture runway ensures that product plans are technically feasible, scalable, and not blocked during delivery, even though Product Owners do not own the architecture itself. While the System Architect defines and evolves the runway, Product Owners must actively connect roadmap initiatives with the required technical capabilities, so that features are delivered on top of a ready foundation rather than being delayed or compromised.

  • Ensure visibility of dependencies – Identify which initiatives depend on specific architectural capabilities (e.g. APIs, design systems, data models) and make these dependencies explicit in the roadmap.
  • Align timing with technical readiness – Coordinate with the System Architect so that the necessary runway elements are planned and delivered before or alongside dependent features.
  • Facilitate continuous collaboration – Maintain regular alignment with architecture stakeholders to validate feasibility, adjust sequencing, and avoid disconnects between product ambition and technical reality.

Focus: For each roadmap initiative, confirm with the architect what technical enablers are required and when they will be ready.

In short

A strategic product roadmap is not just a plan of what will be built, but a coordinated framework that aligns business outcomes, product initiatives, and technical readiness over time. For Product Owners, its role is to ensure that work is driven by value, translated into actionable initiatives, properly prioritized across PIs, clearly connected to execution, and synchronized with the architecture runway owned by System Architects. When used effectively, the roadmap becomes a shared decision-making and communication tool that links strategy to delivery and ensures that what teams build is both meaningful and feasible.

Dictionary

(Strategic) Goal: A desired business outcome the organization wants to achieve.
(Roadmap) Initiative: A high-level investment area that defines how a goal will be pursued.
Epic: A large, value-driven piece of work that delivers a specific capability and can be broken into smaller items.
Feature: A specific functionality or capability that provides value to users or systems.
Story: A small, implementable unit of work describing a user need or system behavior.

LevelFocusBelongs toGranularity
GoalWhy (outcome)StrategyVery high (Long-term)
InitiativeWhat / Why (direction)RoadmapHigh (Multiple PIs)
EpicWhat (deliverable)Backlog (bridge)Medium (Multiple PIs)
FeatureWhat (detailed)BacklogLower (One PI or less)
StoryHow (execution)BacklogVery low (One iteration)

References

[1] C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors, “Product Roadmaps Relaunched,” O'Reilly Media, October 2017.
[2] Scaled Agile Framework (SAFe), “Roadmap,” URL: https://framework.scaledagile.com/roadmap/, Last Update: 25 February 2025.
[3] Marty Cagan, “Inspired: How to Create Tech Products Customers Love,” Wiley, 2017.

Categories
Methodology Stability Wind Farms

CIGRE C4.49: Multi-frequency stability of converter-based modern power systems

Background

Nowadays, it is seen that the rapid transformation of power systems from conventional with high natural damping, short-circuit current and natural inertia to power-electronic-based with limited damping, fault infeed and inertia may trigger unstable operation, if not investigated carefully. Moreover, the electrical infrastructure is becoming more complex due to the introduction of long high voltage alternating current (HVAC) cables, high voltage direct current (HVDC) connections, widespread penetration of renewable energy sources, e.g. photovoltaic (PV) plants, wind power plants (PPs), and offshore electrical network development. This power system transformation creates challenges such as operational coordination of grid-connected converters and small-signal stability assurance both in the sub-synchronous and harmonic (super-synchronous) frequency regions.

Motivation

The increased use of power electronic converters in modern electrical systems creates challenges w.r.t. power system stability assurance but also simultaneously provides wide range of power system performance and stability enhancement solutions. Better understanding about the application of various instability mitigation methods, including impact on power system performance, use depending on instability root cause, implementation methodology, is needed. Power system operators, operators of renewable PPs, transmission solution developers, renewable generation developers, academic units and original equipment manufacturers expect coordinated effort to understand when and how to apply specific mitigation measures.

Therefore, the overview, status and outline of instability mitigation methods in converter-based modern power systems is needed. Thus, the CIGRE C4.49 working group entitled “Multi-frequency stability of
converter-based modern power systems” was established. The instability phenomena, instability root cause and suggests optimal mitigation measures are investigated within the working group. Moreover, guidelines regarding the general approach how to choose optimal instability mitigation method will be suggested in the technical brochure.

Scope

  1. Review of existing literature regarding subject related stability issues including state-of-the-art converter stability aspects.
  2. Definition of stability phenomenon to be covered within the technical brochure.
    • Stability effects above the fundamental frequency, i.e. harmonic stability.
    • Small-signal stability below the fundamental frequency, i.e. sub-synchronous stability.
    • Clarification of definitions to avoid misinterpretation with steady-state harmonics and classical harmonic propagation analysis.
    • Symptoms and root causes of sub-synchronous and harmonic stability phenomenon.
    • Examples of sub-synchronous and harmonic stability phenomena observed and their impact on wider power systems.
  3. The impact of grid-connected converter controllers on sub-synchronous and harmonic stability phenomenon.
    • Classification of typical controllers used in modern converters.
    • Evaluation of various control loops and techniques and their impact on stability, e.g. voltage control, current control, phase-locked loop.
    • Frequency range of interest and controller interactions/couplings.
  4. Overview of linear modelling and analysis methods to perform small-signal stability studies, e.g.
    • Classical control theory approach of linear time-invariant systems, i.e. compensator and plant interactions, and possible general extension to linear time varying systems including e.g. linear time-varying periodic systems.
    • Impedance-based stability criterion.
    • Advantages and disadvantages of single-input single-output and multiple-input multiple-output representation.
    • Relevant stability evaluation methods, e.g. eigenvalue analysis, Nyquist criterion.
  5. Other analysis techniques.
    • Time-domain numerical simulations of linear and non-linear systems.
    • Frequency and sequence coupling investigation.
    • Stability of non-linear dissipative dynamic systems including e.g. limit cycle and bifurcation theory investigation.
  6. Description of mitigation methods to overcome sub-synchronous and harmonic stability issues, e. g.
    • Clear evaluation criteria and minimal requirements regarding the stability indices, e. g. stability margins, damping.
    • Recommendations to address plant resonance profile at early stage during the grid-connected converter controller design.
    • Converter coordination guidelines in modern power systems to avoid potential instability, e. g. passivity requirements.
    • Mitigation measures incorporated in the grid-connected converter control (e.g. active damping) or within the power system electrical infrastructure (e.g. passive damping), also at later stage of project development or during operation.
  7. Guidelines on general approach to such studies and the availability as well as choice of tools. Identification of limitations with the available analysis tools and suggestion of possible areas for development.

References

Ł. Kocewiak, R. Blasco‐Giménez, C. Buchhagen, J. B. Kwon, M. Larsson, A. Schwanka Trevisan, Y. Sun, X. Wang, “Instability Mitigation Methods in Modern Converter-based Power Systems,” in Proc. The 20th International Workshop on Large-Scale Integration of Wind Power into Power Systems as well as Transmission Networks for Offshore Wind Farms, Energynautics GmbH, 29-30 September 2021.

Ł. Kocewiak, R. Blasco‐Giménez, C. Buchhagen, J. B. Kwon, Y. Sun, A. Schwanka Trevisan, M. Larsson, X. Wang, “Overview, Status and Outline of Stability Analysis in Converter‐based Power Systems,” in Proc. The 19th International Workshop on Large-Scale Integration of Wind Power into Power Systems as well as Transmission Networks for Offshore Wind Farms, Energynautics GmbH, 11-12 November 2020.

Categories
Methodology

Rationalistic Tradition - Reliance on reason in scientific culture

There is a close correlation between the western culture approach of organized science and  rationalistic tradition. The tradition of rationalism and logical empiricism can be tracked back at least to Plato. This tradition has been the inspiration of western science and technology. Especially in hard sciences (i.e. natural, physical, and computing sciences), that explain the operation of deterministic mechanisms whose principles can be described by means of formal systems, this tradition has introduces a great influence.

Based on rationalistic tradition the basic concept of research is focused on deriving formulations of systematic rules that can be used to draw logical conclusions. In western philosophy this approach can be seen as a drive to come up with more systematic and precise formulations of what constitute valid reasoning. Therefore, thinking and reasoning are the most natural ways of research and development [1].

In nowadays science, obviously, there must be a certain degree of adherence to the scientific methods having their roots in the rationalistic tradition. The scientific method can be described as involving the following operations [2]:

  1. observation of a phenomenon that, henceforth, is taken as a problem to be explained,
  2. proposition of an exemplary hypothesis in the form of a deterministic system that can generate a phenomenon isomorphic with the one observed,
  3. proposition of a computed state or process in the system specified by the hypothesis as a predicted phenomenon to be observed,
  4. observation of the predicted phenomenon.

According to the presented approach, the first step is to characterize the phenomenon in terms of identifiable objects with well-defined properties based on observations. The next step is to find general rules which apply to the phenomenon in terms of those objects and their properties. And later apply specified rules to the phenomenon of concern, drawing conclusions and generic characteristic of the phenomenon.

It is worth emphasizing that rationalistic tradition not only constitutes a mainstream of both either pure or applied science but also underlies as a paradigm of what it means to think. Therefore, for people of science and technology this approach seems to be appropriate and self-evident way of serious thinking.

[1] T. Winograd and F. Flores, Understanding computers and cognition: a new foundation for design. Addison-Wesley Professional, 1987.
[2] H. R. Maturana, Biology of Language: The Epistemology of Reality. New York: Academic Press, 1978.