Long long ago in a galaxy far far away the company Agulav was asked a simple question 'Dear Agulav can you please, with your low-code Smetsystuo (a PaaS) skills, come aid us in solving our problem'.

The question asked by their client was a valid one with high priority.
Recently it was found out by their client, which we will pseudonymize as Tneilc from now on out (GDPR is also valid in this galaxy), that they were using some kind of spreadsheet program to know if their company was performing well in the interplanetary logistics sector.

The problem they had with this spreadsheet program is that everyone was using different spreadsheets throughout the company and the source of truth was lost and nowhere to be found.
To ensure the source of truth was redeemed they decided on an application, to consolidate all the information in one application. This application was of course built by using Smetsystuo, since fast development was crucial.

Long story short, Agulav built an app, the company was saved and everyone was happy. THE END.

Or is it…

A recurring pattern

Although this particular story might not be true or seem farfetched, since we first have to accept that there are companies in a galaxy far far away, it does suffice as an example for how consulting in the low-code world is done in a galaxy near near where you are sitting.

The most general pattern that we see emerging in our everyday lives is the following:

  1. A company has a problem that they want to see solved
  2. The company looks for a valid solution
  3. Luckily we are a good match and are capable in providing a solution
  4. The problem is solved
  5. The company realizes many more problems can be solved by us
  6. More problems are solved

This pattern, interesting as it is, raises a couple of questions.
However to keep this short and concise my main focus will be on two questions in particular:

  1. How many problems are out there?
  2. Why was the initial problem chosen as the problem that needed solving?

The reason I focus on these questions is because I am curious if the initial problem is the best problem for solving or if there are more problems that might be better to solve.

Unknown and the known

The answer to these questions can actually be tied in a particular way. The first question is that which provides the map of the problem domain, that is to say all problems that exist. The answer to the second question tells us something of how value is perceived in the problem domain. In other words, how problems are prioritized.

I can answer the first question by stating that I don't have any idea how many problems there are in the problem domain. Even if we constrain ourselves to those problems that are part of a particular company, sadly, my answer still has to be same.

However, not all is lost, we can still try to categorize problems. By doing this we can at least get a intuition of those problems that live outside the scope of our horizon. For this I will use the tried and tested classification that can be seen in the following figure:

kuk-1

By using this classification we can talk about problems in a clearer way.
When problems are well known and understood, we will put them in the category known knowns. If they are not understood but are known to exist we can say they are part of the known unknowns. Lastly when they are neither understood or well-known we will put in the unknown unknowns.

This last category is why it is so difficult to provide an exact answer to our first question on how many problems there are.

The nice thing about this classification is that it allows for mutability, since they can change in time. Another nice thing is that they are non-scalable, by which I mean in this case that although a problem can be placed in one category by one person, they can be placed in a whole other category by a group of persons.

Initial problem summary

So having all that out of the way let's make some claims about our initial problem.

  1. The problem has to be defined as either a known known or known unknown else it would not have been formulated at all.
  2. The problem moves from the unknown unknown category, from one part of the company, to either of the other categories before it gets placed on the radar.

This move is usually instigated by an advocate, which we will dub as champion of the problem. The champion his task is making sure that the problem is heard and understood. He also tries to convince everybody that a solution must be found.

Entanglement and adoptability

So how does one map the problem domain?

Easy, let everyone in the company be a champion. This is of course not really feasible. In practice representatives are chosen to fulfill the role of champion.

One remark has to be added here however, those problems that are unkown unknows accross the company are still not on the radar, and will probably never be, untill they move to the other categories.

“ Increase profit pool, decrease costs and increase employee satisfaction: these three ... once taken to their inverse extreme on their own, seem to demote the company to nonbeing. ”

This last remark also means that we need to have iterative sessions to see if more important problems have made themselves available to us.

Having now a map of our problem domain it is time to answer the second question on why the initial problem was chosen as that problem that needed solving.

I posit that the champion aims to strengthen the pillars of the company by making a case that one or more of the following will happen:

  • Increase profit pool
  • Decrease costs
  • Increase employee satisfaction

I chose these three since they, once taken to their inverse extreme on their own, seem to demote the company to nonbeing.

In real life the above descriptions are a bit vague, especially if we want to set up our company in a more data driven way. We need a more quantifiable way. Therefore we will set up some quantifiers!
I would suggest using:

  • Initial costs
  • Recurring costs
  • Adoptability
  • Duration
  • Entanglement

Although most of these quantifiers speak for themselves I will pick out two of them, entanglement and adoptability.

Adoptability

Adoptability tells us something about how widespread a problem is. If it is reaally widespread it might be more easily adopted then the case where it solves a problem for a single person.
It can be divided into internal adoptability and external adoptability.

As an internal quantifier it tells us something about how widespread the problem is throughout the company and is part of the employee satisfaction pillar.
When it is treated as an external quantifier it will be a measurement on how widespread the problem is throughout the potential profit pool.

Entanglement

Entanglement tells us about how interwoven the particular problem is to other problems that are being discussed. As a common heuristic, less entanglement means less duration for a problem to picked up. A cool thing to notice here is that a high entanglement can point to a more meta-problem.
Which means that all those problems are actually symptoms of one big problem and can therefore be solved in one fell swoop by tackling the meta problem.

“ People are more often than not driven by visualisations. ”

Understanding a known known

To find the values for our quantifiers there is only one available route for us to take: We need to move from the known unknown to the known known. This can of course be done in multiple ways but, finally admitting to a bias here, I would suggest using a low-code platform like Outsystems as the facilitating tool.

This choice is not without reason. People are more often than not driven by visualisations. What I usually see in my line of work is that a clearer picture (pun intended) emerges when the first visuals arrive on the scene.
Another reason to use the low code platform is the speed of building solutions. So this means that in a matter of days either one of these results are achieved:

  1. The problem is well understood and built, ergo the problem is fixed.
  2. The problem is well understood but has a higher duration. The core of the problem is defined and we can continue the build on a later day.
  3. The problem is not well understood, ergo we are one step closer to fully understanding the problem.

All these seem reasonable endpoints for a couple of days work.

As a final remark note that these quantifiers only mean something if they have a certain weight to them.

This weight is company dependent. For example, in the case where there is an unbalance in the pillar of the profit pool the weight might be higher for those quantities that tilt toward the other pillars to stabilise the core of the company.

A final pattern

Having answered the two questions in which I hope was a clear way, I would like to depart by summarizing everything in this last pattern that I would love to see emerge in the near future:

  1. A company has a problem that they want to see solved
  2. The company looks for a valid solution
  3. Luckily we are a good match and are capable in providing a solution
  4. We map the problem domain together
  5. We realize many more problems can be solved
  6. We solve the highest priority problems
  7. We have recurring sessions to redefine the problem domain
  8. More problems are solved

If we are able to to make the transitions from the first pattern to the final pattern we can not only help with solving one problem, but can actually come up with a good strategy to solve all the problems starting with best one.

If you like my small article then you will love what inspired it and I would suggest that you take a look at this talk by my muse and partner in crime Marloes Kuijper about how bol.com uses a similar approach in mapping their problems