Category: Lean

  • Lean Customer Development: A Book Review

    leanCustDev

    I’ve mentioned in my Resource page that I’m reading Lean Customer Development by Cindy Alvarez. It took me a while to finish it but I’m happy I did. In Product Management blogosphere and community you constantly hear about the importance of getting out of building, listening to customers, thinking about ideas in an “outside-in” fashion (where focus is on creating products/solution based on customer as oppose to “inside-out” way of creating product solutions from within the company) and having voice of customers understood during software lifecycle development.

    Rightly so, many people think the single most important responsibility of a good product manager is to bring insights about customer’s needs and wants to the company and be able to get the development group to act upon them. I agree with all these but up to now I’ve had a hard time connecting directly with customers. I found it intimidating to reach out to our existing customers and potential prospects. What am I going to ask them? what if I send the wrong impression? how should I conduct an interview and finally how to interpret my answers and share it with other team members? This book not only laid out the foundation of how to approach the customer development but also provided me with a step-by-step practical list of how to get started! How fantastic!

    Here are what I learned and some feedbacks I have on this book:

    Customer development is meant be done parallel to product development. It is about systematically testing your hypothesis (guesses) around existing problems and potential solutions by asking customers to validate them. As a result you will learn what customers really want, and what are the key solutions they’re willing to pay for them. To me it’s obvious why customer development is important because if you don’t know what customers really want, you end up building something that no one wants to buy/use. I have seen this over and over and it still amazes me how often companies invest in resources and time to build a product only to sunset it after a few months. As a product manager having solid experience on talking with customers and brining their insights to the company is one of the key skill sets.

    The process like many other scientific experiments are two fold. First you need to set up experiments by identifying assumptions and writing problem hypothesis then you go about validating (or invalidating) them. In order to do so you need to find “target customers”, plan the interview, ask questions, make observations and take notes. This book goes over each of these topics in great detail.

    Cindy explains how to overcome fear of rejection of people not wanting to talk and offers tips on how to get introduced to new people through your direct connections and/or social media (LinkedIn, and Quora). It covers administrative stuff such as scheduling, no-shows and all those little details that make or break the whole process like making sure email copy is concise enough to be able to read and reply back within seconds over a mobile phone. But the most important part is what questions to ask and what not to asks. I learned that  the main objective is to get customers talking and provide answers specific to their situation to learn as much as possible. Questions like “Tell me about how you do _________ today….” or “Do you use any [tools/products/apps/tricks] to help you get ________ done?” are best because they’re open ended and rely on past experience. Yes/No questions and questions that imply an answer within them (leading questions) are not as helpful.

    The book covers other aspects of customer development including tips on note taking, validating/invalidating hypothesis and sharing your discoveries with the team. Overall I enjoyed the book very much and I’ll keep going back to it for more how-to on my next round of talking to customers. The only thing I didn’t understand was the emphasis to call this book “Lean”. Sure, I understand that by  invalidating hypothesis around what customer’s going to use, we’re saving a lot of time and development not building features no one uses (eliminating waste–> Lean) but I see customer development as an integral part of product manager job in both startup and big corporations alike and therefore maybe I would just call it “A manual for Customer Development” 🙂

    Cindy also writes in her blog in the same approachable easy way about customer development and other areas of product management as well. Check her out!

  • The Toyota Way and its effect on Software Development

    Lean-Agile-Elephant

    Lean, Kanban, Agile, Scrum and Kaizen: You have heard them all before, you kinda know their core concepts but still wondering about what each of these concepts exactly do. What is Lean? How does Lean differentiate from Agile? What’s the difference between Agile and Scrum? Is Product Manager same as the Product Owner? What does Kanban have to do with Kaizen? Last but not least where do all these terms and concepts come from?

    I confess these concepts confuse me as well and I don’t know the answer to all of them (although I’m sure they all have been answered) but as I did some reading and now I can address the last two questions.

    The short answer is: Toyota! yes the big, giant Japanese car manufacturer. But how did automotive industry and in particular Toyota impacted Software Development Life Cycle so much?

    According to wikipedia, The Toyota Way is a set of principles categorized as: (1) long-term philosophy, (2) the right process will produce the right results, (3) add value to the organization by developing your people, and (4) continuously solving root problems drives organizational learning. Most people associate the Toyota Way or Toyota Product System (TPS) as a way to eliminate waste however continuous improvement (Kaizen) is another important goal. TPS has helped Toyota become the most valued car for drivers all around the world and a leader in automotive and manufacturing industry.

    Toyota success in reducing wastes (time, money, labour), getting faster results and continued improvement made it an attractive option to implement TPS techniques into Software Development  Life Cycle (SDLC). The result is Lean Software Development, Kanban and Kaizen. Let’s go through them each.

    Lean Software Development

    Lean methodology preaches many of same principles of TPS also known as Lean Manufacturing (confusing? I know!). Here are the 7 main principles: 1. Eliminate waste 2. Amplify learning 3. Decide as late as possible 4. Deliver as fast as possible 5. Empower the team 6. Build quality in 7. See the whole. For Software development these principles have translated into the following loop:

    Lean-Startup

    The whole idea is to validate hypothesis (ideas, products) as quickly as possible, and increase our understanding of what works and what doesn’t (product-market fit) before spending time, money and engineering resources to build some thing full fledge that no body wants to buys (high risk) . The MVP or Minimum Viable Product means putting minimum investment of time and effort to learn some and Viable means that the product is providing enough experience that shows value to your customer. The goal of an MVP is to maximize learning while minimizing risk and investment. The aim should be to validate the hypotheses and assumptions

    No team can get this right just by going through this once therefore we have the concepts of Kaizen (or Continuous Improvement). It’s a process to teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.

    There is a lot of shared belief between Agile and Lean but what about their differences?  I took to Quora to find the answer and I found the answer given by Nick Coronges very sensible:

    “Lean is a predecessor of Agile, with some of the core concepts of Lean being incorporated into Agile. But one of the tenets of Lean that Agile elaborates on in a significant way is to focus on the delivery in the service of known needs in the present rather than needs forecast in the future…. In Lean, the idea is encapsulated in “Pull” processing you build what the system tells you in needs right now. In Agile you build software in short iterations, each delivering some immediate business value. After each iteration, you take new bearings, plan your next “sprint” and charge forward. Both of them see elaborate design and planning activities in advance as wasteful and misleading”

    Although I have worked with Agile team in the past I’m still learning. I have so far read Cindy Alvarez excellent book on Lean Customer Development (more on that later) and now I’m about to start Ash Muraya Running Lean.