It is epitomized in the paradoxical Toyota proverb, "Stop production so that production never has to stop." The key to the andon cord is that it brings work to a stop as soon as an uncorrectable quality problem surfaces” which forces it to be investigated. This is one of the most important discoveries of the lean manufacturing movement: you cannot trade quality for time. If you are causing (or missing) quality problems now, the resulting defects will slow you down later. Defects cause a lot of rework, low morale, and customer complaints, all of which slow progress and eat away at valuable resources.

Therefore, shortcuts taken in product quality, design, or infrastructure today may wind up slowing a company down tomorrow.

Similarly, the more features we added to the product, the harder it became to add even more because of the risk that a new feature would interfere with an existing feature.

Taiichi Ohno gives the following example: When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. For example, suppose a machine stopped functioning: 1. Why did the machine stop? (There was an overload and the fuse blew.) 2. Why was there an overload? (The bearing was not sufficiently lubricated.) 3. Why was it not lubricated sufficiently? (The lubrication pump was not pumping sufficiently.) 4. Why was it not pumping sufficiently? (The shaft of the pump was worn and rattling.) 5. Why was the shaft worn out? (There was no strainer attached and metal scrap got in.) Repeating"why" five times, like this, can help uncover the root problem and correct it. If this procedure were not carried through, one might simply replace the fuse or the pump shaft. In that case, the problem would recur within a few months.

Read: Steve Blank's book The Four Steps to the Epiphany Read: The Entrepreneur's Guide to Customer Development Read: Single page apps in depth (a.k.a. Mixu' single page app book) (Mikito Takada) Highlights:

Good code comes from solving the same problem multiple times; or refactoring. Usually, this proceeds by noticing recurring patterns and replacing them with a mechanism that does the same thing in a consistent way - replacing a lot of "case-specific" code, which in fact was just there because we didn't see that a simpler mechanism could achieve the same thing.

We want to solve three problems: Privacy: we want more granular privacy than just global or local to the current closure. Avoid putting things in the global namespace just so that they can be accessed. We should be able to create packages that encompass multiple files and directories and be able to wrap full subsystems into a single closure.

Today's new code is tomorrows' legacy code; the best you can do is delay falling into the bad patterns.

Independent packages/modules. Keep different parts of an app separate: avoid global names and variables, make each part independently instantiable and testable.

Lars uses pretty similar methods as all tech guys I guess. Because you have systematic way of dealing with things, you'll manage tasks well. Of course in the case you don't add too many tasks to the queue. My personal challenge is not managing things I need to do. My personal challenge is to decide at very early stage which things I'm not going to do and which things I'm going to complete. It's totally useless to start 10000 things and finish only a few. You'll end up wasting a lot of resources. Based on my experience, this is way too common problem in many companies. Things are done, using resources, but never finished, and therefore won't ever provide any benefits or in worst case, cause just a ton of trouble. This is why I love Kanban cards very much, because it makes it clear, you just can't add things to do endlessly, you simply have to focus on essential.

Read: HFT (Brogaard Jonathan)

Read: Innovator's Dilemma (Clayton Christensen)

Highlights:

Introduction This book is about the failure of companies to stay atop their industries when they confront certain types of market and technological change.

It is about well-managed companies that have their competitive antennae up, listen astutely to their customers, invest aggressively in new technologies, and yet still lose market dominance.

Products based on disruptive technologies are typically cheaper, simpler, smaller, and, frequently, more convenient to use.

Taken in sum, these chapters present a theoretically strong, broadly valid, and managerially practical framework for understanding disruptive technologies and how they have precipitated the fall from industry leadership of some of history’s best-managed companies.

Companies find it very difficult to invest adequate resources in disruptive technologies—lower-margin opportunities that their customers don’t want—until their customers want them. And by then it is too late.

The fear of cannibalizing sales of existing products is often cited as a reason why established firms delay the introduction of new technologies.

But the problem established firms seem unable to confront successfully is that of downward vision and mobility, in terms of the trajectory map. Finding new applications and markets for these new products seems to be a capability that each of these firms exhibited once, upon entry, and then apparently lost. It was as if the leading firms were held captive by their customers, enabling attacking 34 entrant firms to topple the incumbent industry leaders each time a disruptive technology emerged.

The organizational structure viewpoint would predict that, unless they created organizationally independent groups to design flash products, established firms would stumble badly.

Disruptive innovations are complex because their value and application are uncertain, according to the criteria used by incumbent firms.

Read: Finnish Business Economy Book (Taxation, Legal requirements in Finland), very practical guide for (SMB) small business owners.

Read: What has worked in investing by Tweedy, Browne.

Own comments:

Absolutely excellent information with backing statistics.

My own comment about everything above...

Well, as far as I have seen, it's just like that. New, scary, unnecessary and "impossible" to make it work reliably, "who would like to use it anyway"?

Final comments, as experienced product manager, I didn't actually see anything new in these books about product development and product lifecycle. Only the HFT book contained a lot of good statistics and stuff I didn't have any kind of clue earlier.

Note: quotes might not be perfectly accurate due to charset, line feeds conversions etc and other text file type conversions, possible fat fingering during text processing etc. These quotes have been sitting in my "blog about" backlog for over two years.

Made with the new Google Sites, an effortless way to create beautiful sites.