Sogol Fathian

Author: sogolf

  • What I learned professionally in 2019

    In 2019 I read 17 books which may not sound like much but for me it’s the highest number of books I’ve read in years (here is my “completed” books in Goodreads). In addition to an earlier post about my favorite 2019 books here are some other ones that I strongly recommend you to read:

    Better

    “Better” simply was one of the best books I read and Atul Gawande is now my favourite writer. Even though Better mostly talks about what it takes to be a better doctor I found the advice universal to all professions and extremely useful. It talked about becoming better by applying diligence, incorporating ingenuity to understand root problems and do right by people while weaving fascinating medical and public health stories from around the world to deliver the points.

    Asshole survival guide

    “The Asshole Survival Guide” offers strategies in dealing with, avoiding and even fighting general assholery in your life. In addition to highlighting what makes a person an asshole, the author also sheds light on blame and call-out culture, reminding us that personal responsibility and empathy is key even when dealing with assholes. I must confess that I found the book depressing but useful.

    Obviously Awesome

    “Obviously Awesome” is one of the best marketing and strategy books I’ve read this year which provides practical and useful ways to look at a business and the efforts it takes to position a product or service. The advice is sound for both startups and mature products and it provides a systematic way to apply Jobs To Be Done for your marketing efforts.

    Committing to Be a Better Communicator

    This year my boss gave me critical feedback that despite my best effort when presenting to upper management or stakeholder in general, my ideas seems complicated and people leave the meeting feeling confused. This was an important discovery for me (as in my head I was very clear on what I want to convey) so I invested to fix this.

    I read some excellent books on public speaking and started going to Toastmasters to practice my public speaking because no matter how much you read about something you only get better by applying it in practice! Even though I’m far from perfect I learned about main elements of a talk and gained valuable insight on what makes a presentation great. I’ll definitely will continue this path.

    Letting Go of rigidness of Agile

    At the peak of this year I worked on six projects (2 of them major ones) with four remote teams. Since all teams worked in agile I attended a lot of ceremonies from daily stand ups to end-of-sprint retrospective. I understand the ratio of 1 PM to 16 engineers is out of whack but frankly I spent all this time hoping to help my team but not only many of these meetings weren’t good use of my time but they felt draining. In many of them it seemed the core Agile principles have faded; instead people were focused on the useless nuances like endless discussion about story points per user story (everything tended to be given 3, 5 or 8 points to show that its small but not too small), or doing retrospective rituals (what went well, what went not so well) with no tangible improvement in the way the worked or their output.

    As controversial as this may sound I don’t care about these agile ceremonies anymore. Don’t get me wrong, I still love the idea of iterating and delivering thin layers of end-to-end functionality as oppose to give me all the requirement upfront and I wait and see the result but for me an ideal way of working is an engaged team who understands product vision, asks questions when things are not clear, collaborates and challenges PM on the solution put fort, constantly shows the work completed and releases it to production regardless of how they do it.

    and with that looking forward to all the learning that 2020 will bring!

  • Dealing with ambiguity as a Product Manager

    Have you ever that overwhelming feeling when your team is waiting on you to provide perfect answers when you don’t have any? Have you been in a situation that you’re building a product based on a loose vision not knowing exactly how it’s going to look or behave?

    I have been in these situations many times before. In fact as my career progressed and I took on bigger and more complex projects I had to constantly deal with ambiguity defining the product. Although dealing with ambiguity is one of the most fun aspect of product management it can be challenging too. Here are some time-tested approaches I learned to manage ambiguity better:

    Get comfortable with being uncomfortable!

    I can still feel the panic setting in when after a two minute chat my manager suggested a completely new improvement instead of my carefully thought original plan. His idea made sense but what should I do?!!? In few hours I was going to Montreal to kick this project off and I had very little time to think things through. At first I was paralyzed but then figured nothing would be worst than showing up empty handed, not even piecing together that little bits of information I had. My next few hours was spent on talking with few people and teasing out ideas and I felt a bit more confident! During kick off I told my team about the change of plans and challenged them to come up with a solution to satisfy the ask. By the end of the meeting we had a solid idea of the next steps and how to go about them. It was like magic and I couldn’t have asked for a better kick off!

    Recently I came across this blog post from Ken Norton which validates my experience. The fact is as a product manager ambiguity and change is part of your life and you need to embrace it despite feeling jittery and uncomfortable! This is in conflict with another aspect of our job which is to bring clarity and reduce risks but the fact is you don’t always have and know all the answers and you need to be okay with it!

    Do just enough to get started

    Even though you don’t have all the answers up front it doesn’t mean you’re off the hook ! Your team still needs your help to understand the problem and the results we want to achieve. This means you need to work ahead of your engineering team and understand the business problem and identify the goals and success metrics based on it.

    Much has been said about Amazon’s approach or completing some sort of canvas as the first step. I tried multiple approaches and what worked so far is to write a one pager (which is not a slide deck!) and have it somewhere central for the team and stakeholders to view and comment on. Google docs, Confluence or any other wiki-style collaboration software works just fine but don’t email around a Word document as things start to get out of hand! Usually comments and discussions following provide guidance on next step on whether to dig deeper or the vision is good enough for the team to get started!

    Keep connecting the dots until full picture emerges

    Your initial one-pager resulted in a set of questions to investigate further! Now in addition to finding answers to these questions you also need detailed discussion with key people to make your vision more concrete. When I was involved in building a new web application system from ground up I worked closely with web architect and engineer lead to flesh out use cases for user permission and access levels while on UI front I worked with designers to solidify how the web application going to look like and collaborated on user research and testing. I also kept the business side in the loop by asking their feedback on working prototypes. As I connected these different aspects of this product together, I felt more confident about the vision and solution being built and I could answer many more questions in greater details!

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

  • My Favourite Product Gatherings in Toronto

    Product Management is getting more attention and popularity as a profession and so there are quite a few product events happening in Toronto. The other day a friend asked me about my favourite meet up and events that I go. Below are a few of my favourite local events:

    Product Tank Toronto: https://www.meetup.com/ProductTank_Toronto/ is a big and usually high quality presentation from well known people talking to large crowd of 200+ attendees.

    Product TO: https://productto.org/ is a smaller event where the audience pitch product topic they’re interested about and the audience divide into smaller groups to further debate those topics. I love this intimate event mostly because there is no one expert and you get to have interesting and engaging debates with your peers on relevant topic.

    Product Camp: https://productcamptoronto.ca/ an annual day of unconference where again people show up with ideas to present and if they get voted up on the topic they’ll present. The audience choose to walk between multiple concurrent sessions they can attend.

    Other events that I go from time to time

    Toronto Product Management Association: https://tpma.ca/ is a paid event. It usually is in presentation style with a focus on product management and product marketing management at big corporation and enterprises.

    Product School Toronto: https://www.productschool.com/toronto/ is small group presentation that is mostly geared toward newer PMs who want to break into the field.

    Product to Product: https://roadmunk.com/community an on again off again type of event that RoadMunk (a company that sells roadmap solutions to PMs) host.

  • Best books I’ve read so far in 2019

    I love reading books and even though I’m a slow reader I’ve managed to read 8-9 books annually for the past couple of years. Here are the top 3 excellent books I’ve read so far.

    Radical Candor by Kim Scott

    This is by far my favourite book from last year. I loved this book so much because it not only provided a playbook on how to manage a team but also it provided this great framework for giving and getting feedback. The book is filled with great insights coming from Kim’s personal experiences from working in Google, Apple as well as having her own start-up. It’s a must read!

    Show & Tell by Dan Roam

    Show & Tell is easy to read and its pages are filled with pictures and drawings but don’t underestimate how powerful and informative it is. I learned so much from this book. Key takeaways, everything is told through a story and even though there are many varieties on presentations, they all follow a few outline formats. Also our brains are wired to process visuals so use pictures, images and diagrams to convey clarity.

    Confessions of a Public Speaker

    Like other Scott Berkun’s book, Confessions of a Public Speaker is an honest book that provides you with everything you need to know to speak well in front of any audience. From excellent tips on public speaking from what to do, how to do things in right way to funny stories of things gone wrong I enjoyed this book enormously.

  • 2018 product lessons

    2018 flew by and I realized that I have only written twice on this blog for the past year. Nonetheless as my last post in 2018, I want to share with you these 3 important lessons I learned this year in problem solving, collaboration and defining strategy:

    • Provide context
    • Pre-sell your vision prior
    • Have crawl, walk and run versions of your solution

    Provide Context

    • location, location, location
    • providing context is articulating clearly and concisely the what, the why and the outcomes
    • when you’re selling the project and presenting the vision
    • to dev team before the work starts
    • to marketing and support team when you’re launching the product

    Pre-selling

    • once the vision is set and work scope is roughly drawn pitch it to key people, see their reaction, their questions and objections
    • be more aligned with various parties so you can reach decisions faster

    Crawl, walk, run

  • Use your time wisely

     

    It’s been two years since I wrote about time management but the topic is still close to my heart. The reason is pretty obvious but given the nature of product management I find it even more relevant to tightly manage your time or by end of the week you’re going to scratch your head on what have you accomplished.

    In the last Product TO meet up I moderated a session on this very topic. In addition to my own tactics, I came away with a few tricks on how other people manage their time. Let’s go through them:

    Have a plan of attack

    Have a plan of what you want to achieve in a week. It is extremely important to write it down and prioritize it based on what’s important and urgent and equally important on what’s important and not urgent like reading, learning and talking to customers. If your schedule is all over the place and you are constantly fire fighting plan your day to the hour. Of course you will have to change your plan several times as your day/week develops but having an plan and a framework of what you want to get out of your time will help you decide which meetings to skip and if things must be done or can wait.

    Take a easy with M&Ms

    M&M was the term used in “rework” (and if you haven’t that I strongly recommend that you do. It’s easy to read and oh so good) which refers to “Meetings and Managers”. While I do have a few tips on how to work with your boss my following are my tips will focus on avoiding and eliminating (zombie) meetings.

    I hate nothing more than those 1.5 hour meetings you go with 20 other people where everyone discusses something and you come out of it with no decisions made, no clarity on anything and a promise of yet another follow-up meeting to continue this torture. I know you feel me, you’ve been there too!

    Yes you can! Eliminate status meetings

    Status meetings (specifically product team status meeting) are one of the most annoying ones ever. I’m talking about the one where each PM reports back what they’ve done with their teams in the past week. While this is valuable for director of product or stakeholders working with those PM, it’s completely useless for peers who’re working on totally unrelated products/projects. The best way to solve this is to ask everyone to write their updates/blockers etc in a wiki page by a certain time and day and the managers and stakeholder go over it themselves and pull certain PMs for further questions. This approach also has the bonus of providing a historical week-by-week view of who has done. Pooofff one meeting gone from your calendar forever!!!

    Don’t schedule recurring meetings

    I challenge you to instead of a scheduling a recurring weekly meeting, evaluate every week to see if you still need to have it. Be honest with yourself! If you’re driving the meeting and you’re not ready (more about this on point below) with what you want to discuss postpone it. I even suggest to experiment with daily standup meetings, I haven’t seen any major downside in reducing daily stand ups from every day to every other day.

    Also if you are invited to a recurring meeting and you realize you haven’t had a thing to say in the last 20 minutes of the meeting, you’re clearly not adding value. Start skipping them!

    Go into meetings with an agenda and come out of it with a clear outcome 

    If you are driving the meeting it’s extremely important to do upfront work. What is the purpose of the meeting? Are you bringing up a proposal and looking for feedback as part of ideation? are you trying to make a decision? are you answering questions as part of grooming and sprint planning? Whatever your goal is make it clear in the agenda. Have someone to take notes, or write them yourself and then summarize what discussed, what actionable items are and who is responsible to act on them and by when.

    Action items must be clear enough that it doesn’t leave room for interpretation and small enough that is doable within the timeframe proposed. Having a date attached to action item makes it more palpable makes it actually happen.

    Another neat trick is instead of going through a proposal or presenting a slide deck during the meeting, send it in advance to everyone to read and because most people don’t read, send a reminder before the meeting. Make sure to make it clear for everyone that the meeting is intended for deeper discussion or answering questions as oppose to high-level presentation.

    And finally if I had the authority and power for my meetings I would ban cellphones and laptops except for note taker and presenter. I have been to way too many meetings feeling I’ve wasted my time because no one is listening or paying attention. It is disrespectful. If something worth our time then it’s worth our time. How useful a meeting can be when attendees are slacking with one hand and tweeting with the other?

    Please Slack responsibly

    If you are working completely remotely I get it! Slack (the hottest messaging app du jour) is very useful to have short and efficient outburst of communication to get answers and stay connected but if you are slacking with your co-worker across the room all day long, then what’s wrong with you? No matter how fast you type you can still talk faster if you have a 5 min conversation.

    And please don’t get me started on a making a product decision with 15 other people across a slack channel. The conversation almost always goes through a tangent and what remains of it is one-liners that 15 people chimed on without any conclusion. This is the opposite situation that eliminating a meeting actually works worse! Have a super short ad-hoc meeting with few key people, look at the trade-off make the decision and then feel free to broadcast in Slack!

    Hope this is useful for you!

    Picture is taken from news18 website.

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