What I will say is going to disappoint many “startuppers” and many “design thinking consultants”. The hard cold reality is rarely lovely.
The Lean Methodology has been marketed as a way to simplify product design and make it accessible to everyone, particularly artists and practitioners who use coloured markers and cardboard models.
However, this interpretation of Lean can result in a false sense of ease and the notion that the laws of physics and well-established software engineering principles magically don’t apply. According to Eric Ries’ book “Running Lean,” the definition of a minimum viable product (MVP) is the bare minimum set of functionalities that a potential user is willing to pay for and should be the first product that is produced.
It is crucial to note that the MVP must be a tangible and functioning product, not just a cardboard prototype or graphic images of a hypothetical product. I would underline the V in MVP, for “viable”. Minimum, yes, but do not forget “functional”! The product “must work”.
You could simulate user interaction flow with an App using a cardboard model or a more sophisticated mock-up. You may end up later in trouble if your system is not capturing required information, or you can’t ensure a realistic response time, or the data you should be showing to the user cannot be calculated or retrieved (unless you actually design How to get that data, and that could not necessarily be easy). Or you could be promising your client a feature that Apple prohibits on their App Store.
What surely you cannot deliver is a working bottle capable of capturing water from the air, filling itself in a few hours, all using solar power.
Well, they actually tried advertising that product, and, respecting the Lean approach, they did not try to actually build it. They had just prepared a professionally edited nice-looking, captivating video using computer animation, and advertised the product on Kickstarter.
It was a huge “success”, meaning that, were such a being in existence, many people would have bought it. So, you had an idea and validated it by convincing some naive folks to grab their credit cards and actually place an order.
There was only one little tiny irksome problem.
That product can’t be made, not now, not ever. It is impossible from a thermodynamics point of view. You would never capture enough solar power to actually condense that much water without solar panels that would take several square meters of space. Nothing you could dream of transporting in your backpack.
Applying the Lean methodology effectively requires a specific level of expertise in the discipline in which it is being used. Without this, the methodology becomes a “Cargo Cult” where strictly following all the ceremonies and rituals leads to the creation of non-functioning products without the necessary theoretical and practical knowledge. Designing a product cannot be deferred until later if the physical idea behind the project has not been proven through a prototype or feasibility calculations and the application of scientific and technological knowledge. Failing to do so results in an exercise in futility, much like drawing a spaceship in a notebook without any understanding of actual “rocket science”.
Similarly, one cannot expect to design an electronic device without a basic understanding of electronics. You can ride training wheels by using some prototyping platform made for non-technical users and bring home some partial design within the scope of the tightly defined limits of what that prototyping platform allows. The easier the prototyping platform, the less you can achieve with it.
This unrealistic and false notion of “Easy Design” can lead to scepticism among those who think logically or have a basic understanding of the subject. This is why I am sceptical of Design Thinking, and Lean Methodology practitioners who have never concretely created any software, worked in a technology design studio, or participated in creating an industrial product.
It is interesting to note the “lean design thinking” consultants disgusted reaction, witnessed personally at some of their workshops not that many years ago in Milan, when an actual software developer proposed creating an actual working prototype with code or at least with a hardware prototyping platform. It defied their mantra that: “You have to test it without actually building anything”. And the conceptual error is leaving the engineer out of their room.
The hilarious thing is that these folks define themselves “Agile”, following “Agile principles” while in practice are pretty much Waterfall. The easy part they leave to themselves; the hard part is a leftover for later on, down in the waterfall, left to some unsung hero of an engineer.
The belief that design is simple and can be achieved through simple drawings is a classic example of the Dunning-Kruger syndrome, where ignorance is mistaken for simplicity, and some feel comfortable declaring themselves experts in something they know little about. It is important to acknowledge that defining the activity of writing software or designing a product as “easy” tasks (not important, just implementation details that you can pass to some developers) is a mistake that can lead to serious problems.
I am similarly wary of team leads and, in general, managers that take decisions on technical matters that are not in their personal back history. Can they be trusted to understand the risks involved? Why don’t they delegate these final decisions to those that understand those risks, that is, engineers and developers?
If you are in consulting, It is hazardous to leave the client alone (usually a “product owner”) with marketing guys and designers with no actual engineers and technology guys in the loop. If the product owners do not understand the technical development of an actual product because they have never done it… you are in for a bumpy flight, double so if the POs are arrogant and affected by Dunning Kruger syndrome themselves. Sometimes, the ethical thing to do is renounce: you cannot deliver something that can’t be done. But to know that it can’t be done, you need technical expertise. Calling in the tech guys too late will end up in tears later. This also happens if the tech guys have no integrity and have developed their careers for being docile “Yes Men”. They won’t raise the alarm even if they spot the problem.
Sometimes management won’t listen to engineers. This may lead to spectacular failure, sometimes with tragic loss of life, if the system is a life-critical one. Does anybody remember why the Space Shuttle went offline?
Product design and development require hard work and expertise to ensure the product is functional, usable, and meets the target market’s needs. While the Lean methodology can streamline the process and make it more efficient, it does not eliminate the need for hard work and expertise.
Creative artists, UX researchers and developers need to work together in a close loop. You can’t cheat the process by declaring product design done just because you have produced some good-looking screen prototypes that “have been approved by the client and can’t be changed”.
Studies have shown that product design and development involve significant time and effort. For example, according to a study by the usual suspects, the Nielsen Norman Group, it takes an average of 17 hours to design a single screen for a mobile app. If you want to ensure usability, you need a minimum of four iterations.
Another study by McKinsey & Company found the obvious fact that developing a new product requires significant collaboration between engineering, design, and business teams and involves multiple stages, including research, prototyping, testing, and iteration.
In conclusion, while the Lean methodology can make the product design process more efficient, but it does not eliminate the need for hard work and expertise. Product design and development require significant time and effort to ensure the product is functional, usable, and meets the target market’s needs. Effective collaboration between engineering, design and business teams is crucial for a successful outcome. The dangers of applying the Lean methodology and design thinking naively should also be acknowledged: It can fail the product even if the design appears promising on paper or in graphics.