Disruption and Lean Startup – improving the Lean Canvas

One of the more interesting tools I’ve discovered lately was the Business Model Canvas. This was created by Alex Osterwald with a huge group of people. I thought it was incredibly useful for putting issues that companies have into a specific context. However, I did feel that something was missing. Something important. The picture linked above is extremely useful for an existing company that wants to put everyone on the same page, but I felt that it would fall a little flat in helping a new company start. There are simply too many unknowns to answer a lot of the questions that are in the frame work.

This is where the book Running Lean comes in. The author decided to adapt the business model canvas into something that a lot of entrepreneurs could use the Lean Canvas. In entrepreneur circles today, the most important thing to focus on is the problem trying to be solved. If you don’t have a clear articulation of the problem you’re trying to solve you’re going to fail. As such, there is more of a focus on the problem, the metrics associated with the problem and less focus on the planned solution. Secondly, Ash Maurya, argues that the best way to use the Lean Canvas is to look at both the problem and customer segment concurrently. Ignoring any potential solution, but looking at the problem you’re trying to solve and the people you’re trying to solve it for. This helps keep in perspective the real goal with your product, solving a problem for a customer that they’d be willing to pay you to solve.

However, I believe that this solution is still missing something which is something of an analysis of the existing competition and the planned solution. While Maurya does highly recommend including existing solutions under the problem, there is no effort to really use them – other than to make sure your product is different than their product. With the Lean Canvas the goal is to interview customers to identify if your existing solution is worth pursing more through rapid continual feedback – leveraging the MVP that I discussed in my last article. There are a few questions that can be asked to help shape the direction of the solution before talking to any customers.These questions come from the Theory of Disruption which argues that there will be less competition over time for the customers you’re pursuing because incumbent firms truly don’t want them as customers.

Does this product compete with Non-consumption? If you can answer yes to this, then you are expecting to undercut an existing incumbent that does not serve an existing market segment. In the case of Radios this mean extremely low quality devices that most people wouldn’t buy. In the case of video games now, you could argue that consoles are competing against non-consumption, this argument makes even more sense in terms of games on a smart phone. If the answer is No, then you need to ask the next two questions.

Does this product represent a sustaining technology? If you introduce this product to the market does it go after the same customers that the existing firms are already attempting to serve? Furthermore, does it go after the highest most valuable customers in those customers segments? If you answer yes to this, you will face extremely stiff competition from incumbent firms. They want those customers and will fight you tooth and nail for them. You will lose against those businesses and should look for a different solution to the problem you’re trying to address. If the answer to this is no, then you need to ask yourself the next question.

Does this product represent a disruptive technology? If you introduce this product would only the least valuable customers decide to purchase it? These would be customers that are being over served by existing solutions. For example, Pandora and Google Play Music both represent solutions for people that are over served by Apple’s iTunes. For customers that find iTunes to be part of their iDevice there’s little reason for them to look outside Apple’s Ecosystem especially since there are solutions for Apple users in that ecosystem. However, for non-iDevice users, iTunes represents a product that has many features that are undesirable. So Pandora and Google Play Music represent a smaller music collection where you never own the actual music you’re listening to even if you pay a premium for the updated services. This is disruptive to iTunes for that very reason.

Including these three questions at the minimum, with a clear understanding as to what they each mean, will help shape the solution to the problem you are trying to solve. Additionally, it will help you understand what customer segments you should pursue from the very beginning. As you are successful in capturing the lower tier customers you will continually improve your product and begin to move farther and farther up market. Which allows you to then truly disrupt the market.

Combining these theories into the Lean Starup approach will help understand the best route to pursue. Furthermore, you might not be able to answer these questions honestly. You will likely need to get customer feedback pertaining to these questions. Don’t as straight forwardly if the customer thinks it’s sustaining or disruptive, they won’t understand what that means. You will need to ask them if a competitor is already offering this service and if they aren’t using it why. If they are using a similar service make sure you try to differentiate between the competing product and high light the differences. Try to understand if your competitor would release this and if their customers would use the service.

That’s where the Lean Startup Build Measure Learn cycle comes back into the fore, you ask questions, learn build again, learn, and continue the cycle.

Adoption of Agile compared to Lean

