Tag: lean

From the Introduction of The Counterinsurgency Field Manual

This publication can help compress the learning curve. It is a tool for planners, trainers and field commanders. Using it can help leaders begin the learning process sooner and built it on a larger knowledge base…

…Current tactics, techniques and procedures sometimes do not achieve the desired results. When that happens, successful leaders engage in a directed search for better ways to defeat the enemy. To win, the Army and Marine Corps must rapidly develop an institutional consensus on new doctrine, publish it, and carefully observe its impact on mission accomplishment.

This learning cycle should repeat continuously as US counterinsurgents seek to learn faster than the insurgent enemy.

The side that learns faster and adapts more rapidly wins.

The Future of the Toyota Production System


“What Akio Toyoda feared the company lost when it was growing so fast was the time to struggle and learn,” said Liker, who met with Toyoda in November. “He felt Toyota got big-company disease and was too busy getting product out.”

via ‘Gods’ edging out robots at Toyota facility | The Japan Times.

Seems like there are always lessons to be learned from Toyota – interesting to see a perspective about running a business that looks at the downside of speed, the downside of a product focus.

Live Chat and Lean Manufacturing



In the Toyota Production System (TPS) and its ongoing adherence in Western companies (usually called Lean, often mixed in with Six Sigma processes), one of the ways that we are able to reduce waste is moving from batch production to single piece flow, or continuous flow.

The opposing styles here are characterized like so: if Process Zoidberg requires you to perform actions A, B, and C, and you have to perform 100 Zoidbergs, batch production would suggest you do _all_ of your As, then _all_ of your Bs, then _all_ of your Cs. Continuous flow would suggest that you do A, then B, then C, one hundred times.

When we think about supporting a customer base, we can visualize each customer experience as a finished product, with each of their questions or friction points as a discrete component. We could extend this metaphor to the entire product development life cycle, but for the scope of this article, let’s focus on the post-launch product support, by (mostly) dedicated support staff.

Thinking of customer support using the well-trod ground of manufacturing, we can start to use insights that have already provided serious gains for other industries – it can also help us to explain data that we already have, or better understand or phrase our support for new experiments and learning opportunities.

When we consider traditional email support from the side of the customer, a customer sends in a request, they wait, the support staff replies, wait, customer replies again, with a new question or concern, they wait, and so on. If you asked the customer, it looks a lot like an (especially slow) continuous flow model.

From the side of the support staff, we see a different picture: they reply to customer requests as they come in, working with many customers at many different points in that particular customers’ process. Rather than working with one customer from the beginning, through all of their questions, to the conclusion, they move from question to question.

When we consider live chat support, it looks to be much more in line with the continuous flow model – as a customer arrives, they are picked up by a support team member, and they are moved through each of their questions in turn, to the point of completion.

It would be interesting to see some data on how these two processes look side-by-side, especially in terms of efficiency of production – which here would mean customer-questions-answered. I acknowledge that it might be tricky to suss out exactly when a question is answered, especially in an automated way. Tricky, but interesting.

My hunch would be that providing support in the continuous-flow model would gain similar efficiency gains to the adoption of that model in other industries, but, that’s just a hunch.

October Reading Goals Recap

I almost made it – I finished Microinteractions, Elements of UX and Lean UX. I am only about halfway through Gamestorming. I do have an excuse – I picked up and spent some time in the excellent Just Enough Research, part of the Book Apart family. So, I’ll call it a draw.

Here are my thoughts in the order I read the books;

Microinteractions: I was concerned that my lack of professional experience with UX topics would make this one a bit out of my reach, but to the contrary I found it really interesting, and it has certainly changed the way I think about the tiny pieces of software and websites, and the way these pieces change my experience. I would recommend it to anyone who works with websites or software, regardless of your area of focus.

Elements of UX: This book, while thoughtful and certainly full of really important and structural high level thinking, was not for me. I lack the necessary grounding and experience to get the full value. It was the same experience as reading the third of fourth book in a series independent from the others – I could tell I was not getting the full story, the full impact. So, I would certainly recommend it, but probably not good if you’re just dipping a toe into design and UX.

Lean UX: Probably my favorite of the books I finished in this list, Lean UX isn’t really about UX per se, but more about approaching that sort of Work from a different angle. As a step forward in management and product development, I liked it an awful lot. This may be because it ties into the sort of thing think about already, have some work experience with already, so the lessons and thoughts are especially tangible and pertinent.

Gamestorming: Despite only getting halfway, have already started using the games and thinking in this book – my team at Automattic will be putting together our annual roadmap in January, and we’ll be using some of the creativity building games to help approach the next year with open minds. Game storming is mostly a collection of brainstorm games, with a short explanation of how to use them – if you work with other humans to make things in any capacity, you would get a a lot out of this book.

While I failed to meet my book goal in October, I did meet my page number goal, so I feel inspired. I am going to only choose three books for November, including the rest of Just Enough Research. I have reached out to my colleagues Jeremey and Ian for recommendations – stay tuned!