Blog Archives

How to Design for Speed and Simplicity

Guest post from Bart Huthwaite

How to Design for Speed & Simplicity

Quick time-to-market comes from getting the small things right.  Here is a check list to follow:

  1. Smaller is better.  Keep your product team small, typically no more than 6-8 members.  And make sure all know the importance of product speed and are totally committed to it.  Communication is faster when fewer are involved.
  2. Get the “Big Picture” first.  Don’t start without a clear “end-in-view” and a strategy for getting there.  Build your strategy on the strategic values which will make your product or service a long term winner.  Your team members will be able to make decisions faster.  Strong “buy-in” to a team’s game plan encourages faster response time when crises arise.
  3. Work in parallel.   Parallel work compresses product launch time.  Constantly work to build confidence and trust, thus encouraging early understanding and commitment of these parallel teams.
  4. Avoid “sand bag” solutions.   Sand bag solutions are those which slow down a new product effort.  These can include specifying a new, untested manufacturing process, launching a product with an untrained sales force and implementing a new CAD system the same time you are developing a new product effort.  These kinds of innovation are best done “off-line,”  and are only inserted into the product development cycle when they are fully proven.
  5. Create a “Team Efficiency Charter.”  Identify and agree on the characteristics of a highly efficient new product team.   Good product teams build standards of excellence and then adhere to them.
  6. Measure both product effectiveness and team efficiency in “real time.”  Product effectiveness is how well your product is attaining its goals.  Team efficiency is how well your team dynamics are working, such as the speed decision-making and follow-through.  Fast track product teams keep a stop watch record of everything.
  7. Think ahead.  Develop your product in three generations.  This helps your team anticipate the future.   I call this technique “step”, “stretch” and “leap.”  This helps you prepare for future shifts in technology, competition and marketplace changes.  This helps you avoid “re-inventing the wheel.”  Only insert new technology into your product when risk has been reduced to a minimum.
  8. Get management involved and committed at the early concept stage.  Management buy-in “up-front” reduces your team’s fear of failure.  Do this beginning at the early product concept stage.
  9. Be time driven.  Never start a meeting or a task without first setting a specific time to finish it.  And stick to your guns.  Avoid trying to get the entire job done in one sitting.  Shoot for 80% and then come back to the issue later.  Iteration is a hallmark of effective design teams.
  10.  Let us know how we can help.  LEAN Product Design is our passion. Contact us to learn about our onsite programs to help you.

Development problems and lean development

Development problems and making designs lean

Timothy Schipper

Early in my career, I was a product developer.   However, I quickly became disenchanted with the whole development process.  I loved the engineering part of the job, solving problems and finding solutions.  It was the lack of alignment, loop backs, and rework that discouraged me.   I found that the whole process lacked focus and that projects spawned huge amounts of rework.  Rework appeared in many forms – late design changes, added requirements, and a general lack of focus.  I found that development only address part of the value equation, and usually did not address the problem of anticipating manufacturing wastes and design inefficiencies.

My career took a few turns.   I left product development after a few years, working as an IT project manager and then as a manager.  It was during this period of time that I found lean methods.   I studied how lean was applied to manufacturing and also the office.   I found that the lean tools provided a framework for looking at problems, and working on root cause elimination.   The idea  of continuous improvement appealed to me as a way to move an organization to be more efficient.  Lean became my new passion.   Nearly 10 years and 120 workshops later, I had mastered the art of applying lean to the carpeted areas of the business.  It was during that journey that I discovered another application of lean.

Have you ever wondered if lean could be applied to the design world?  Could it be used as a method to design more efficiently?   Could it inform a product that was still on the drawing board, or should I say still in the CAD system?   It is clear that it could be applied after the fact, once products were designed and hit the factory floor.  Lean applied in manufacturing creates efficient value streams that run at a constant TAKT time with minimal inventory.  But what does lean look like when applied to design?

The discovery I made was that lean could be applied to design just as well as it has been applied to manufacturing.  Much of the language is the same, but the tactics are quite different.    About 5 years ago, I was introduced to the topic of designs that are lean at a Huthwaite Institute Summit.   It allowed me to synthesize my thinking and explore the world of design in a new way.  This proved to be a thinking model as well as a guide for individuals and teams on how to apply lean to their development process.   Thinking and reading Bart Huthwaite’s books inspired me to create LEAN products.both products and processes that are lean from the start.

The methods works well with teams who need to innovate quickly and speed development along.  It is unique in that it works on both the process of development and on the product that is being designed.   One of my favorite quotes is that for something to be lean it has to be lean from the start.  In other words, wastes have to be designed out for the system upfront.

I was inspired to write about how development could generate innovative products and lean process.  The book Innovative LEAN Development was one of the ways that I explored the idea of lean applied to development.  I co-authored the book with my colleague, Mark Swets.  It is our attempt to make a contribution to the knowledge base of lean development and design.

If you have been frustrated with the development experience as we were, then I encourage to investigate the lean development method.   We have witnessed many teams who successfully applied lean development to improve their process and the quality of their products.

If you find the idea of lean for development intriguing and would like to learn more, please respond and tell me your challenges and frustrations with the development process.  Let’s explore together how lean can remove your most difficult development gaps.  I only wish that I had found the lean method earlier in my career.

—– Tim

Lean Development: Spotting the Wrong Questions