This is part of my ongoing series devoted to understanding the connection between Disruption Theory, Lean Startup, Lean product development, and Agile software development.

In many organizations the adoption of Agile software development techniques have been adopted rather quickly. For those unfamiliar with Agile software development, the point is to focus on user experience through developing software that is created through user stories (there’s a lot more to it obviously). Agile grew out of an understanding of Lean practices, where there is a strong focus on learning, daily standups, and understanding where and why things went wrong. This includes the use of the 5Whys which was highlighted in the Lean Startup. In away the company becomes a learning organization as there is a set meeting every sprint to reflect on the last few weeks of work. Agile was initially conceived around the turn of the century and has seen steady adoption over the past 15 or so years.

Many of these ideas came from Lean. While retrospective isn’t specifically called out in Lean, it happens consistently through a Plan Do Check Act cycle. Furthermore it happens through Root Cause analysis which happens on nearly a daily basis whenever issues arise. Much of the most ardent Lean practitioners are found in manufacturing, however it is making headway in other areas of the organization over time. Lean was Popularized in the early 90’s by the book “The Machine that Changed the World” but is much older than that and had been adopted by Toyota competitors as early as the 70’s.

So, then why, when Lean is the inspiration for Agile (as well as the Lean Startup), has Agile been heavily adopted while Lean has not? I do not mean to say that Lean isn’t used; it’s used a lot of places. However, it’s not used in the bulk of companies around the world or used uniformly throughout an organization. Agile has been adopted as a methodology across many industries and within many different types of companies. It is also not possible to say that one works while the other doesn’t. Both have been shown to improve processes and drive cultural change within an organization. I think that Agile has been more quickly adopted in broader corporate America than Lean because, similarly to Lean, it was made by and for the people that use it the most; Corporate IT. IT/Software development has owned the deployment of Agile practices which has made them much more successful at adopting them than those same corporations adopting Lean practices.

Agile has had the luxury of being successful in many organizations in a very public manner. Which has lead to a lot of top down support and required adoption of the methodology. This makes adopting specific methods for project management significantly easier for adoption of any given methodology. In fact, Lean and Six Sigma deployments are only successful whenever those deployments are attached to specific strategic initiatives. With IT any project that is funded for development is by definition strategic resulting in clear alignment between the Agile deployment and the execution of the project. Lean typically does not have this luxury.

Furthermore, Lean is not well regarded in many leadership circles as it is not typically taught in high level MBA courses. Agile on the other hand has made it into Masters programs for both IT and Computer Science. Meaning that the leaders responsible for owning processes and project results learned about how to deploy Agile in their education and it was a highly stressed practice. On the other hand Lean is part of Industrial/Manufacturing Engineering and to specific business niches. Which means that there’s a clear misunderstanding of Lean and the management practices that accompany the tools.

Coming to Agile from the Lean perspective, I believe that Lean practitioners have a lot to learn from the Agile community around adoption. Much of the actual practices are extremely similar and anyone with a strong Lean background will be able to transition into an Agile environment easily. The transition the other direction will be only slightly harder, mostly because of the broader range of performance metrics associated with Lean compared to a handful with Agile.

Innovation and Lean

I’ve been doing a lot of reading around Disruption Theory, Lean product develop, and Lean Startup theory including the application of all three. One of the more interesting aspects of Disruption theory is that people hire products to do specific jobs. This is fairly similar to the questions that Lean Startup and product development ask, what problem are you trying to solve. This hired to solve a job approach seems to instill some limitations if these jobs aren’t continually re-evaluated. For example, in the Innovator’s Solution they talk about RIM and their Blackberry device, now this book was written in the early 2000s, which means that there was an actual debate if they should include cellular service or not. They argue that the job RIM is hired to do is to provide short periods of distraction to business people.

The risk of not re-evaluating these jobs on an extremely frequent basis, such as quarterly or annually, would likely lead to missing out on something like the iPhone. What I found interesting in this section of the book is that they argue against cramming every type of feature into a single device. I think that, at the time, this was sound advice due to the limitations of the technology, the costs of doing that, and immaturity of the markets still.

