Category: Uncategorized

• Cutting time to market in 1/2

  Lately I’m able to deliver commercial MVP’s with customers in half the time or less, and there is nothing artificial about it. It’s all about product work and validation, and I thought it would be worth sharing. 

  First of all I am a brain for hire so I build software with teams and companies and I have done so for a very long time. Many people do that but my approach differs some and I thought it would be worth sharing. 

  My approach for new functionality is based on this approach:

  1. Build the full user experience first (Commercial MVP, NOT technical MVP)
  2. Perform the Quality Assurance process to validate commercial fit and user experience befor building the underlying system
  3. Iterate on step 1 and 2 until we:
     1. Have discovered our commercial MVP
     2. Understand our Cost/Value factor
  4. Build the entire system

  The first 2 steps are quite similar to many other prototyping phases. However, in the workflow I use it’s not a prototype, it’s the User Experience code that will actually hit production later. That is IF it is deemed commercially viable with an acceptable cost/value.

  So, what is the consequence of working this way and what are the trade-offs? Let’s start with the potentially controversial changes to how people work.

  Postpone all backend implementation

  In this approach I postpone 98% of all backend implementations until AFTER we have run QA on the full User Experience of potentially a quite complex system. However, this does not mean that the application has no logic, it will actually have all working logic and functionality required to run a QA on commercial fit and cost/value calculations.

  Before you think I have gone completely mad let me just say that I have actually built systems and tooling to achieve this. Which allows me to build full user experiences which mocks out all backend functionality and later allows me to easily implement backend systems in step 4. The tool is peercolab.com btw.

  So why is this a good idea? Because of the following reasons:

  • The first iteration of a solution is rarely the one that solves the problem
    • And it will often reveal that we didn’t even understand the problem
  • Integration is the killer of iteration speed
    • This is why we have been led to believe that microservice to monolith is the solution to our problems. As if we had no problems before microservices became a thing….
  • Persistent state management and concurrency is a waste of time before you have validated that
    • You understand what the problem is
    • You understand what the solution to the problem is

  Having the discipline to postpone this decision is often hard because it feels unfamiliar. However it is the single most rewarding step in my approach. This allows us to not fear change, to learn, to re-write functionality and discover the right commercial MVP. To be honest most projects I see accumulate legacy long before it even hits production because of prematurely implementing and designing large structural systems. And doing so before we even know whether it solves the real-world problem.

  Separate problem and solution breakdown

  This is a big one too. The way I define it is that the problem surrounds what real people do in their real life regardless of whether they have an app or a software system. In the problem breakdown there is no software system. There are people, behaviours and criteria for considering what it takes to recognize a solution.

  The Dunning Kruger Effect has an enormous impact on the problem breakdown as the problem breakdown for a commercial MVP is usually quite big. This is why separating the problem and the solution breakdown is so important. Although our natural instinct is to understand a problem by visualizing a solution to it, we need to understand that bringing the concept of a solution into understanding the problem increases the complexity by orders of magnitude. 

  I use a systematic approach to problem breakdown that I call Clear Thinking. It’s really nothing fancy, it’s just a systematic way of breaking down a problem and still be able to postpone the solution breakdown.

  Build a quality user experience to learn, not necessarily to release

  When I build the user experience I build it to validate, not to ship. This does not mean that it has low quality or is some thrown together prototype. It means that it is built with quality BUT with the purpose of being able to rip it apart at any point in time because our quality assurance and validation iterations reveal learning in the problem and/or solution domain. One of the outcomes could be that the solution will not be worth the investment, and it would be great to discover that ahead of making the investment.

  And technically again, this still means doing data breakdowns, API modelling and all the things that we are used to doing. However we will do them so that we can build and validate the user experience and perform commercial viability tests first, not because we want to build the underlying system yet. However we will simulate it!

  Conclusion

  As I started out in this post and the reason why I wanted to share it is because of the effects of it. Like I said I take companies and teams to a commercial MVP in usually less than half the time of what they are used to. It also leaves them with much less maintenance cost and the real beauty, alignment! Because of the problem breakdown approach and iterations, the teams end up almost strangely aligned. Which after all is not strange at all. The only thing that everyone in a project can align on is the user experience, and by approaching the user experience first you give everyone a seat at the table.

  -Svein Arne Ackenahusen

  October 15, 2025

  product, technology, ux

  ---

