My frustration in respect of the processes and hoops I had been going through to ensure not that people began to understand that intuition validation was worth doing, but that there was no point in stopping it long-term, as had been the case for around six years to when I developed the online whitepaper in question, led me to do something I didn’t really agree with: produce a roadmap for a technology I felt needed to exist in order to solve a problem most people were afraid of solving.

Two reasons I didn’t want to do this:

1. I had been through an innumerable series of startup ecosystem accelerator sausage-factories, which clearly weren’t designed to enable true innovation, never mind invention, but ensure — fundamentally — that those who had portfolios of existing startup companies wouldn’t see themselves endangered by anything which became excessively disruptive.

2. Although I describe the accelerators as sausage-factories, I actually learnt a lot. I learnt how to do lean properly, and how not to. I also learnt that most technologists and investors become shiny-eyed by the idea of spending more time thinking about the bright new techie toys they could jump into building than they do about the possibly more humdrum pain in the real world, that is the problem we want to solve, which — to my mind — should really focus 40 to 60 percent of all the time we spend developing a technology.

In truth, whilst I saw the best process would be to actually follow lean as laid out, I saw very few people doing this. There was no incentive to get the solution exactly right first time round through more highly developed discovery procedures, because reworking of software a posteriori meant greater opportunities outwith the original budget to further invoice the client, by then far more dependent on the supplier.

What follows is an example video of a process I began to scope a while before o mi wan itself, where if delivered we’d have reconfigured everything we did in tech, via the creation of an absolutely privacy-positive workspace where, in a discovery interview, the interviewee would have total control at every stage — even in a corporate software discovery process — whilst being consulted as to the real problems the business needed software and other digital solutions to.

The idea being that people didn’t tell the truth in standard software consulting about what was needed, and therefore reworking and resulting runaway budgets became the norm in second and third phases.

In my view, systemically — that is, the wrong focus was being applied, and there was no incentive to apply the right one.