In a past podcast with Ron Mascitelli, president of Technology Perspectives, we discussed exchanging the use of stage gates in design to what Ron and I both like to call Knowledge gates. I asked Ron, Do these happen at phase gates or control points of the process?
Ron: Actually, in my perfect vision of the world, the events become the phases and gates. Our market requirement event is a knowledge gate, so is our project planning event. The rapid learning cycle event, which is to burn down your early risk on a project, each of these, in a sense, are knowledge gates. So in my perfect word, we don’t use artificial governance gates like concept freeze gate and a detail design freeze gate or whatever they might be. We actually use these events as knowledge gates. But in most companies that already have a comfortable language of governance, we just embed the event at the appropriate phase, and it will give you the outputs you need for your existing gate reviews.
Related Transcript and Podcast: Lean Product Development with Mascitelli
Ron takes a further look into these knowledge gates further defining them as events. Even more toward liking.
Joe: Well, you seem to be event driven, and I don’t mean time-based necessarily, like a scrum sprint or anything, but could you explain what you mean by an event-driven process?
Ron: After a number of years of trying to find a way to package tools and methods that I knew were working within a framework, what I arrived at was basically, to be honest, I was inspired by going on jury duty with 11 other people that I didn’t know and didn’t particularly want to be with, in a hot-stinky room with stale donuts. Our goal in life was to reach a verdict. It occurred to me that the conversation and the consensus that was built in that room fairly quickly, were built because people had focus. They had no choice, essentially. They were going to be in that room until they got an outcome, and it was so much more fruitful that if we had, for example, tried to reach a verdict by sending each other emails and having an occasional conference call. I mean, in that environment, I think we’d still be waiting for the OJ verdict.
It, ultimately, inspired me. I said, "Well, why don’t we package a set of tools?" For example, defining market requirements. This can drift on for months in some companies, with the wrong people in the room or scope creep, or someone comes up with something, and we throw something else in.
I have a new thing called the market requirements event, in which we actually pull together for a day, focused day, with a set of tools, collaborative tools that the whole team can use, and we focus on just market requirements.
Again, it is a standard work event, but it’s flexible enough to scale to the needs of the project. The outcome is a prioritized list of engineering design requirements, the scope of work to move forward in the project. And the other events, of course, hit at critical points within the process.
We’re not doing all the design work in an event. What we are doing, however, is those critical collaborative junctures. In a sense, this is a forcing function for fruitful collaboration.
Joe: That’s an interesting take on it, because it’s not necessarily a Kaizen event? What is it called?
Ron: No. Other than the fact Kaizen events are a great example of how powerful this kind of intensive collaboration with the high focus can be. But it’s not a Kaizen event in the classical sense of being continuous improvement. It is an execution event, where you have, again, a standard preparation in advance. Everyone, within their role, comes to this very cross functional event with preparation, information, and in some cases work done. When we get in the event, we follow an agenda of tools, discussion, and prioritization. Then ultimately, we have a standard output that determines the close of the event.
In fact, if we don’t close the event properly, if we don’t reach that outcome, we reconvene in a week or whenever we can, and we continue until we can reach that closure. I think it’s a very powerful forcing function for timely decision making and for really getting all the voices together, looking at the same issues and problems, and answering the same question.
Related Transcript and Podcast: Lean Product Development with Mascitelli
The above dialogue is an excellent analogy of progression that I have taken in working in sales and marketing. Instead of this progression through a funnel, I think more of an event and completion of a learning cycle or a knowledge gate. When a customer or prospect is within a certain, excuse the pun, stage, we evaluate our efforts through the behaviors exhibited by our customers. Are they ready for the next stage, the next learning cycle? Have we provided the proper tools, the increased knowledge needed? Have we increased our knowledge that both parties are prepared to create a stronger mutual relationship?
I think often we view taking a customer down a funnel. I view sales and marketing more in the process of increasing engagement. In one of my most popular blog post of all time, I describe this type of arrangement in The 7 step Lean Process of Marketing to Toyota. We start with a mutual understanding and climb with our customer to shared Kaizen and PDCA. In Lean terms, we become part of the way they do business, standard work. Once standard work is established we seek to mutually improve, Kaizen. It is not difficult to image but very difficult to do.
Lean Sales and Marketing: Learn about using CAP-Do