BEYOND TECHNICALITIES

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 🙂