Category Archives: Innovation

All posts that talk about innovation theory and technological innovations

Lean canvas, Lean Development, the Theory of Disruption

Posted on by

In yesterday’s article I talked about how you can use a product development approach called Set Based Concurrent Design (SBCD) to avoid some of the risks associated with developing a disruptive design regardless of how integrated or modular a given technology and its platforms are. Before that I had written about a concept called Lean Canvas to include questions associated with disruption to help push the initial design into a more disruptive place to maximize the likelihood of success.

In “Running Lean” the author, either knowingly or unknowingly emulated the benefits of SBCD whenever he fully described his approach for creating Lean Canvases. Ash Maurya recommended that for any given startup to initially start with multiple different views of the initial Lean Canvas which could represent different solutions, problems, customer sets, and metrics. Each one of these is to be discussed with potential customers in interviews.

However, once you understand your customer, you’ll need to begin developing your solution. In the case of a piece of software it may be easiest to simply caret multiple wireframe mock ups that emulate the SBCD. While with physical products, you’ll need to start with several mock ups and ideally multiple different specifications for components within the design. This is important as you may need to mix and match components of your physical design based on the niche customer set that you are targeting. The best result may end up forcing you to create a product that might be difficult to make if you don’t plan for the different specification interactions from the beginning.

While building your product as  you look at each different iteration it is important to continue asking if the actual solution continues to be disruptive or if it has slid into a less disruptive niche in the market. It is also vital that you still are aware if the interaction between the changes in your product and how it impacts your customers. If your potential customer decide that there are too many features you may have pushed yourself out of the initial niches  you were striving for. This will also mean you’re moving into a market space that will force you to compete head on with your competitors.

Using these three tools, questions for disruptions, lean canvas, and setbased concurrent design, will help speed the decision to continue pursuing a specific product, problem, and customer set. The point of this early process is to speed learning as quickly as possible and the B-M-L approach coupled with a set of Lean Cavnases and Products will help rapidly increase that knowledge set. Especially when using tools to help determine the trade-offs between your choices.

Finally, with continual engagement with your customers and products that are narrowing down towards a completed solution, you may find that your sets of products could become a family of products. This means that your learning may even be more valuable than before.

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.