Category: remote work

  • My Recommended Books with Strong Ties to Product Management

    Past few months I have read the following books all related to product management. They were all excellent. I learned new techniques to write user stories, tackle prioritizing them and to strengthen my concentration on the task at hand. They also provided me new perspective on what skills I need to master to become a better leader.

    Book Summaries


    user-story-mapping

    User Story Mapping

    I came across the book shortly after I became a Product Owner to my newly-formed agile team and like many other newbie product owners I was struggling with how to chunk out the product I envisioned to build into smaller pieces by writing user stories. I also had difficulty on how to write these stories in a way that captures all the nuances and requirements. Thankfully User Story Mapping provided an answer on above issues for me. Here are the two main things I learned from it:

    As a Product Owner I can never capture all the requirements of a product and I can’t specify all the functional and technical details in just one document. Even if I could, this document would be so massive that most people wouldn’t read it. Even if they would they will have their own interpretation of what it means!!

    A better approach is to outline my ask as a story and use that as a starting point to a productive conversation. By the end of this conversation, the ask is more clearly defined and everyone have a shared understanding of what it is. My goal is then to document our understanding using words and pictures.

    The real goal of using stories is shared understanding. Stories get their name from how they should be used, not what should be written.

    Another valuable lesson is that focusing solely on backlog is dangerous. Without having a big picture of what the product is trying to accomplish and what types of activities people use this product for, building one small thing after another from a flat backlog results in a product with mismatched features. The solution is to build a Story Map!

    The biggest benefit of creating a user story map prior to building from a backlog is that it forces you to tell the story of all the interactions the user has with the product to accomplish something. This will give you the big picture of what your product does and in the process it identifies gaps that no one has thought about before.

    Creating a user story map is easy. At the top of the map are big stories (also known as user activities). These stories are too big to do in one sprint or an iteration but once implemented they provide major functionality to the user. The big stories are placed next to each other from left to right. If nothing else, reading these stories provides a view of the whole system.

    However to get these big stories done we need to break them down further into smaller stories. These smaller stories or tasks are placed in the second row and this breaking down continues to a level that provides enough clarity into what the system does. For more detailed explanation check out this blog post from author itself.


    hard-thing-about-hard-things

    The Hard Thing about Hard Things:

    I came across ‘The Hard Thing about Hard Things’ through reading Ben Horowitz’s blog and I am glad I read it. The book has two main parts: The first part is an easy to read, humorous but enlightening account of how Ben Horowitz managed Loud Cloud and Opsware, two companies he co-founded and run as a CEO. The second part is lessons  learned along the way of managing though hard situations.

    Second part of the book has too many good advice to recount them all and they go beyond my focus on Product Management. These are my most important takeaways:

    What resonated the most with me was the importance Ben placed on providing the right training for the job and making it clear what an employee is accountable for. He argues that if you don’t train your people, you establish no basis for performance management. As a result, performance management in your company will be sloppy and inconsistent.

    I personally have always struggled with this one. Unlike a developer or a designer who produces tangible results, product manager’s work spread across many areas and is not as tangible. If my company provides training for the specific skills and what it expects of me, it will save me a ton of time and the confusion and frustration of trying to figure this out by trial and error.

    Another issue this book confirmed for me is that everywhere there is bias to dismiss or rationalize leading indicators of bad news and only listen to good ones. Doesn’t this paragraph rings true in your head?

    If a CEO hears that engagement for her application increased an incremental 25% beyond the normal growth rate one month, she will be off to the races hiring more engineers to keep up with the impending tidal wave of demand. On the other hand, if engagement decreases 25%, she will be equally intense and urgent in explaining it away: “The site was slow that month, there were 4 holidays, we made a UI change that caused all the problems. For gosh sakes, let’s not panic!

    This explains why when Product Managers and executives see the growth is stalling and partners are leaving they avoid the obvious: The product is not the best in the market and is lagging behind competition. There is not much to do but to take the hard step of building a better product.

    Finally the most important and the most unexpected truth that came out of this book is on how to hire good executive. It talked about how to hire for key run a specific job (like VP of sales) for sometime yourself to learn what skills for that job you’re looking for. Although this one is not directly related to Product Management per se, I found it incredibly valuable in not only for hiring but also building framework for career development. You can read it in its own entirety in this brilliant post.


    deep-work

    Deep Work:

    This book is not directly related to Product Manager but it’s a book that if you are committed to follow through its advice it will change your life. The first part of the book starts with what Deep work is and why it is important to work on truly hard things with intense focus?

    Deep work is the ability to focus without distraction on a demanding task. It’s a skill that allows you to quickly master complicated information and produce better results in less time and it is a extremely valuable skill to have in the over-distracted world we live it.

    The author,  Cal Newport, goes on to explain in great detail on why deep work is valuable and meaningful but it is still rare. And honestly you do not need to read page after page to know why: Just take a good look at your work environment and daily habits and keep a tab on hours you actually focus on a hard task and I bet you’d be surprised on how little and fragmented your deep work is. I am first to admit that I suffer from a distraction and constant context switching: With so many interesting articles to read my browser has tens of tabs open that I read only half through. As part of open office trend and agile work style I work in a large room shared with 9 other colleagues and an ongoing open video conference so anyone can ask me anything anytime. And my day most of the time slices to a million of 30 min meetings.

    So how to cultivate the habit of working deeply in out day-to-day life? Here are my take away from the strategies suggested to in the four main rules suggested in the book to achieve deep work:

    Work Deeply

    Unsurprisingly this is rule number 1 on how to allocate enough time in your life to an uninterrupted work. There are multiple philosophies to schedule deep work in your day. For me building a daily routine around deep work and practicing it everyday is the way to go.

    Embrace Boredom


    Focus is a skill that must be developed before you can do it with any effectiveness and in order to strengthen your ability to focus, you must avoid the temptation to entertain yourself the minute you are bored by reaching out for the phone. One  suggested method to practice this skill is to cut off internet for some time interval and focus on the task at hand. Don’t check emails, surf the web or any other internet related activity during this time.

    I have been doing this for the past couple of days and I can tell you firsthand it’s hard! As soon as I find something that is hard to work through or make progress, a few seconds later, I catch myself to have opened a new tab or checked my email unconsciously.

    Quit Social Media

    Out of all rules outlined the most provocative one is to quit or dramatically cut back on the most beloved and addicting social media sites like Facebook, Twitter, Snapchat and so on. A core idea of this rule is that most people select digital tools using the any benefit mindset, which claims that you should use a tool if it can provide any benefit. This rule argues that you should instead use the craftsman mindset in which you only select the tools that provide the most substantial benefits to the things you find most important.

    Drain the shallows

    Finally having a fix time where you leave work and wrap up your work day forces you to be ruthless on what are the important stuff that get done.

  • 5 Tips for Managing Products Remotely

    After reading A Year Without Pants I became interested to know more about remote work and specifically how it works with product management. What qualities are required? What are the advantages and disadvantages? so I did some research such and interviewed a couple of my colleagues who work remotely as Product Managers. I like to share what I learned along the way with you. Let’s get started:

    The practice of working remotely has been on the rise for sometime. In US alone, number of people who regularly work-at-home has grown by a whopping 103% since 2005. (For more interesting data take a look at latest Telecommuting statistics). There is no denial that work from home is a real attractive option and if you need more convincing reasons just read the book Remote. I myself dream of working from home where I don’t need to commute to work everyday (specially in winter time), I can get something done without getting interrupted multiple times and have flexibility over my schedule.

    However most of the telecommute jobs I have seen are for well defined jobs such as software engineers, designers and customer support members.  There are few remote product manager jobs out there and I have always been wondering why? Can it be that there is no need for product managers in companies where work is done 100% remotely?

    I believe the answer lies in company’s size and maturity and not on how it’s distributed. In small companies with a single product and  a small team, different team members take on additional responsibilities to divvy up the work. Usually the founder who is also the CEO takes on responsibilities such as talking to customers and defining product vision. Then designers and developers are responsible for turning that vision into workable software. In this setting, the product management role is distributed among the team and no single person is responsible for the job.

    However as soon as the company grows and the product becomes more complex the work itself becomes too much of an overhead to do for designers, developers and founders on top of what their main responsibilities. Someone needs to clarify Who we are building for and Why to free up the rest of the team to focus on How. This is when Product Manager is added to the team. (Take a look at black box of product management article for an in-depth explanation).

    So if being a remote team as oppose to a co-located one has no effect on having a product manager role, how does remote product management work? What qualities are required? What are the advantages and disadvantages? I sat down with three of my colleagues who all work as Product Managers remotely to get answers to my questions.

    For my first interview I talked with Alex whom I had the pleasure of working with for a long time at OANDA. OANDA’s main focus is currency trading and its popular online trading platform known as fxTrade enables trading volume of several billion dollars a day. Alex has been working remotely for the past 6 years and he currently manages fxTrade across all platforms (Web, Mobile Browser, Mobile App). Design and development are all centrally done in Toronto. Alex travels every 2-3 weeks from San Francisco to Toronto and stays for a week.

    Then I sat down with Barbara who works as Product Manager for Mozilla. Barbara works on Firefox browser for Android app. Her development team is geographically dispersed across the globe. Barbara is based in Toronto but she travels once a month to one of Mozilla offices in States and stays with the team for a week.

    My final interview was with Saeed who works in Product Management at Informatica. Informatica provides solutions around data for the Cloud, big data, real-time and streaming. Saeed is based in Toronto but his team is spread across India and in northern California. Except for annual planning meetings in Informatica headquarters he does not travel.

    Top 5 observations about working as a remote Product Manager:

    Here are the most interesting things I learned through my interviews:

    1. We all work remotely to some degree

    “Business expand across locations. With the exception of small companies, where everyone is in one location, as a Product Manager you have to work with remote people and teams… and of course, customers and partners are NEVER at HeadQuarter. 🙂 “

    When you come to office even when you are co-located with the development team, you need to work with other parts of business such as Sales, Marketing, and Customer Care which may be at different locations and time zones. So being able to work with others through email, phone, chat or whatever remote communication channel is a must no matter how you work.

    2. Communication and Collaboration

    “None of the team members I regularly work with are in the Toronto office, pretty much 99% of my meetings are held over Vidyo (a video chat system used at Mozilla)…We [also] heavily use IRC and Slack, as well as Bugzilla and email to communicate.”

    Email, phone, video conferencing and instant messaging (Slack being the most popular one) are used for communication with team members. However what is more important than choice of tools is to make sure crucial information isn’t lost between colleagues. Barbara and Alex find traveling at least once a month necessary to make sure that everyone in the team is in-sync.

    For collaboration, screen sharing software like WebEx, project management tools such as Trello and wiki softwares to quickly edit content like Confluence and Google Docs are all part of the remote toolbox. Good written communication is the single most important skill to make sure everyone has a shared understanding of what the ask is and how to provide a solution.

    3. Trust is the Key

    “I have built a close relationship with my team over time and now I trust my them to know my vision really well… I’m confident that they will be able to represent and defend this vision to others during a meeting when I’m not in the room.”

    Product Manager has to earn the respect and trust from the programmers and designers. With trust, PM can discover how to get the best possible work from the team. If there is clarity on the goal and a criteria that defines it, then we can speak the same language about what we need to do to get there. This issue becomes even more important when you work remotely as you need to build relationship over time and and you need to make sure you can effectively convey the vision to everyone on the team.

    4. Biggest Advantages

    “I can be more productive because I’m working somewhere else. I don’t get pulled into meetings where I can’t contribute mostly because I’m not in the office. As a result, until something important comes up that needs my attention I don’t get called into meetings.”

    One thing that stands out in addition to all of the advantages of remote working, is the fact that you don’t get tied up with unnecessary things to do inside the office. Instead you can use that time into do some strategic activities like talking to customers, delving deep to understand the problem and figuring out product/market fit. These tasks require long and uninterrupted attention which is something that gets harder to come by when you work in a room with 10 other team members and a constant flow of chatter and calls.

    5. Main Drawbacks

    “There are advantages to working in the same office as the product team. It’s very easy to get the group together to discuss an urgent issue. The proverbial “water cooler conversations” are only possible when you are co-located. There is a lot of information that can be gained simply through casual discussions, having lunch with someone or even “overhearing” something in the hallway. And quite honestly, having timely information IS very important managing products.”

    This quote definitely captures two themes that keep coming up. The first one is you can’t walk into an office and give a brief about what was just decided in another meeting. This disconnect can lead to informational asymmetry and misunderstanding. You have to be very disciplined in dispersing information. Sometimes you need to set up multiple meetings just to convey the same info because it’s hard to set up a meeting that works for everyone. Another important thing is to have a central knowledge repository where everything is organized and be vigorous to keep it up-to-date.

    Finally emergency situation or when a project needs a lot of coordination from multiple teams having an on-site team is so much easier than orchestrating activities between multiple time zones, and only being able to rely on chat, phone and video to work things through.

    Conclusion

    All in all I think working as a remote product manager is not fundamentally different from working with a co-located team.  There will always be a sense of FOMO (fear of missing out) when dealing with remote teams, so over-communicating is often better than assuming team members will find things out through other means. You also have to work harder to build the relationship and get used to different working styles of the team.

    Note about this post’s image: It is taken from Trello blog which has an insightful article about remote working.