Running Lean Is Bad For Business
Ever since I first heard the term running lean I was confused by its appeal. Maybe it is because in the early stages of my career, I was a student of Waterfall and the idea of purposely avoiding the documentation stage just seemed irresponsible and actually, impossible to accept. But the industry was moving in that direction and I figured I needed to learn it for the sake of my career. But the more I learned about lean, the more confused I got.
I was then told I need to understand product market fit, if I was to truly appreciate how the lean model is applied throughout the product lifecycle. And again, my confusion grew. Was Steve Blank (the person who first coined this phrase) trying to tell us that before building a company, a team, it is important to first verify where and how a product will fit into a given market? This couldn’t be the case…could it?
At this point and based on my experience, I have yet to find a single reason going lean is beneficial. To me, it feels more like a fad and one that will ultimately be beaten in the market by more informed approaches, including Disciplined Agile. Simply stated, there is no substitute for well-written and researched documentation. Yes, I agree that Waterfall may have taken documentation too far but without any understanding of the backend that will host a system, how it will scale (including interdependencies), and how each phase of development will influence existing, “live” technologies makes little sense to me.
And to that end, one of my biggest objections to many of the products on the market today, is that there is no discernable difference between them. For example, how many survey tools exist today? These are products without companies and I just don’t get it. In part, this is the result of the product market fit culture. A product is only as good as the folks supporting it. And in my view, part of validating the potential success of a product is appreciating who it is that will be working behind the scenes to ensure it performs optimally.
Part of product development is understanding how it will be supported. Are there people who can help product owners get buy in from others at their company to best-ensure scalability between departments? Libby Maurer wrote an article titled, Why UX Research Is Business Research where she includes a great example of this challenge –
“The head of Marcom wants to extend the use of our product by adopting the video platform. But the IT department owns the decision and has selected a platform from another vendor, unaware that we offer something similar.”
She continues by stating “this customer has low product utilization (the what) due to IT’s ownership of buying decisions (the why).” The sheer volume of redundant technologies I have observed within one organization is baffling. Scott Brinker does a brilliant job of demonstrating this in a recent article he published. While the intention of the article is to highlight the amount of technology organizations are utilizing, it is hard to not observe how many companies are using two (or more) vendors that offer redundant services. In some cases, this is understandable…but in most situations, it is dumbfounding. Much of the time, this occurs when one department uses a specific system and another team using a similar piece of technology.
Maurer wrote another great article, How to Fix Enterprise UX: Find Your 99%. The basic idea that one may take from what Maurer wrote is that (arguably), the best software is created with a focus on the end user’s experience. To that end, the people purchasing software and those that will use it, are often not the same. In this same article, Maurer quotes Jason Fried as stating, “The people who buy enterprise software aren’t the people who use enterprise software. And it pulls and pulls and pulls until the user experience is split from the buying experience so severely that the software vendors are building for the buyers, not the users.”
There are so many variables to consider when developing a new product. We must consider different users, the players involved in choosing products versus using them. And I simply reject the notion that all these fancy terms and processes (E.g. lean, product market fit, sprints) can substitute for well-planned products, created by product teams (including UX Researchers).
—
Thanks to Joe Cimino who brought these articles to my attention.
