Sogol Fathian

Category: Product Management

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

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

  • 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