Sogol Fathian

Category: Product Management

  • 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.

  • All resources I know about Product Management

    Product Management is still a relatively new field and each company depending on their product, culture and how they work have different job descriptions for a Product Manager. What are the key responsibilities of a PM and how can you build up skill sets required for the job? More importantly where to start?

    Whether you’re trying to become a product manager or you want to deepen your knowledge, there are so many resources out there to help you. When I started, I wanted a concrete understanding of PM role and to get a hang of all scattered resources over the internet.

    So I began searching, I read many blog posts and joined multiple PM groups on Linkedin and finally completed a very expensive Pragmatic Marketing course to get a feel for what PM is really all about. And when I was searching for books, articles, people on the topic I ended up with multiple recommendation for Pragmatic Marketing as a go-to training course for PM, Crossing the Chasm as “the” book for understanding concepts and people like Ken Norton and Marty Cagan’s SVPG blog as ultimate PM authorities. These are all great recommendations and definitely help but I find myself learning and relating a lot more when I find blogs of people learning out loud.

    Over time I’ve slowly built my own understanding and knowledge repository of what PM is, what skill set is needed and how to find answers and I want to share it with you. Take a look at Product Management Resource page. This page is going to be an ‘in-progress’ page and I will add to it as I learn.

    As I find more and more interesting things to read, learn and digest I keep reminding myself information overload is real and there is always more to learn and read than I have time to spend on butI’m not in a race I am here for the ride 🙂

  • Product Prioritization or how to be a curator

    I am reading the wonderful Rework. One topic that stands out for me is their emphasis on being selective on product features. They basically argue that building a good half product is much better than having a half-ass whole product. How true!! but what causes a product to end up being the latter and not the former? No one intentionally starts with the goal of building some thing mediocre.

    So what cause products to bloat?

    One of the best explanation I came across is a blog post called “Product Strategy Means Saying No”. It enlists the arguments product managers and executives use to add more features to the product. I myself am guilty of making “But our competitors already have it” argument without completely being able to justify why it’s important to have all those competitors features.

    If I would add one more argument to the list, it would be “Let’s hack this quickly NOW so we look cool then we’ll fix it later” and “Later” never comes. This is called “shiny object syndrome” but once the hacky feature looses its coolness and some other cool thing pops up suddenly no developer has the time and willingness to fix it. Users and customer support are forever stuck in a loop with this piece of crappy code.

    How to avoid building mediocre bloated products?

    If you’re building a new product, assuming that you have identified customer pain points start with the core one. What I mean is that the founder (which in my mind is really doing product management) must have a system to identify out of all identified pain points which one is most important one to address first. If the founder has experienced these pain points herself and has observed how users currently dealing with these paint points, it should not be difficult to figure out what is the most pressing issue to fix.

    Much has been said about “Lean” methodology but in my mind it all comes down to figuring out the burning problem and build core functionality to address that problem only. This will be the product’s epicenter and as the product is being used by customer it will grow and evolve. But this approach create the main building blocks that ultimately create an awesome half product that solves one problem and does it very well!

    What about mature products that have been around for a while? The ones that still provide value to the user but they’ve been so diluted that it’s hard to pin point its usefulness. I’ll talk about that feature audit and prioritization methods to fix these type of products in the next post

  • Why do you need to be a hands-on Product Manager?

    Product Management is a hybrid role and depending on where you work, your list of responsibilities vary. You need to have different skill-set to be able to build a product that is valuable, usable and feasible. Also, product manager responsibilities comes from working with multiple teams and within the frame-work of product development. So it’s hard to showcase product manager abilities in a stand alone context. What I mean by that is, a software developer has working code and a designer has portfolio to show for but what is a concrete output of a Product Manager?

    This is why it’s so important to be a hands-on in multiple aspects of the job, not only to demonstrate your skills in a practical way but able to remove roadblock you encounter effectively and efficiently.

    If you are working in Information Technology like I do, your day-to-day responsibilities change depending on which phase of software development life cycle you’re at. In early phase of software development life cycle you need to work effectively with multiple stakeholders but in order to do that you need to be 1) knowledgeable about product/market fit 2) opinionated about what needs to be built 3) be able to justify your opinion.

    If you are working with developers you need to speak their language and be able to understand what they’re saying and what are the implications of their proposal’s for the product will be. Are you able to understand and verify what is said? The same is true when you’re working with designers. When I first started, I worked with a designer who would get on implementing her ideas and I always justified that approach by thinking she’s the expert in her field and I should trust that judgment. I didn’t know about principles of user experience design nor did I about the importance of building customer persona before jumping right in to designing stuff. Now at least I can have an effective  discussion with UI/UX designer and ask questions on why the interface needs to be the way s/he emphasizes to be.

    When time is short and you need to get a product released in a tight deadline, there are so many little things to do. It’s so much more efficient to take on these tasks and free up experts (designers, developers) time to do the heavy lifting. Can you jump in as the copy-writer to change that campaign copy for the last time before it goes out, do you have some Photoshop skills tweak the layout, and write the code for the script to get the data you really want but Business Intelligence team doesn’t have time to do it now?

    All this hands-on experience becomes invaluable if you want to build your own business.  Do you have what it takes to get to that first MVP?