Sogol Fathian

Category: Product Management

  • Using AI tools for Product Management use cases

    My blog has been dormant for quite sometime but it’s Jan 2025 and the plan is to revive this blog with more frequent but shorter posts🙂

    The past two years has been a dizzying nonstop torrent of news of AI related innovations and products. What does this all mean for Product Managers and how can they be leveraged to facilitate, accelerate some aspects of the job?

    While I still firmly believe that as a PM you are responsible for thoroughly understanding the problem, there are many aspects of product discovery that takes a long time. Many generative AI chatbots such as chatGPT, Perplexity AI can be effective tools that help speed up the process. Here are a few use cases I have tried:

    Brainstorm ideas

    AI tools can help to generate ideas for a new product or service in a specific industry, or for a specific target audience. Don’t expect miracles but as a tool to help you think about a space in different ways and spark new ideas instead of coming up from scratch.

    Sample query I did on Perplexity AI

    Customer Segmentation

    Use chatGPT or similar tools to get a better understanding of different groups of users. Again as a research tool it may come up with some groups of customers that you couldn’t find right off the bat yourself.

    Competitive Analysis

    I also find that AI can be a great assistance in conducting competitive analysis as it quickly can show the key features, strengths and differences between multiple competitors offering.

    In summary although there are other use cases like writing product requirements or codes that I haven’t fully explored, I think for ideation and research AI tools will be essential to use going forward.

  • Leveling Up From Product Manager To Product Leader

    I have previously written about why it’s so hard to jump from a senior product manager to a product leader. Here is what I wrote:

    The catch is you can’t advance to the next level (becoming PM lead) just by doing what you’ve done up to now in a more complex/bigger scale. As a product lead you fundamentally need a different skillsets that you haven’t invested on acquiring.

    In that post I provided strategies to prepare you for this transition and even though those strategies are still relevant, I attended a talk by Jules Walters on Industry Conference this April on this very topic that made the advice crisper and better. When Jules got promoted from a Senior PM to a Product Lead in Slack he struggled to keep up with the new job. He eventually realized he needed to make these key transitions to become a successful product leader.

    From direct to indirect Execution

    Product managers at every level are expected to demonstrate leadership but as a junior product manager you are certainly tasked with more execution than leadership. When you become a product lead “people management” aspect of job becomes much more prominent. Now you need to allocate your time to hire people, set goals and and manage your team to deliver results which means you have less time to manage products directly. To transition from a direct to an indirect execution you need to identify people who are willing to take on more and mentor them so you can delegate. It also means to create a system to share context with others (a consistent way to describe the problems we’re solving, why we’re solving it, the solution outline etc) so they can make the right decisions.

    From team-focused to cross-functional Leadership

    When you are a (senior) product manager your focus is your team or teams you’re working with however when you become a product lead, building trusted relationship with teams becomes ever more critical because at this point your product is understanding and finding solutions to the needs of other teams across the company. You need to understand align with them in order to resolve dependencies and pushing forward. To transition to a cross-functional leadership you need to develop mass communication to keep everyone on the same page and provide context by telling simple and memorable stories.

    From Consuming to Influencing Company Strategy

    Understand other areas of your company and explore ways to influence them. At this point your focus should be to understand the business and how the product contributes to the business deeply. When you have a clear grasp of the business your goals will be aligned with the CEO. Set aside time to think strategically to come up with big picture projects and goals and get buy-in from other teams to execute them.

  • Two great PM reads

    When I talk to people who are curious to learn more about Product Management one question keeps coming up: “What are the resources to learn about Product Managment?” I have a dedicated page on what I’ve found as valuable resources for PM and I update it frequently. Recently I came across two more that I want to tell you about:

    Bringing the Donut

    Bringing the Donut: Read the articles on the website and do yourself a favour and subscribe to the newsletter. You’ll find the articles long (in a good way that goes in depth as oppose to shallow reads with click-bait titles) are insightful!

    Hardcore Software

    If you like me got your CompSci bachelors degree a while back Hardcore Software is educational and oh so much fun to read! Sinofsky walks you through his career path in Microsoft, behind the scene Windows and other product launches and you get to see even when there was no official product management in place how its principles still plays out. I am really enjoying myself reading the chapters as they get published out!

  • Kill your darlings!

    I just finished Stephen King’s superb book “On Writing”. For someone who’s not a fan of King’s horror stories I thoroughly enjoyed it and came across this quote:

    Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler’s heart, kill your darlings.

    I later found out this is one of the most frequent advice given to writers and I think one that can be 100% applied to product managers as well. First though let’s see what are darlings and why should they be ruthlessly killed?

    What King means by “darling” are those storylines, characters, or paragraphs that a writer works hard on and is often most proud of. S/he loves them, to the point that she almost doesn’t care if those bits are clear to readers or not. She loves them, and wants to keep them even if it makes the overall story worse! Dear product manager does this tale sound familiar to you? 🙂

    One of the common mistakes we product managers (and product designers) make is getting attached to our darlings. It’s understandable! Coming up with a solution takes creativity, time and energy. When you spent many hours crafting one into a workable requirement doc or a design, it can be really easy to get attached to it!

    When you fall in love with your solution if someone gives you a feedback at best you argue your hardest to justify its existence and at worst you get defensive and block the critique even when it can help you. Getting attached to a particular solution will also prevent you from seeing better solutions out there if you tried to tackle the problems from different angles. However the biggest danger of it all is if our solutions only make us happy but fail at the problem-solving then we are failing miserably as product managers!

    Therefore it’s imperative that you are willing to “kill your darlings” on your route to find the best possible solution to your user’s problem.

  • Making Hard Choices as a Product Manager

    making choices
    Image by Nathan Dumlao through Unsplash

    I was at an event where the keynote speaker told us when asked by his young daughter on what he does as a product manager, he said:

    “My job is to make a lot of decisions every day.”

    Although there are other ways to define what I do day-in and day-out, I often think back to this quote. Even though product managers don’t build the product directly, they make decisions which helps the teams and enables them to get things done. One of the biggest values a product manager brings to table is providing clarity which is the result of an informed decision by an opinionated product manager. Avoid these mistakes when you are making a decision:

    Don’t try consensus decision

    At first glance finding solutions that everyone actively supports seems like a great idea but consensus decision has two major drawbacks. The first one is not everyone wants to be involved in decision making. I know people like Marty Cagan advocate engineering involvement in product discovery but in my experience few engineers are interested or have the time to observe how users interact with a product or be involved in product discovery. Second and bigger problem in my experience is reaching consensus is near impossible! No matter how much you spend time on it by nature different departments have conflicting demands; Sales wants feature X as soon as possible but Legal won’t approve it until regulatory features Y, Z are added to the mix. While you are trying to involve both group and find a compromise the engineers are waiting on which feature to build!!

    Collaborate closely with a few key stakeholders and understand their must-haves but the decision on what to build and in what order is yours alone. Know that everyone will NOT be happy with your decision but for your unhappy stakeholder you owe them a justification of your decision and should manage their expectation.

    Don’t take too long to decide

    Unless what you’re deciding on is high stake don’t spend too much time on it. It takes a REALLY LONG time to involve everyone, get their input; when coming to a conclusion prolongs it zaps the energy and momentum out the team involved. I was once tasked to build an application system that authorized various groups of users and provided different access level to them. The architect involved was to select the suitable authentication and authorization tool to do this. He wanted to pick the right tool because the company was going to use this authentication and authorization framework for years to come. However he obsessed over this decision by taking months to analyze and compare various tools. By the time the final decision were made we had so many false started that engineering team was already fed up with a project that hasn’t even started yet!

    If your decisions can be easily reversed make them as fast as possible. Even if your decisions have high impacts for the business, do your due diligence gather up data, talk to people and do your competitive analysis but put a time limit on this process and when the time comes make as informed of a decision and move on with your decision to enable your team to get the ball rolling.

    Don’t second guess your decision

    Once you made your decision you need to commit to it to allow it to succeed. Second-guessing yourself lowers the odds of success and makes you look uninformed and haphazard in your decision making process. This doesn’t mean that you shouldn’t change course if new valuable insight comes up but questioning the wisdom of an agreed-to decision weakens the trust and alignment you worked hard to build with rest of the company which lowers the odds to succeed. Once you make a decision, commit to it.

    Even though the above list by no means is exhaustive list things to avoid they have been helpful guard rails for me. I want to leave you with a list of excellent and quite useful articles on this very subject including 10 Habits for Making Wicked Hard Decisions by Gibson Biddle, Making Good Decisions as a Product Manager by Brandon Chu and finally a fascinating TED talk from Ruth Chang that explains why hard choices are hard.

  • What got you here won’t get you there

    Jumping through a gap
    source: Thanks to Blake Cheek from Unsplash

    I want to let you in on a secret that no one warns you about: A gap on your path from a Senior Product Manager to a Product lead (or Director of Product) exists and you won’t see it coming!

    The story goes like this: At the beginning as an Associate/Junior Product Manager your job is to execute on the solution outlined for you. You work with a small engineering and design team to build a product where its features and functionalities are mostly defined and you get evaluated on the product you shipped. As you progress in your career you take on more challenging problems. This time you are the one working on a couple of projects concurrently in one area defining the features on one and coming up on a road map for another one. You work with bigger engineering groups and you’re responsible for Take to Company and/or Take to Market plans as well. But at the end of the day you are still being evaluated on what you shipped in your area.

    The catch is you can’t advance to the next level (becoming PM lead) just by doing what you’ve done up to now in a more complex/bigger scale. As a product lead you fundamentally need a different skillsets that you haven’t invested on acquiring. Here are some of the hurdles you will came across:

    1. You have expertise​ in your area but you are far less knowledgeable about other areas of the business. This means that while you present a road map for improvement in your area you don’t know the impact of these suggestions on the overall business.
    2. You worked in your role as an individual contributor which means ​you’re responsible for your work but don’t have experience managing a team directly and be responsible for their results and accomplishments as a team.
    3. You know how to effectively lead a cross functional team and influence your peers but you don’t know how to influence other executives.

    What to do to overcome these hurdles?

    After reading and thinking about these issues here is what you can do right now to break through them:

    Tour of Duty

    I learned this from Jonathan Nightingale’s excellent talk in Product Tank Toronto. Instead of having a vague, unactionable 5 year plan, have a specific career goal and plan your next 12-18 months to achieve it. To overcome issue 1 above put yourself in situations where you learn new skillsets and experience different types of product problems. For example if you’ve worked so far on “feature work” for your next role (aka tour of duty) look for “growth work” or try “scaling work”. This will expand your toolbox and help you identify which type of work is needed for a particular problem. When time comes you to lead your team you can help them pick the right solutions without getting into the weeds of the work itself.

    Mentor Others

    One of the most common traps is to keep the most important projects for yourself. You’re thinking: “This is important, I can create a better outcome myself, therefore I should do it.” But doing so has a big opportunity cost as it keeps you in the weeds and takes time away from you learning other things (obstacle #1). Mentoring others is a powerful way to combat this issue.

    Mentoring others not only is personally fulfilling and helps you learn about managing other individuals but also teaching someone to get better at something you do well helps you to delegate that work and take on new responsibilities.

    Be a Thought Leader

    Contrary to programming or design, it is hard to demonstrate you are knowledgable in a tangible way in product management. Maintaining a blog or some sort of outlet to record your thoughts, opinions and learning is one of the easiest and most effective ways to show you know what you’re talking about. What is quite striking to me is that how few PMs do this! If you want to go to next level you need to demonstrate you are a thought leader. So write a blog post, speak in related events, answer some Quora questions!! Not only you are giving back to the community but also you are practicing how to lead and influence others with your work!

    None of my above recommendations is a guarantee for your next promotion however they are all actions that are within your control. If you read this article and find it useful I would love to know what are your recommendations for jumping through this gap and landing successfully the other side!!

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

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