“The uncreative mind can spot wrong answers, but it takes a creative mind to spot wrong questions.”

This quote came to me from John Maxwell. 

 It reminds me of why we are looking for Knowledge Gaps and writing A3’s in Lean Development.  Ultimately, we are just making sure that the right questions are being asked and spotting the wrong questions.  We are attempting to expose the things that we don’t know. 

 The exercise of writing Knowledge A3’s in Lean Development is meant to help us spot the wrong questions and in fact it goes a step further.  It helps us ask the right questions, and then it points us to think about who can help us get the answers to the questions.   This is what we do in the LOOK and ASK steps of LAMDA (the steps that Al Ward identified for Rapid Learning Cycles).   We LOOK for questions to ask and then we think about who we should ASK.  If we aren’t ASKing the “people at the ground” (a.k.a. People at the Keyboards, SMEs, Users, etc.) who will be using the program or innovation we are developing, then we are not going far enough.  In Innovative Lean Development, this is described in the PLAN step of the Rapid Learning Cycle.

 By starting with the problem statement, or as we sometimes have called it – the central question, we can stretch our minds to wonder if we have asked the right questions about different aspects of the program.

 A corollary to Maxwell’s statement would be “An uncreative mind asks the right question at the wrong  time, but a creative mind asks the right question at the right  time.”

 So – I am not at all surprised when we need to put an A3 on hold, or take one through the initiate phase and set it aside until later.   We are simply identifying that it is too early to ask the questions yet.  But, it is so important to at least identify the questions.

 And here is something else to think about … the more questions and A3 writing that we do up front, the more complete the solution will be in the end.


Timothy Schipper,

Author – Innovative Lean Development


Discovery – and Rapid Learning Cycles

What do you want to discover today?

Heuristic (pronounced /hjʉˈrɪstɨk/, from the Greek “Εὑρίσκω” for “find” or “discover”) is an adjective for experience-based techniques that help in problem solving, learning and discovery. Archimedes is said to have shouted “Heureka” (later converted to “Eureka”) after discovering the principle of displacement in his bath.  You might remember from physics that displacement is the principle that a floating object will displace its own weight in water.


Heuristics is the art of solving a problem in the best or most optimal way that is possible.  The optimal solution will be the most elegant one that is possible.  In nature, we find that the solutions have been created to be the most optimal, with nothing wasted.  The design of a plant is unique to its environment, taking in the right amount of light from the sun and nourishment from the soil.

When humans attempt to solve a knotty, or difficult, problem, we have to use a trial-and-error method.  We are limited, and do not take all the variables and parameters into account.

Enter Learning Cycles … Rapid Learning Cycles (RLCs) are a method of laying out the problem and approaching it with a series of rapid iterations of building, prototyping, and testing each one.

The best developers and inventors practice the art of RLCs. Thomas Edison reportedly tried something on the order of 3,000 materials for the filament of the electric lightbulb.

Or take the case of Charles Goodyear.  By the mid 1830s, it seemed as though the rubber industry in America was going under. The problem with the new material was that it was unstable – becoming completely solid and cracking in the winter, then melting into goo in the summer. Miraculously the industry was saved by inventor Charles Goodyear – a man with no knowledge of chemistry who worked stubbornly and tenaciously to develop vulcanized rubber.

After incidentally learning about rubber’s fatal flaw, Charles Goodyear became determined to invent a way to make the substance more stable. Without a steady job, he lived for years off of advancements from investors. When his experiments with rubber continually failed, Goodyear reduced his family to poverty, was jailed for debt and derided by society as a mad man.

Undeterred, inventor Charles Goodyear finally found that, by uniformly heating sulfur- and lead-fortified rubber at a relatively low temperature, he could render the rubber melt-proof and reliable. He patented the process in 1844, licensed it to manufacturers and was ultimately hailed as a genius.

Years after his death, when the age of automobiles dawned, two brothers from Ohio decided to name their company after the man who made their product possible – hence Goodyear tires were born.

So, discover something today using rapid learning cycles… and don’t be discouraged by the iterative nature of problem solving.


Source for Charles Good year story:

Learning Cycles and Design Thinking

I am reading Roger Martin‘s excellent book The Design of Business.  He talks about the need for companies to move through the knowledge funnel.  His knowledge funnel moves from

 mystery (asking what might be), to heuristic (discovery) and finally to algorithm (or repeatabili

ty).  Moving through the knowledge funnel requires the user to practice abductive reasoning, which is described as asking what “might be” as opposed to “what is”.

I found it very interesting that many of the same topics found in Roger Martin’s method also found their way into our book.  In Innovative Lean Development, Mark Swets and I talk about heuristic problem solving, and how to set up learning cycles to move from general ideas to something more concrete for the customer.   We showed our own learning cycle funnel.

Why is the concept of the funnel so important?  The concept is to have many ideas, or options, available to the team up front, and then weed them out.  The team will also refine requirements, moving from general ones to

more specific.   But, for the activity in the learning cycle, the team must have a structured way to create value and find the optimal solution.  Using learning cycle exposes the gaps in the product or solution space.  Learning cycles help to outline the questions and then focus the team’s direction in that ar

ea.  Learning cycles  become a tool to move from concept

s (mystery) through the other two phases of insight driven heuristics and algorithm .  The team can use learning cycles to expose the gaps in the problem, refining both the requirements and the product design.