Sogol Fathian

Category: Software development

  • Review of “Shape Up” book

    I enjoy reading books over blog posts and tweets because they provide more context and they can also go deeper. I recently finished reading “Shape Up” written by Ryan Singer. The book is available for free on Base Camp website and it definitely worth a read. Here is my take on it:

    What is Shaping Up and why does it matter?

    The book argues there is a Goldilocks state for defining requirement in a way that defined work is neither too vague nor too concrete. The idea is to provide the team (1-2 developers and a designer) enough context about the project’s goal and clear layout of the scope and constraints but allow them to define the nitty-gritty details themselves. I strongly agree with this approach as I made both above mistakes.

    Having too vague of a requirement (“This page should be easy to use”) leaves the team guessing on what the PM really wants. They either constantly interrupt their work for further clarification or they may build based on their own assumption. Either way the end result is either something that took much longer that it needed to or worse an application that is totally different from the PM expectation.

    The other extreme where the requirement has all the details (“Here is the exact designs for registration page”) brings its own risks. The biggest one is to create an illusion that PM knows all the answers and the team has no say in figuring out the direction of the product. The team job is only to follow strict set of instructions to get to the final product. If user experience or the flow doesn’t make sense then it’s on Product who should have should have figured it out sooner. This approach takes away the joy of collaboration, leaves the PM anxious about guessing everything upfront and the team powerless in coming up with solution.

    What I learned & loved about Shape Up

    The first part of the book talks about the characteristics of a shaped up work and how one should go about creating such work. The first thing is that the work should be completed and shipped within 6 weeks. I learned there are four main steps to follow: 1) Setting Boundaries which focuses on defining the problem 2) Rough out the elements is about sketching a solution without specifying too many details 3) Address risks and rabbit holes finds unanswered questions in the proposed solution to de-risk it and finally 4) writing the pitch is simply creating a document where all the above is laid out so that the team can understand them.

    What could have been better

    In summary Shape Up specially it’s first part is a must read for every product managers whereas other parts are less in control of the PM. For example, the book talks about the concept of circuit breaker (abandoning a project which has run through its 6-weeks cycle but it’s not completed) but that truly depends on leadership willingness to pull the plug and enforce that deadlines are firm. I haven’t seen that happening much in my experience and it’s not something that PMs can enforce by themselves.

    Another issue I haves is that the book comes us with some new catch phrases like “six week cycle”, “cool down period” and “betting table” but I’m vary of coming up with new hypes and new names. These terms tend to take a life of their own as the spread to other companies and turn into something quite different. I’ve seen this with concept like MVP, sprint, JTBD and my concern is that they will have the same fate.

    Overall though it’s one of the best free books out there that really teaches you something 🙂

  • 5 Tips to Balance Tech Debt vs Feature work

    As a product manager you lead your team’s and prioritize their work. One common challenge is to decide between spending time to improve current software versus releasing net new features. Improving current software sometimes also known as Technical Debt takes many forms: code can be refactored to be simpler, it can be optimized to run faster, it can have better test coverage for fewer bugs and so on.

    On the other hand you as a product manager represent business and users who want new features within the software application to solve their problems. Net new or add-ons to existing features can be many things: new functionality, better user interface, new routes and APIs and so on. So how do you balance between the two?

    Here are the five tips I’ve learnt so far to balance the two:

    Make the outcome clear and obvious

    One problem I often encounter is tech debt stories written by engineering that are full of low level details. Just like any other story type highlighting the benefit or outcome is important.

    The value of fixing CI/CD pipeline issues or optimizing data access might be obvious to engineering team but without clearly outlining the benefit to none technical folks understanding their value and therefore getting them prioritized is more difficult. Delivering value takes many forms; if not upgrading to latest framework slows a team from adding new feature to the software or not fixing pipeline issues makes deployment a complicated and error prone project by itself then the value of doing all these tech debts are unblocking the team add new feature to the software quickly and efficiently. Stating this value upfront makes it easier to prioritize tech debt compared to other stories.

    Fix small items on the go

    One way to address smaller tech debt items are to fix them as part of building add-on features. By add-on features I mean new features built over some existing foundation. If the foundation needs improvement and it can be broken down into smaller tasks then some of those tasks can be tackled as part of building add-on feature without inflating it much. Breaking up what needs to be done and deciding to do it as part of a new feature vs a stand alone item needs expertise and for this I defer to the opinion of skilled developers and technical engineer leads that I know of.

    Allow dedicated time for bigger items

    If tech debt item is big enough that cannot be pegged to another story it is best to acknowledge it as such and allow clean up time before another project or a new milestone starts. Just like when one dish is done you allow time to clean up work surfaces and equipment in the kitchen before you start a new one. You can’t not make things dirty when you cook, but if you don’t clean things quickly, muck dries up, is harder to remove, and all the dirty stuff gets in the way of cooking the next dish.

    One rule of thumb is to allow one week or even one sprint of dedicated tech debt work per every 4 to 5 sprint of feature work for a week. I’ve also seen ‘fix-it’ days equivalent to hackathon days that instead of building things quickly teams within the company focus on fixing items annoying them where they haven’t had time to fix them.

    Document what’s fixed & list what needs fixing

    Documentation is one of the most unappreciated and neglected part of software delivery and misinterpretation of Agile value of “working software over comprehensive documentation” hasn’t helped its cause. Having a central place to show what’s been fixed and a link to remaining list can quickly subside the confusion and worry about the amount of tech debt. This is something that needs commitment from engineers however developers usually don’t do a good job about this.

    It’s an ongoing process

    Like everyone else customers like the progress of new and improved software that makes their life easier and spending months to clear big tech debt and improve foundational items is hard to justify. That’s why balancing between feature work and tech debt is an ongoing process that can’t be done once and then set aside. There needs to be constant communication between product manager and the team on how to manage to avoid accumulation of too much tech debt to cripple development of future features.

    Addressing tech debt doesn’t need to be a conflict point and a blame game of “you (product manager) won’t let us write good quality code because it takes too long” when it can be positioned as enabler of faster and better software development and delivered as a continuous part of software delivery.

  • Interested in Product Management Podcasts? These are a few of my favorite

    Interested in Product Management Podcasts? These are a few of my favorite

    It is hard to believe that 5 months has gone by and I haven’t written anything in this blog throughout 2018! For the past 9 months while driving to and from work so I had a chance to listen to many interesting product-related podcasts which I want to share with you.

    Product to Product

    is podcast from Toronto-based Roadmunk. I am impressed with their choice of guests, quality of the discussion and their current theme which for season 2 is the human-side of product. Favorite episode: How to think like a Product Manager I have always been a fan of Melissa Perry’s insightful approach on product managers topic but my main takeaway was this:

    “… What I want product managers to understand is it’s not a linear process. You may never start in the same place, depending on where you are… stop and think about what they know and what they don’t know. ”

    Nir & Far

    In this podcast, Nir Eyal mostly reads his previously written articles from a namesake blog. This is a nice deviation from a discussion/interview style of other podcasts. Favorite episode: Unexpected benefits of distraction when it is always portrayed as something to avoid based on this article:

    “…Using distractions with an expansive mindset builds strength, while using them with a suppressive one simply shields us from the pain we are avoiding.”

    Yours Productly

    recommended by a colleague to me this low-key podcast is a treasure trove of in depth interview with some high-profile well-known product manager folks. Favorite episode: Interview with Saeed Khan. I’m truly biased because I know him personally and I enjoy his insights. I love his emphasis on management side of product management.

    Inside Intercom

    both the blog and the podcast are one of the better known resources within product manager community. The only problem: it is a full-time job to keep up with the content! Favorite episode: Product Trends w/Paul Adams & Emmet Connolly. This episode was done early 2018 but I never get disappointed whenever I get a chance to listen to or read something that Paul Adams said or written.

    I have to confess that I have two more podcasts in my queue so this post will be updated with a review on This Is Product Management and the SaaS podcast shortly!

  • Last post for 2017

    Last post for 2017

    2017 passed by faster than I expected but it was a productive year for me. Great opportunities came on my way: I finished my work wrapping up epost transformation, learned a ton and made great friends in Canada Post. I joined Index Exchange and have learned a lot about Advertising and ins and outs of it (although there is still a long way to go) and made new friends. I also stepped up to take on more responsibilities on the business I am running with my friend. This meant that I ended up not writing blogs as much as I wanted to but I am still committed to continue this blog.

    It’s hard to believe that I have written this blog for the past two years and although writing is not easy, it is certainly rewarding to organize my thoughts and distill what I have learned into posts that I share with others along the way.

    This year I managed to read 11 product/business books which reviewed some of them but I also read many product related blogs, watched product videos and attended some local meet ups. Here are the ones that stayed with me:

    Blog posts:

    Videos:

    Meet Ups:

    • Product Tank last (Dec) meetup done by Johnathan Nightingale was a fantastic one it confirmed my beliefs on how the career success is non-linear and you have to take control of it. I wish you were there with me. He was quite an entertaining and experienced speaker and I will going to read his book as well.

     

  • How can we come up with new product ideas?

    How can we come up with new product ideas?

    I have previously written about Jobs To Be Done but the topic is still fascinating to me because I think this is a key tool to do customer discovery and ultimately drive product strategy. There are also so many overlaps between JTBD, design thinking and the concepts that were covered in Badass book that convinces me there is real value in understanding and pursuing them.

    In continuation with my previous research this time I managed to read the latest Clayton Christensen book along with one practical guide intercom published a while back on the topic. To refresh your mind here is what JTBD:

    A job basically is another way of defining underlying user’s need without focusing too much on user’s attributes. What I mean by user’s attributes are characteristics that define a user, like gender, age, occupation etc. The core theory of Jobs to be Done stems from the fact that customers pull a product or service into their lives when they are trying to solve a problem regardless of who they are. Problems in our lives always exist and we as customers pull products or services available to us into our lives as a way to satisfy those problem. The first product/services that address the job is not very good however they are competing with nothing (or as Mr. Christensen puts it they are competing with non-consumption) and they are making something happen when it was not possible before so we hire them. Over time because we are looking to make progress in solving our problem when we find a better, faster and cheaper solution we fire the old solution and hire the better solution.

    Let me explain these concept with an example: talking to your loved ones when you are far away is a universal problem. This problem fits a description of a job because regardless of people’s age, gender and/or location the need to communicate always exists. I remember when my aunt left Iran in 1985 to get her bachelor’s degree oversees, calling her was so expensive that my grand parents could only afford to talk for 10 minutes a week and those phone calls would cost a fortune at the end of the month. Few years later, when prepaid international phone cards came to market, national telecom company was quickly fired and prepaid phone cards were hired immediately instead. This solution was much more cost effective so now my grand parents could talk hours instead of minutes per week for the same cost. Fast forward to now where with ubiquitous availability of mobile phones and Voice over IP technology we now hire Skype and What’s app to talk however long we want for free.

    What is interesting is that JTBD helps us to view solutions for hire holistically by not just focusing on direct competitors in one market but to understand that the solution for hire can come from indirect competition. A few years ago if you asked business folks at telecom giants like Verizon in US or Rogers in Canada about their competitors I bet names like AT&T or Bell (which are other giant telecom) will pop up. They would never considered a rinky-dink company founded in Estonia that provided computer-to-computer calls to be a threat. Skype however was quickly hired by international students who were technology-savvy but poor to call home. They would tolerate bad voice quality and dropped calls as long as the talk to friends and family back home. Within 2 years Skype penetrated the market so fast that was bought for a record $2.5 billion in 2005. Fast forward to now where many of us don’t have a landline anymore let alone making an oversees call from it!!

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

  • How to have make developers love you (as a PM)!

    Whenever I get a chance I listen to some the excellent talks available on Mind the Product website. Over the course of past several weeks I came across three different talks about creating and maintaining a better relationship between the Product Manager and Development team. They also got me thinking about my own experience working with Dev for the past 7 years. Here is what I have learned:

    Learn the Dev Language:

    You do not need to have Computer Science or an Engineering background to be a product manager (although that can be helpful) but if you work with engineers learn to talk their language definitely earn their respect. Again I want to emphasize that you don’t need to be a programmer but you should have a solid understanding of software development life cycle (specially how the software is deployed and released), the technology stack, how the data flow from front-end to back-end through and back through different components (system architecture) and .

    Read this excellent article from Brandon Chu on what he recommends to know about technology. Also I found this article from Suzie Prince about the Continuous Delivery and DevOps quite enlightening.

    Build a Shared Understanding:

    I talked about the importance of shared understanding among the team in my review of User Story Mapping book. As a Product Manager define in your user stories Who you are building for, Why building this feature or functionality is important. Although I usually come with a suggestion on What to build, I love to see what my team comes up with and if I find their suggestion more convincing than mine I change it. I try to avoid prescribing How the feature should look or function as I trust my team they can figure this out much better than I can.

    All of this discussion happens during weekly Backlog Grooming meeting and after a couple of back and forth the ask is clear for everyone. This approach has been tremendously helpful to make sure what dev team is building is what I asked for.

    Learn to Work Asynchronously:

    I used to walk to the engineering section and tap on someone’s shoulder to get an answer to my question. I couldn’t figure out why I was getting hostile looks and short yes/no answers to my perfectly valid questions!! Oh, now I exactly know why they filled so pissed off! I was interrupting them the way everyone interrupts me now (karma!). And when you’re interrupted, you’re not getting work done. Interruptions break your workday into a series of work moments and you can’t get meaningful things done when you’re constantly going start, stop, start, stop.

    The remedy is to learn to work Asynchronously. If your question doesn’t need a response NOW cancel that face-to-face meeting and send an email message instead clearly outline the question and highlight when you need an answer by. Now if you don’t hear back by the date indicated you have perfectly valid reason for the tap on the shoulder 😉 Another good trick I learned from Sherif’s talk on how to make decisions without having meetings.

    Make that Decision:

    Ideas and requests come from all over and one of the benefits of having a product manager on a team is that s/he makes the decision of what needs to be built “Now” as oppose to  “in Future” versus “Never”. Developers need to always know that the code they’re working on now will deliver the most value and they need to focus on building just that. You are here to shield the team and you should be the single point of contact where ideas and requests internally and externally flows in. Listen to all ideas, evaluate them, analyze them and make an informed decision and stand by it. I will write a separate post on how to prioritize.

    Agile Works (even if it sucks at the beginning):

    Agile is all about teamwork and although it’s easy to get trained on principle of Agile in a day or two, working in an agile team at the beginning is hard. Like a lot of other newbie teams, My team and I had a rough start. Not only as a team we were trying to understand how to work and trust each other but also we were confused on how to build, test and demonstrate something small enough in two weeks time that provides value. Over time, it started to get easier when back-end developers tried front-end coding, hand-off to QA happened earlier. Automation testing happened. We wrote smaller stories and sized them during grooming meetings. We put a Definition of Done in place and soon enough the work didn’t piled up anymore. Bringing a culture of listening, self-organization and collaboration was hard but now with having agile values in place, the fruit is sweet 🙂

    PS: Here are the talks in random order: A Product Manager and a Developer Walk into a Bar by Sherif Mansour , 11 Things your Dev team wants from You by Christin Gorman  and Product Owners: How to Get Your Development Team to Love You by Ron Lichty

  • What is Definition of Done and why it is important to have one?

    Imagine you are doing major renovation on your house, like you are adding an additional level and you hired a team of top-notch contractors to do the renovation. Two months into the process, a representative of contractors informs you that they have completed all the work and they are done now. How do you determine if the work is completed? You will go and check out that second floor, you make sure they built it based on the agreed upon layout, there is running water and working electricity etc. Basically your verify their claims by going through a checklist to make sure completed work is to your satisfaction before you pay the contractors.

    Definition of Done does the same thing. It is a check list of all the items to be checked off before your team declares the story is completed. Unlike “Acceptance Criteria” that is specific per story and describes what the ask is, Definition of Done (or DoD for short) establishes what must be true of each product backlog item for that item to be done.

    DoD is partly done by your development team because it is their job to write high-quality, high-value software. So it is on developers and testers to define what quality is but you as Product Owner can add other criteria too. In the end both you and your team should agree on the Definition of Done before you start the first sprint. Let me explain this a bit more by showing you what my team Definition of Done is:

    Each item in our backlog will be “Done” when….

    • Acceptance criteria & functional testing is met.
    • Code is peer reviewed by another developer and meets development standard.
    • Unit tests written and passed.
    • There are no critical or high bugs open.
    • English & French content written and validated.
    • Feature is tested across supported platforms & browsers as per the Official Canada Post browser support.
    • Feature is tested for Accessibility; Web Content Accessibility Guideline (WCAG2.0) targets level A, AA.
    • Feature with new UI elements is tagged for analytic.
    • Remaining hours for task set to zero and task closed in Jira.

    As you can see in example above the first four items define quality baseline of the code. However other criteria such as accessibility, dual language or administrative tasks in Jira speak to other aspects of being “done”. Definition of Done is a living document which means that you have to keep revisiting it to refine the “done” criteria to make sure they are still up-to-date and relevant to your stories and products. For my team during every sprint planning we quickly visit the DoD to make sure if it needs further tweaking.

    After using DoD from stories for a while now I have extended them to software releases as well. I find having a release DoD where I have a checklist of all the things to be done prior to release extremely helpful.  This helps my team not to miss any big ticket item. Here is DoD prior to every release:

    And finally one last check list that is very powerful is to have Definition of Ready for each story. Definition of Ready verifies all pre-requisit work is completed before a story is ready to be pulled into a sprint. For example you have a story that lets user to to a date range and export some data based that time frame. This story needs a UX pattern, visual design for date selector and copy associated with the exporting function before it can be passed on to developers. You can create a Definition of Ready checklist so that a new story will NOT be pulled into the next sprint unless all the UX, content and VD sub-tasks are defined and completed. I find this is as a great approach to take the risk dependent external work out of your sprint.

    Hope you enjoy these checklists as much as I do 🙂