There is an unfortunate pattern in business where, once an idea becomes successful, people try to copy it into all sort of other scenarios. I always felt like the following picture summed up nicely how everyone feels about this phenomenon, as it relates to the outcome of the Agile Manifesto:

The main problem with this pattern is that, sooner or later, people end up applying said idea to scenarios where it is not really applicable. At best, the idea becomes ineffective or a distraction. At worst, it can work against you, leading you down a path that destroys value instead of generating it.

The one instance of this pattern I want to focus on, is the pattern of slapping “Lean” in front of everything nowadays (I will probably write additional posts about other instances in the future). Since Eric Ries’ classic book (which I can only strongly recommend), the concept has been copied and over-applied to a degree that is hard to believe. As I was typing this post, I searched for “Lean” in the books department of Amazon, which promptly returned the first 16 of a stunning 20,000 results! It is hard to argue that the concept has not been over-applied.

Before I dive into the impact of misapplying the “Lean” concept, I would like to state on record a couple of disclaimers:

First and foremost, I find the concept of “Lean Startup” as originally described by Ries, as well as the associated concept of an MVP (Minimum Viable Product), to be a really powerful idea. My objections lie not with the concepts described by Ries, but rather with the misapplication of those concepts. If you are a startup that is using Lean to discover as quickly as possible the right product for your target segment, then you have my full support.

Second, I draw a very strong distinction between Lean Startup and MVP as concepts, and the concepts behind the Toyota Production System. I personally think the idolatry of the TPS is also an instance of this pattern of misapplying ideas to contexts where they are not applicable, but I do not intend to address it in the current post (perhaps a future one).

And with the two disclaimers in place, time to dive into some of the dysfunction that ensues when the concepts of Lean and MVP get misapplied. The problem with this particular instance, is that misapplication of “Lean” often falls in the damaging category.

Let's start with a case that is unfortunately all too common in the world of B2B (and one that many of us in the industry have experienced first-hand): that of the brand new version of software. Companies with products that are well established in their target segments still need to renew their software every few years, if for no other reason, to remain competitive and to adjust to advancing user expectations. And quite a few of them come up with the seemingly natural idea of “doing a lean MVP” and “iterating rapidly”. While there is nothing wrong with iterating rapidly on the UI/UX, conflating that concept with the concept of an MVP creates an interesting pressure to go in the wrong direction: that of putting in place a minimal architecture that cannot serve the needs of a production customer. After all, putting in place infrastructure for scalability, data security and safety (e.g. encryption at rest), business continuity and disaster recovery, auditing, traceability and observability, monitoring, cost efficiency in operations, and all the other little things that are generally characteristic of large-scale Enterprise-Class Software often takes a lot more time and effort than the actual functionality. The end result is that, in the spirit of an MVP, the company bypasses all of these requirements and instead starts developing with an architecture that is a skeleton architecture at best. This is, of course, more than sufficient to support obtaining feedback in the demos at the end of the sprint (you are doing demos to your real users at the end of each sprint, right?), but it contains the implicit assumption that the MVP will be replaced with a different system at a future day, more suitable to the rigors of actual enterprise use. That is generally when the other shoe drops: your business management has spent a lot time and money to iterate over the new user experience and now want to monetize it. And they have seen all the functionality with their own eyes (in those same sprint demos) so they can't understand why the product is not ready. To make matters worse, if you were successful in dramatically improving the user experience, your very large B2B customer has been hearing their users raving about the new product, and is unwilling to continue with the old one. The end result: your MVP, which still has a skeleton architecture, is pushed to production, along with a massive amount of technical debt, and woefully insufficient support for all the non-functional requirements. Since the major manifestation of this deficiency appears as poor scalability, performance, and stability, both business and customer perceive this as a quality issue, and the fact that the wrong strategy got executed is very neatly masked and very hard to diagnose.

So, where did all this go wrong? Or stated differently, why does an MVP make sense for a startup but leads to so much trouble in this case? For one thing, an MVP is designed to do something entirely different in a startup: it is designed to establish problem-solution fit and product-market fit! In an established B2B creating a new version of a product that has clear market traction, neither of those two things need to be established. The MVP is clearly being applied to something other than what it was originally intended to do!

Using a similar scenario let's examine a second way in which companies get in trouble. Once again, your company is exploring the possibility of a new product extension for some of the large B2B customers. A product manager reaches out to one of the target customers and convinces them to engage in a pilot. The company invests in an MVP, developed in close cooperation with the pilot customer. After the MVP is completed, the sales team tries to convince other customers to sign up to the product extension, only to find out that the product is too specific to the first pilot customer (it evolved into a point solution), and the rest of the customers are generally not interested. The outcome is that you now have a product that very few customers have signed up for, that you have to support and maintain. Unfortunately, business management is not willing to lose the small amount of revenue that the product is generating so they commit to keeping the product in place. Here the company comes to a fork in the road: down one path, the company can continue to maintain and support the product but at the cost of losing money on it. Down the other path, the company continues to provide the product to the few customers that have signed up, but minimizes investment, effectively not properly maintaining and supporting the product. Understandably, neither of those outcomes generates value.

Once again, there is a key misapplication of the original Lean Startup idea that led to this outcome: remember that the original point of the MVP in Lean Startup is to establish whether the product is viable in the market, and if not, pivot! In this case, the pivot never happened. I think every entrepreneur instinctively realizes that a pivot that is necessary but never happens will spell certain death for a startup. The problem is that for an established company, a missed pivot behaves more like a chronic condition than an acute one - it will certainly deteriorate the health of the company but, because the effect is not immediate, the danger is not as visible.

The third and final dysfunction is a bit more subtle: pivoting in B2B is radically different than pivoting in B2C. There are two effects behind this:

• In B2C you define a product with the help of the law of averages: even when practically non-existent, a B2C company is going to be working with a sample user size of over 1000 unrelated users. The end result is that it is much harder to end up with a point solution - there's simply much less opportunity for group-think in a sample of 1000 unrelated users, than a sample of 40 users that work for the same organization.
• Pivoting away from 1000 users to what could potentially be of value to hundreds of millions of users is a lot easier to do, than pivoting away from the (admittedly partial) requirements of a B2B customer that represents 12% of your revenue.

At the end of the day, making to leap of faith to pivot is simply a lot harder to do in the context of an established B2B company with existing large customers.

Long story short, read the product label carefully before you take the medication!