Tag: product-management

• From Behaviour to Value

  Ever since my blog post on Torbjørn Marøs amazing Christmas blog series in 2012 I have kept drilling down into the same frustrations within the software development industry. And my 2 cents to this is that the remedy is not technology, it’s product management. Here comes a 2025 update to that old blog post.

  When we talk about Value-Driven Practises in Contango it is not just about building valuable software, it’s about making smart decisions under uncertainty. At its core, it is a systematic approach to risk management: identifying, reducing, and ultimately controlling the risks that affect whether a product will deliver meaningful value at an acceptable cost.

  Traditional software processes often assume too much, too early. They jump into solution mode before truly understanding the problem, its impact, and what success even looks like. Value-Driven Practises turns that on its head. It asks:

  • Do we understand the problem we’re solving?
  • Do we understand who benefits, and how?
  • Can we measure whether the solution actually delivers that benefit?
  • Do we know the likely cost of building it—and of maintaining it?
  • Have we considered unintended side effects or system-wide consequences?
    

  Until these questions are answered, and the associated risks reduced, any plan to “deliver value” is speculative at best.

  Risk Before Specification

  In this model, specification for development is not the start of the process—it’s the result of it. The initial goal is not to define the solution, but to attack the unknowns that cloud our understanding of value and cost. Every early activity is about creating learning loops that reduce risk fast and at low cost.

  That’s why we often begin with UX-first thinking, not because UX is a design preference, but because user experience is the first-place value becomes measurable. Validating UX is the clearest and fastest way to test whether we understand the user problem and whether our proposed solution could actually deliver value. It’s a way of surfacing assumptions, flushing out hidden risks, and making better investment decisions before any heavy development work begins.

  Clear Thinking: Anchoring Risk Management in Intention

  Effective risk management also depends on clear articulation of intent. We call this Clear Thinking: the disciplined separation of intention from solution. Intention is the problem we aim to solve, why it matters, and how we will recognize success. Without this, teams build based on assumptions or interpretations, often misaligned with organizational goals.

  Clear Thinking runs through the entire organization. From leadership to product to delivery, everyone must be able to express not just what they want built, but why—and how they will know if it’s working. This is just as crucial when working with AI tools as it is with human teams: if you cannot express intention clearly, you cannot delegate work effectively.

  Throughput-Driven Prioritization

  Once value and risk are framed, prioritization becomes throughput driven. Using principles from Throughput Economics and Theory of Constraints, we focus on reducing the most critical risks first—those that most affect the cost/value ratio. The goal is to continuously increase the confidence of our decisions through fast, lightweight iterations.

  This might involve:

  • Exploring user experience flows to reduce uncertainty on value delivery.
  • Decomposing services and APIs to reduce architectural risk.
  • Running cost or time breakdowns to surface hidden complexities.
  • Testing assumptions about side effects or operational impact.
    

  Each step is designed to create a clearer picture of whether an initiative is worth executing, or whether it should be abandoned early, saving resources for better bets.

  The Outcome

  The result of Value-Driven Practises is not just higher product quality. It’s:

  • Lower rework due to better-aligned solutions.
  • Faster time to confidence on what’s worth building.
  • Scalable delivery built on real, validated understanding.
  • Clearer communication and decision-making across roles and teams.

  This is not a delivery methodology. It is a thinking framework for reducing risk at every level—from strategic planning to the smallest design decision. And it’s the foundation for truly value-driven work.

  March 25, 2025

  Clear Thinking, leadership, product-management, project-management, Value-Driven Practises

  ---

• Separating product knowledge from product

  When building software there are particularly 3 things that I see people mix up, and this has been the cause of most misalignments that I have experienced.

  • Problem understanding & user behaviour
  • Solution & user experience
  • Change-requirements

  I believe that the transition into an Agile mindset has caused a mental shift where we focus so much on continuously delivering that everything is interpreted through the lens of change-requirements. As a consequence when we communicate we try to address the users behaviour / problem, finding a solution to it AND how to implement it at the same time.

  First of all, that is way too many problems to tackle at once. Second of all this brings the conversation to a level of complexity where you are going to lose most of your stakeholders. Most important of all: prematurely going into solution mode kills the conversation around whether you at all have understood the problem you are trying to solve!

  The problem understanding and user behaviour is about what problem you want to solve, why the problem is important to solve and for whom. Continuously as we learn more about how our users interact in real life we need to capture, structure and use this information for communication and alignment.

  This learning does not right away turn into projects and tickets. This information is detached from the product and the solution. It might affect our product in the future, but not immediately. To begin with we need to use it to validate our common understanding of the customers challenges, behaviours and criteria’s for success. It will act as the foundation of our communication and as such evolve the language we use (the ubiquitous language is evolved, not constructed) . When we are aligned and know enough, only then are we ready to try to solve the problem. By limiting this content to who, what, why and excluding how (solution) it will remain at a level where ALL your stakeholders can contribute! You cannot assume that all stakeholders have in-depth knowledge about the products user experience.

  The problem understanding & user behaviours forms the basis of what we need to start exploring solutions to a problem. And be disciplined about looking for a solution without thinking about your change-requirements. If you mix up finding a solution with change-requirements you will likely end up with the natural next step of your existing product rather than the best solution to the problem you are trying to solve (here be dragons around strategic misalignment).

  Exploratory UX first approaches are great for forcing out learning within problem understanding and user behaviours BUT be disciplined about keeping the information separate to not pollute communication and alignment. This is where UX first development can make an extreme impact (I’ll write more about this in a few days)! Either way the information in the end will end up in a user experience within your product where the customer’s problem is solved. The conversations around solutions and user experience needs to be free of change-requirements, however it is always made on top of our source of communication and alignment.

  Lastly: the change-requirements. Change requirements describe how to take the product you have today and convert it into the new proposed solution. This is about describing a project, tickets, what tasks need to be done and how to do them. It requires background knowledge around both how the product works and potentially is implemented in addition to how to transition it in the best way. The change-requirements allow you to understand the impact, scope and risk of what we are about to set out to do. If change-requirements leak into any of the other sources of information it will kill the conversation. It blocks people from freely reasoning about a problem and coming up with a good solution because “that will break the system” trumps all thinking. The consequence thinking is important for risk management and you should not break the system at any cost but it needs to be a weighted decision at a point when you are ready for it.

  All these 3 concepts are levels and depths of understanding that must not be mixed. If we do, we will lose the ability to communicate. I have seen so many dev teams that retract into themselves and end up pulling strategic in addition to product roles into their teams. Not because it’s the best solution, but because it’s the only way they can stay aligned and communicate. We call them autonomous teams however on so many occasions they really become communication inhibiting teams. It really kills me when I hear things like “but stakeholders don’t know what they want”. That just means that the organisation has lost the ability to communicate.

  The single most important action you can take to enable alignment and communication is to stop polluting the information that forms the base of it. This is a topic that is really close to my heart as this is exactly what we are solving with the Uniscale tool. I do realise that this is not an overnight transition. However it’s simpler than you might think. If anyone needs help with it I encourage you to reach out! We can help you 🙂

  January 20, 2025

  product-management

  ---