For years I’ve been preaching about “knowing thy customer” – it’s something that I’m pretty fanatical about. It started, ironically, when I was working with the military early in my career. I realized even then that success wasn’t a factor of how great my code looked, or how amazingly designed my solutions were. I’ve been on a LOT of projects over the past 20 years – some of them went horribly wrong (depending on who you ask) – and some of them went amazingly well. How did I know if a project went well? Was it that the project finished on time? Was a project successful if my estimates were accurate? Was it successful if my team was happy and no one worked overtime and everyone came to work in sandals and sang songs at lunch? Na… none of these things made sense. The ones that I felt were successful were the ones that truly provided value and dramatic change to my customers. Hearing things like “I love this” or “this will change everything.. I’m soo happy” – well, that makes all of the hard work pay off. Even better were the customers who came up to me years later and said “we’re still running the app.. and still loving it”.
Hearing customer praise felt great. I had a hidden shame, however, sometimes my projects were successful by accident – and I needed to figure out why. I desperately wanted them to be successful – on purpose.
I’ve always been passionate about requirements and requirements management. At one time, I thought that this was the very key to the universe… I was almost right. I invested sooo much time into learning and mastering things like UML, and Rational Rose (so that I can make pretty diagrams and post them all over my cubicles), and researching all the different ways to capture user requirements that I can use to base my software off of. I worked on huge projects that had 100’s of “Use case documents” that flushed out every detail of how the software should work. I must say, my use case diagrams were .. well, perfect. I made sure that my activity diagrams, class diagrams, and component diagrams had no equal. I was master of my domain. King of specification. How can I not produce perfect software after doing such a good job engineering the requirements?
Guess what.. even after I mastered the black art of “Requirements Engineering” I was still unable to see that delight in my customer’s eyes. I pour my soul into learning how to represent requirements. I found out two painful things as a result.. first, no one consumed my art (er.. specifications) – validation couldn’t really be done by end users.. and, my specifications were as complicated as the code that was to satisfy them. My projects were no more successful than they used to be. Hmm…
Well, about this time I started to realize that those projects that I considered successful had one key element – I deeply empathized with my customer as a result of my deep understanding of them and their needs – mostly driven by my constant, consistent, and incremental collaboration with them. Yes yes yes.. I know.. I’m not the first to realize this.. eXtreme Programming and later, the Agile Manifesto were big parts of this epiphany.
Guess what though.. Agile wasn’t the first to figure this out 😉
As I mentioned above, focusing on requirements was “almost right” – more importantly, one must focus on the problem and deeply “know thy customer.” Genchi Genbutsu is a term used a lot in the world of Lean. It means “go and see” and it is a key principle of the Toyota Production System. It suggests that in order to truly understand a situation one needs to go to ‘gemba’ or, the ‘real place’ – where work is done.
The key is to minimize and validate your assumptions – especially when it comes to customer value and the problems that they are trying to solve. I can’t tell you how simple this sounds, yet how amazingly complex it still can be. How, for example, do you communicate your knowledge – propagate it across your team. Is it possible to send your entire team to Genchi Genbutsu? What if you have 1000’s of customer? How can this information resonate with the rest of the team? How do you continually refine and update your knowledge? These are tougher problems that you might think.
They key is to find many ways to “get out of the building” (a blatant reference to Steve Blank from his book the Four Steps the Epiphany). You can use tools such as the TeamPulse Idea and Feedback Portal to help reach your customers. You can use conferences where groups of your customers may congregate to get a deeper understanding of their needs. You can of course, literally, go and sit with your customers… they key mindset to have is to “gather” or “validate” knowledge – not to sell your solution.
Of course, this is only a small fraction of what it takes to have a successful project, or new business startup. It’s really gratifying to see the same thing happen 10 years ago with Agile now happen around Lean thinking. Before we called it “Agile” – many of us were already doing “agile” for the same reasons. Seeing “Agile” put together and the resulting offshoots was like smacking yourself in the head.. yet, somewhat gratifying since many of us came to the same conclusions differently. The same is happening around Lean – as it applies to IT and to business. Absolutely not rocket science or even new (was “Agile” ?).. yet, it’s all the rage with the cool kids.
Expect to see more and more pieces from Lean applied to the world of software and IT startups. We’re already seeing Kanban steamroll through Agile teams. For example, I predict we’re going to see something similar to Lean’s Quality Function Deployment to help us with prioritization of that customer value we struggle to understand and capture – an old, yet proven set of techniques I’m sure we could gain tremendous value from. And of course the immense popularity of Lean Startup models are proving themselves again and again.
Once again, stop guessing and assuming.. start learning and measuring. Start thinking Lean… and for crying out loud… GENCHI GENBUTSU already!
