Monthly Archives: March 2015

Innovation and Lean Product Development

Posted on by

This is another portion of my on-going series for Innovation, Lean, Lean Startup, and Agile, see my last one here.

So far we’ve talked about how to combine some of the various theories together. For example looking how Lean and Agile work together or Lean startup and Lean work together. Similarly we looked briefly at how Lean Startup and Agile can be meshed, but haven’t discussed this much. Today we’re going to look at how the Lean Product Development methodology can be combined with the theories purported in the Theory of Disruption. I will look at how these can be combined with yesterdays article tomorrow.

Lean Product Development is a natural outgrowth of Lean manufacturing. It is how Toyota is able to continuously develop new products at a faster rate than their North American competitors. It is how Toyota is able to create new designs that are extremely high quality and disruptive to the market.

In the Innovator’s Solution, Christensen argues that integration and modularity are on a swinging pendulum where due to the constraints on the “not good enough” technology, that a more integrative approach is required because a fully modular design would reduce performance below thresholds that customers would be willing to pay for. Christensen argues that this would occur because relationships between firms dictate how new technologies can be developed. Whenever firms work jointly on a technology there must be agreements in terms how the components interconnect with each other. These underlying interfaces between technologies evolve much more slowly whenever there are multiple firms are working at the interface of these technologies.

Allen Ward writes about Toyota’s methodology for product development. He calls this approach Set Based Concurrent Design, where there are multiple different designs for a given new product from the start. For the case of the Prius, Toyota started the process with incredibly lofty goals and over 20 initial designs. These designs were kept loose initially, until they were reduced down to four that were selected to be turned into clay molds. During this time Toyota had been working closely with their suppliers, where they had no plans to insource more of their components than for a typical car. As it stands Toyota uses suppliers to provide roughly 75% of components to their cars, while focusing on the hardest components like the Engine and body. Similarly to a gas car, for the Prius Toyota elected to keep ownership of the drive train, and the hybrid engine systems. Otherwise everything else would be managed in a similar process as any other car.

To manage for the uncertainty of their four designs, they provided their suppliers with a range of requirements. Engineers at Toyota and their suppliers developed a range of “Trade-off” curves, which provide the ranges of trades-offs between different features and the limitations of those features. For example, engine vibration will have a trade-off with the tolerances of the Pistons. These trade-off curves increase the rate of learning for a given product and reduces the risk for a new product development.

This means with more information shared between companies there is less need for companies to oscillate between heavily integrated designs and modular designs. For an organization like Toyota the desire to share information and creating a formal process to enable disruptive innovation without owning the entire new product is a huge advantage for the organization. Toyota is actively investing in new capabilities and disrupting their competition.

This of course doesn’t disprove what Christensen is saying though. This approach has worked well for Toyota but has not been adopted by many other organizations. This is one of the problems that companies are having with disruptive technology. Furthermore, Toyota inherently turns new product development into a pseudo skunk works, which is what Christensen recommends for these ventures, by making their Chief Engineer a mini CEO for the product as well as dedicating, or as close as possible, engineering and manufacturing resources to the tasks. Finally, Toyota focuses on a few key elements that will be disruptive while reusing a great deal of older technologies maximizing technology reuse and learning from historic projects.

Disruption and Lean Startup – improving the Lean Canvas

Posted on by

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.

Agile and the Lean Startup

Posted on by

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

The Lean Startup is most likely the best example of how to translate Lean into software development directly. This set of management tools uses nearly all the Lean tools identified in the famous texts of Lean, such as Toyota Way, Lean Thinking, and Toyota Production System. In fact there are so many similarities between the two people have accused the author of basically writing a book about Lean and not adding anything to the topic. I, personally, don’t agree with this as the portions about pivoting is definitely not part of the Lean framework and is novel capability he introduced.

Furthermore, he’s had to translate a great deal of the language from manufacturing or office settings into a development setting. While there are similarities there are differences between a piece of finished goods and a completed piece of code. This difference is that the code can be pushed to “production” servers and active for users, while the finished good has to be purchased by a customer, which still may take weeks to occur (if the production system is linked to purchase orders and directly to customers). To that end Reis pushed to make as many changes to production as quickly as possible – not without testing of course, but as soon as testing was completed the change went live. This is an extreme case of single piece flow. One change goes through testing and pushed live.

Pushing in the “Continuous Deployment” model of course causes a lot of issues if you don’t have robust testing. You need the testing to be fast but comprehensive. It’s impossible to do this from the beginning so over time the team has to develop more and more sophisticated tests based on how the team breaks the existing piece of software as they deploy changes. This is where Root Cause analysis plays a key role. Do a 5 Why’s analysis (ask why 5 times until you come to an underlying root cause) fix that problem so it never happens again. In the case where you cannot prevent the issue then you need to be automatically testing for the issue to fix it before you publish the change.

Agile has similar concepts in that they there are short cycles of development called “sprints” these sprints can last anywhere from a week to a month. At the end of each sprint the goal is to have a series of features that are deploy-able (including testing) that a customer would be willing to pay for. These pieces of work are broken down into something called a “minimum viable feature” which is smaller than a product but not so small that it wouldn’t completely work. For example, an MVF of WordPress would be the “publish button” initially it would need to convert all the text in the text editor and turn everything into a viewable website and create the URL associated with that article. Over time new features can be added like the auto-tweeting capability that exist now.

One common theme between both approaches is the concept of minimum viable product, which is a set of features that makes up the product. The difference between the two approaches in developing the MVP is that the Product owner does this in Agile, while the MVP is determined through a great deal of customer interaction in Lean Startup (Ideally the Product Owner is doing a similar activity for the customer but typically acts as a proxy).

There hasn’t been a lot of authors that have looked into combining these two approaches. There are a lot of similarities as they both emerged from the Lean philosophy, which means they should be fairly easy to combine into a larger framework. The only book I’m aware of that has even attempted to tackle this is the “Lean Mindset” by Tom and Mary Poppendieck. Even in this book though, they have decided to go with a 4 step approach that has more phases than what the Lean Startup recommends. They propose the stage gate to help determine minimum levels of details. I believe that this is because of the typical levels of bureaucracies in organizations, where a Project Management Organization will require adhering to some sort of phased gate approach. The Lean Startup uses Pivots as a way to manage projects that are failing, but not with the same level of rigor or structure as the approach the Poppendiek’s recommend. Instead, the Lean Startup approach recommends setting goals and targets for metrics (non-vanity like number of views) determining when to pivot. The timeline has to be long enough to get a clear view of what your customers actually want.

Adoption of Agile compared to Lean

Posted on by

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

Posted on by

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.