A potential tool to capture user needs

Is anyone familiar with Maslow? It’s a GDS tool to create and manage needs. It’s the successor to a prototype called Needotron.

I wonder if Maslow is being outlooked? Would it serve a useful generic purpose in mapping? Could it be adapted to complement other mapping tools such as Atlas or the RealtimeBoard Canvas?

Maslow is available in GitHub although the license isn’t explicit.

I’ve added it to my todo list. Indeed, this might be a great add-on for Atlas, and actually, early versions of Atlas had something similar (but nowhere near as advanced).

A few random thoughts about integration:

• user needs should be described at the organisation level (aggregated), as the role of the CEO is to balance different user groups.
• automatic sync between maps and table of requirements are a must have.
• should we add Evolution to the Maslow?
• the need API could be a nice extentsion/addon to the wardley script.
• a source code without the licence is proprietary and cannot be used by other people than the author.

The developers of Maslow have responded to my GitHub issue confirming a MIT license.

They also kindly added some comments including saying that it’s unlikely Maslow will suit our needs.

That’s very kind of them, but it still leaves the initial question open - how to add a proper user need analysis to the mapping tool, as there are so many things to analyse. Each time I think of this, it scares me away:

• delivered value (with all the subjective flavors),
• criteria of choice (why this over that)
• what the users tries to accomplish,
• what the user is accustomed to,
• market size,
• direct and indirect competitors,
• communication channels.

All of those can be done on a company level, for different user groups, and at the component level. Plus we have negative user needs (those that we do not want to serve).

Then, each need can be proposed (maybe we will implement it), delivered, about to advance in Evolution, about to be sunset.

Then, some of those have associated impact on the value chain.

I had to write this down for my future self .

Without intentionally trying to state the obvious, could MoSCoW be applied to your initial set of requirements?

With a prioritized set of domains, some sample data that provides a good example of the complexity involved in each domain would be useful. At this stage, it would then be possible to make a start on defining metadata and classification.

This problem does suggest a graph database might be part of a solution. I would like to investigate further.

Honestly, I have no idea what could that be . I feel like an impostor.

I do not see why not. Some points for consideration would include obvious and less obvious conflicts (f.e. regulators obligating you to know your customers and customers protecting their privacy). It is like needs together with an act of balance form requirements. Another interesting aspect is the FIST/FIRE doctrine, where there is an expectation of being Inexpensive and Restrained, which kind of implies that you want to implement only those requirements that have adequate value/cost relationship, and that very often cannot be calculated upfront, at least in the uncharted zone, so that would require including Evolution into consideration.

@john.grant that’s an uber-interesting problem, which I think I will spend some time on (and in the end, it may appear it is a dead end, and it would be better to with MoSCow without additional considerations).

I think we have talked about graph databases in the past. The arbitrary nature of components makes, and an open set of relations actually leaves us no other choice than to use a graph database.

However, Amazon does not have yet a well integrated graph database available as a service that could be also spin locally (for those people that want to keep their data behind a company firewall because of the involved ).