Sogol Fathian

Category: Customer Development

  • What are the key ingredients for a long product life time?

    “What are the key ingredients for a long product life time?”

    A while back I was asked to answer the above questions as part of an expert roundup. The question has been stuck in my mind and I thought about it for a long time. Here is my take on the secrets of long-standing products:

    They keep evolving:

    While the underlying problem that make users look for a solution rarely changes, solutions provided for the problem changes all the time. In order to create a long-standing yet relevant product, teams needs to constantly provide new and innovative solutions to the core problem. Let me explain this concept a bit more:

    Let’s look at Netflix. For them the core underlying problem is to keep their users entertained through watching home movies but over time the solutions they came up to satisfy this need changed dramatically. They started out as a better solution to Blockbuster (remember the franchise that you would go to rent a movie?) with mail-in service but now they are in the business of video streaming. They also changed the type of home entertainment they offer. At the beginning they provided movies and paid back loyalties to movie producers but now they create their own films and movie series. So looking back at the 20-years old Netflix you can argue that they completely renovated itself across all their product offering and services while still addressing the same problem.

    Now let’s take a look at another product. You might have heard of Basecamp, a project management and team collaboration software that has been around for at least 15 years. The company is one of the most successful small businesses in US and their software is wildly popular. What have they done to stay relevant? Turns out every couple of years they go through and build a complete new product!!! and I am not talking about just a visual redesign, but a whole new product rebuilt from the ground up. Even though the product solve the same old problems, but it does so in easier and more modern ways to deliver more value to the user. As far as I know they have gone through two major rebuilds. If you want to know more about their reasoning watch this talk. Another interesting fact is with each major upgrade they didn’t forced customer to move to the newer version. The customers have a choice to stay on the older product or to upgrade to the new one.

    They keep users move forward

    I have written about this previously when I reviewed ‘Badass’ book but one of the fundamental things makes the user repeatedly come back is that if the product helps them build skills and keep them moving forward along the path of expertise. This one is subtly different in that these type of products are more complicated and required continuous users effort. For example if you dig deep into why photographers keep using Photoshop is that post-processing images is considered a valuable skills that separates amateur photographs from professional ones. Photoshop is ‘the’ tool for editing digital images and it can be as small as correcting colors or as complicated as removing a forefront object from a busy background. Although photoshop has a reputation for being complex because it supports a photographers journey from beginner to advance user keep coming back for more.

    What are the other traits of long lasting products that I am missing? Share your thoughts in the comments.

  • Build Your Product Strategy using this Blueprint

    Build Your Product Strategy using this Blueprint

    If you want to switch from waterfall and are new to agile there are many resources and blueprints available to get started and to tell you what to do next. There are courses to take and books to read and experienced people to learn from on how to build, test and ship software in iterative and continuous way.

    But what about all the activities that we do to decide what to build? Is there a blueprint we can follow on what to do next so we can make informed decisions on what to build? If you are like me, you have come across all different methodologies like Design Sprint, Jobs To Be Done, Lean Startup, Customer Development and Design Thinking over time and the question is, how do we know if these tools are helping us, and how do we know what to use when? How do I decide which ones are right for my team?

    I came across a (long) blog post followed by a video of Teresa Torres that answered all the above questions. Take a look at the video:

    In Summary, her idea is to build a decision tree (she calls it Opportunity Solution Tree) to make sure that we have thought about different aspect of what to build. The root starts with finding what the clear desired outcome is. We need to define a qualitative objective, combined with quantitative key results, so that we can measure if we are getting closer to our desired outcome. Next comes as identifying opportunities (which is the fancier word for problems and pain points you want to build solution for) and only after these two levels are clearly defined you can compare and categorize solutions and ideas to see if they tie back to the making better outcome.

    The great thing about Opportunity Solution Tree is that it gives you the blueprint I was craving earlier. This means there is a systematic way to use different methodologies at each levels to identify the problems/opportunities, solutions and validate if the proposed solutions will work. This is helpful to me because it it helps me to identify which method to pick. Take a look at this diagram here. In a glance I can now see Jobs-To-Be-Done more focuses at defining the problem but tools like design sprint talks more how to build the solution.

    One final note is like Agile concepts, I think this mapping concept is easy to understand but hard to implement. I am trying this at work right now I will let you know how things go!

  • Book Review: Badass – Making Users Awesome

    As you can see from my resource page, I am a huge fan of Kathy Sierra, so as soon as I learned she has written a new book I grabbed a copy and I was blown away. Kathy uses her distinctive style of using people with bubble talks to breakdown and explain complex stuff in easily understandable and fun way. However don’t be fooled that with all the white space, pictures and bubble speeches the book is easy or a fluff. Instead it is packed with lots of material on cognitive science and leaves you with many ideas on viewing your product in a totally different way.

    Making Users Awesome compromise of two different sections. 1. what is the reason that we use one particular product or service over other similar choices and 2. how we build skills over time and what are the ways we can accelerate learning skills over a short period of time.

    On part 1 the book’s main argument is that people pick a tool or service over others when they trust the recommendations they get about that particular product or service. When a friend or a family member talks to us about a recent app or a product they have used or when we pour over guests testimonial on Airbnb, we are likely to pick products, apps and hosts based on these reviews over what a particular brands is portraying. Why do we trust friends or even strangers over the brands in choosing something?

    The surprising answer comes from the fact that no one uses an app or a service because they really want to get good at using it; instead we use the app or services to be good at whatever real-world domain this software works with. We choose a recommended app or service when see someone else is making progress and becoming better at our desired real-world domain. Our desired real-world domain can be anything, it can be experiencing a city like a local or becoming a front-end web developer.

    The second part of the book looks at how people learn skills, the nature of expertise and how one can learn skills in a short span of time. One big take away for me was that, when we start learning something we try to take in everything and we are told that “Practice makes Perfect” so repeating and reviewing what we have learned so far will make us better. However the book shows us that we have only mastered a skill if we can achieve 95% reliability in repeating the task within 1-3 45-90 minute sessions.

    If we can’t achieve this then the typical reaction is to repeat the exercise all over again. However we should realize that if we can’t do the skill it’s probably because there’s a small sub skill that we need to master first. So our next step is to break this skill down into its components, master those and then try the original skill again. She calls this principle “Half-a-Skill betas Half-Assed skills” ! 🙂

    The book has so many other interesting takeaways and concepts that I didn’t cover to it so go read that book. Seriously. It’s badass itself!!

  • What job are customers hiring your product for?

    If you noticed I used the framework of Jobs T0 Be Done in my previous post when I tried to compare multiple email marketing solutions with each other. Asking “What job are you hiring this product for?” is an odd question and it took me some time to wrap my head around thinking about a product like it’s a person or service I can hire. This is an essence of Jobs To Be Done framework but when I talk to people not many know about it. So I researched multiple articles and listened to a couple of podcasts to learn more about it. Without further ado here is what I’ve learned:

    What is Jobs To Be Done and where does it come from?

    If you search Jobs-to-be-Done, you’ll find this video from Clay Christensen, a famous Harvard Business School professor who came up with the framework. (He’s also the guy who came up with the idea of Disruptive Innovation in his seminal book the The Innovator’s Dilemma). Anyway, Clay speaks about a product development issue in a fast food chain where they wanted to sell more milkshakes.

    Their initial approach was to talk to buyers and make changes to milkshake based on this customer analysis. They asked buyers if they like their milkshakes be healthier or more sugary, thicker or thinner etc. This failed. They sold no extra milkshakes, as there was no meaningful insight to be found in analyzing the users themselves. So he suggested that they focus on the job that customers hire a milkshake to do.

    It certainly sounds weird (no-one thinks of “hiring a milkshake”) but switching to that perspective offered new insights. After talking to buyers in this new format, it turns out more than half of the milkshakes are hired to do the job of providing sustenance and entertainment for a long commute. In this regard milkshakes were competing with bagels, bananas, and energy bars. Milkshakes had advantages over energy bars and bananas, as they’re tidier and easier to consume in a car. They beats bagels because bagels are too dry and leave you thirsty in your car. They beats coffee because they are more filling and less likely to don’t leave you desperate for a bathroom in the midst of a 40 minute drive. Once the chain realized this, they were able to make changes that made milkshakes the best tool for the job.

    When using Personas are helpful

    Similar to the restaurant chain example above product designer, product manager and UX/UI  team try to talk to users to understand what they’re looking to get out of  software. They come up with user personas and user roles.  Once personas are defined, then they try to design and define a system in a way to deliver users’ needs and wants as a series of user stories.

    Personas work well when the user base is broken down into different types of users with different needs. For example, if trying to create a market place it is helpful to define distinctive types of personas based on buyers and sellers roles. These personas are definitely helpful to define what your system must fulfill for each of them.

    When Personas are not useful, focus on the Job instead

    However for many products (and I’m thinking many B2C type of software) the customers come in all shapes and sizes, from all countries, all backgrounds, all salaries, all levels of computer skills. In these circumstances defining persona is not as useful as there is no way to group your users into meaningful roles to define a system for.

    Another time when focusing on the job is more helpful is when a situation dictates the solution as oppose to your user’s characteristics or attribute.

    For example, after a long day of work and with an empty fridge, Alan who is single and in his early 30s is looking for a comfort food with minimal prep time and dish washing afterwards. That when he orders Pizza! However the same Alan on Friday night when he has a date  in order to impress his date, he’ll go to a fancy Italian restaurant.

    In both cases the situation and the problem context dictated the solution as oppose to Allan’s attributes of being ‘single’ or ‘in his 30s’.

    Jobs-To-Be-Done framework becomes very useful because the product is better defined by the job they do than the personas it serves. Now it’s best to get an intimate understanding of the job itself, what creates demand for it, and what ultimately what you’d hire to do the job.

    Another cool example that I’m going to borrow from Intercom blog is when you hire a photo app:

    When do you hire a web app?

    There are a few different jobs you might like to do once you’ve taken a photograph. Here’s six:

    1. Capture this moment privately for me and her, so we can (hopefully) look back on it fondly in years to come
    2. Embarrass my friend in front of her friends, cause she’ll regret this in the morning.
    3. Get this file backed up online, so I can point others to it.
    4. Get a copy of this photo to my grandmother who doesn’t use computers.
    5. Make this look cool and interesting. Like me. And then share it.
    6. Get this edited and into my portfolio so that people consider hiring me for future engagements.

    In this case the products you could hire are Facebook, Flickr, iPhoto, Instagram, maybe 500px. When you think about how many of these apps you use, you realize that the job is the distinction here, not you. You haven’t changed.

    Jobs-To-Be-Done Interview and Job Stories

    To understand “the job” you have to interview users to understand their struggles, alternative solutions to the job and finally what made them purchase your product to solve the job. (There is a Jobs-To-Be-Done interview course  teaching interview techniques). As a product manager you act as a detector! your mission is to find out:

    • what situation the users were in when they encountered the job?
    • what caused them to take the action ?
    • What steps they took to come to the conclusion to hire your products?
    • What are other solutions (software or not) that are competing with the solution you offer?

    For the reasons outlined above, Alan Klement goes as far as suggestion to use Job Stories instead of User Stories.

    There is so much for to learn about this framework and I find it fascinating. One final thing I learned is that there are no new jobs! Jobs don’t change but the solution that’s satisfy the job changes over time. What do you think?

    Resources

    Finally if you are interested to learn more about this let me know, I know a great knowledgeable person  in GTA and we have a meetup to chat JTBD if there is enough interests 🙂

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