I believe this is where the Lean Startup approach really would help. Innovator’s Solution basically argues for the minimum viable product for a given job. Afterwards, through collecting data on how the users actively use the product the team can learn in which direction the product should mature. Through engaging continually with the customers it’s possible to understand and, with the right questions, determine if and when the job the product is hired to do is starting to change over time.

For example, iTunes was originally designed to be a light weight music playing piece of software. The job was to play music. Over time, because of the goal to move up market and capture other markets, Apple added new features, changing the jobs that iTunes was capable to fulfill. In some cases this lead to clear overserving customers and has since been accused of becoming bloatware. Using the correct metrics Apple would know if they were losing market share or if their market share was being artificially maintained because of the iPhone/iPad. This means that the music playing space is clearly ripe for disruption. The most popular product is over serving most of the market and causes excess performance drain on systems using the software. This is clearly why, despite iTunes popularity, services like Last.fm, Pandora, and Google Music are so popular. They are meeting the market where the market is and moving.

Over the next few weeks I plan to explore these theories and techniques in more detail. I plan to work towards something of a unifying theory and then attempt to deploy them in a startup of my own and write a book about the process. I have no idea what startup I plan to start but that’ll be half the fun! As a writer for KBMOD, I plan to work with the leaders of that team and deploy these theories with them. Hopefully seeing positive results for those guys.

Strategy and Business Management

As I mentioned in my Business and Silver Bullets article, there are a lot of different approaches to managing your business, or at least a portion of your business. None of these approaches are easy to implement and it seems that there’s a bit of a revolving door around what leadership approach is the best for a given business. Furthermore, it’s troubling to me that organizations are looking at initiatives like Lean and Six Sigma as only operational improvement opportunities. As I’m reading through how Business Architecture works, it’s obvious to me that many of the organizational deployments of LSS have failed in reaching their full potential. I saw it at Samsung, AMD, and I’m skeptical of the full reach I’m going to have at Regence. It’s not a failure of the individuals deploying it or of a given leader, it’s a failure of the full organization to accept that changes need to happen. Organizations need to integrate approaches like LSS into their core strategic planning process. Otherwise those methodologies will only impact a limited area and won’t appear to have a holistic approach to making changes to an organization.

From my experiences Lean and Six Sigma methodologies can indicate the need for organizational re-alignment. These require real change with serious effort to implement those changes. In many cases those are outside the scope of the project facilitator, the leader of the process improvement center of excellence, and likely the owner of the processes. It’s got to come from an executive sponsor. They have to be able to provide the organizational courage to make real changes to an organization. Through these tools it’s possible to identify redundancies and areas where organizations require massive change.

Why don’t organization implement these changes? Too many priorities is likely one problem. Another is that these changes are hard and unless they are well versed in Lean or organizational structures, they won’t understand why the changes are fundamental to continued success of an organization. They may not understand the changes because they weren’t involved in the redesign process intimately enough. Finally, it might also be that these changes are bottoms up recommendations and not top down.

I believe this is why Business Architecture eventually was a created as a discipline. I believe in organizations that are truly Lean that these types of roles are not needed. Simply because the bottoms up approach allows the leaders to focus on different things especially since a true Lean organization is always customer centric. In organizations that there is a great deal of legacy behavior and entrenched management fiefdoms, it might be a requirement to go through an organization like Business Architecture to give the true sense of ownership to the leaders. It makes the bottoms up recommendations that come from the BA team seem like it’s a top down approach that is sanctioned by all of leadership. It let’s people see that clearer tie between the different organizations in a way that a lot of Lean work doesn’t. It’s designed to be holistic not something grown into the whole over time.

This leads to a different method for developing strategy than what a lot of Lean practitioners utilize. Business Architecture focuses on the current capabilities and works to align the strategy from there. Lean starts with the 5 year vision and goals and figures out how to align existing projects and improvement efforts to enact those goal, through providing a metric for the person doing the work on the ground.

I think that these business management approaches are both valid, I’m really biased towards Lean, but I do believe that in many organizations Business Architecture is likely required. It leaves the control a bit more in the leadership rather than the Lean approach. I believe they both can impact strategy in an effective manner, but it’s likely that BA will be more tightly coupled from the start than many Lean initiatives.

Businesses and Silver Bullets

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.