• 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

  ---

• Leadership meets AI

  I want to explore the surprisingly deep connection between AI and leadership.

  At its core, great leadership isn’t about having all the answers. It’s about setting direction, creating clarity, and enabling others to do their best work. This is especially true when leading experts. The only thing you can do is clearly express the larger intent: where we’re going, why it matters, and how we’ll know if we’re making progress.

  That’s the kind of leadership that unlocks real value.

  Now, with AI entering the picture, we’re all being thrown into a similar position. Each of us suddenly has access to an incredibly capable “expert” that can help solve problems: if we can express clearly what we want. Working with AI demands the same clarity we expect from great leaders. You have to express not just the task, but the why, the value, and the criteria for success.

  The ability to define problems, articulate intent, and guide solution proposals isn’t just a “nice to have” anymore. It’s becoming a core part of everyday work. And it doesn’t stop at the individual level. If you give your AI tools access to all your organization’s content, the real leverage comes when that content reflects shared direction, priorities, and purpose. That’s how AI becomes aligned with the organization strategically.

  That’s why I find the Clear Thinking model so powerful. It gives structure to this mindset: separating Intention Requirements (the what, why, and success criteria) from Solution Suggestions (how we might get there). At first, it seems like a tool for writing better briefs or specifications but zoom out, and it’s really about leadership. Then zoom out again, and you realize it’s a key to unlocking the potential of AI.

  If you want to either lead or utilize AI then learning how to express yourself clearly is the key, for you and your organization as a whole.

  Apparently, Madonna was a leadership and AI pioneer all along 😉

  March 19, 2025

  ai, artificial-intelligence, leadership

  ---

• 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

  ---

• Where’s the Domain in DDD?

  Where did the “domain” in “domain-driven design” go? The technical patterns of DDD are great for manifesting the domain within your implementation, but that doesn’t necessarily make it “domain-driven.” Shouldn’t the domain (i.e., the “real-world problem”) you are trying to solve through software come from the real world, as opposed to the technical world?

  Communication, as highlighted through strategic design and most importantly the ubiquitous language introduced by Eric Evans, has always been the key to unlocking DDD. But how do we ensure that the real stakeholders in an organization or project drive the process?

  I believe the answer lies in defining value. What if you ask yourself and your team: Are we producing value? Who would be able to answer that question? It’s not a philosophical question; it’s crucial to remember that we are paid monthly to provide a service. Whether the one paying us is an organization or an external customer, the vision, purpose, and most importantly the accountability for what you are working on originate there. As a result, the definition of value must originate there too. This makes them the true stakeholders. Therefore, domain-driven must mean that the software project is driven by a vision and a purpose defined by those who are ultimately accountable for it.

  For a software project to be domain-driven, there must be clear communication through all roles—from the true stakeholders through product owners, project managers, UX/UI designers, software architects, developers, quality assurance, customer care, and so on. If not, how can anyone in these roles know whether they are producing value or not? And if you don’t know if you are producing value, it’s impossible to claim that you understand the domain. It is not enough to just monitor end-user feedback. If we cannot determine whether that feedback aligns with our overall vision and purpose, we cannot assess its value.

  For the word “domain” to be part of DDD, we need a systematic communication framework that allows all stakeholders to be part of the same conversation (at the level they can contribute), using the same ubiquitous language, and all being able to contribute their parts while always staying within the frames set by the true stakeholders.

  January 20, 2025

  ---