Working in product management is rewarding but demanding. As product people, we have a large set of diverse responsibilities, which often translates into a high workload. But continuously working too hard carries the risk of becoming chronically tired and stressed and sacrificing our health. This article discusses techniques that help you achieve a healthy, sustainable pace and avoid the danger of being constantly overworked.
What is Sustainable Pace?
Sustainable pace is an important agile principle. The Agile Manifesto defines it in the following way: “The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” The goal is to create a healthy work environment and avoid that people are routinely overworked, lose their creativity, make mistakes, and eventually sacrifice their health. A framework like Scrum offers specific techniques that ensure sustainable pace—unfortunately, only for development team members and not for product people.
But sustainable pace is equally important for you, the person in charge of the product. You have a demanding job with a range of diverse responsibilities. These include interviewing users, working on the product roadmap, updating the product backlog, engaging with the stakeholders, and working with the development team, to name just a few. As all these duties compete for your time and attention, it is all too easy to do too much, work too hard, and exhaust yourself—which is neither good for you, nor for your product.
Say No
If you find that you are overworked and struggle to cope with your workload, then start by reflecting on the tasks you carry out. Are all of these part of your actual job? I find that product people often take on responsibilities that belong to other roles thereby making a demanding job even harder. A common example is looking after the development team. While it’s great to care about the team, facilitating effective collaboration within this group is not your responsibility. That’s the job of the Scrum Master.
I know that some product people don’t have a Scrum Master working with them or that the Scrum Master’s work is not effective—the individual might be too stretched or not adequately qualified. But if that’s the case for you, then I recommend addressing the issue rather than covering another person’s job. The latter will stabilise an ineffective setup and cause you to be overworked or neglect some of your core duties, neither of which is desirable.
Therefore, focus on your actual job—making or keeping the product successful. Do not take on additional responsibilities like improving the development process, leading the dev team, making UX design decisions, or creating a marketing strategy. That’s the responsibility of the Scrum Master, development team, and marketing stakeholder respectively, not yours. Have the courage to say no even if it’s difficult: There is no lasting benefit in you becoming the general dogsbody for the product.
Be Proactive
Next, minimise the amount of unplanned work and firefighting you encounter. I find that many product people are so busy with urgent tactical work, such as refining user stories, working with the development team, or answering a support request, that they neglect important strategic tasks like regularly assessing if the product strategy is still working. This can cause nasty surprises like a competitor leapfrogging you, which then leads to more, unplanned work, as you desperately try to catch up with the competition.
Consequently, make enough time for strategic work. Regularly assess how your product is doing and how effective your current product strategy is, for example, by holding collaborative strategy reviews, as I describe in more details in the article “Establishing an Effective Product Strategy Process”. This will allow you to play a proactive game and be responsive rather than having to react to surprises.
Share the Work
If you find that you are simply too busy to regularly strategize and cannot let go of any responsibilities, then consider sharing your workload with development team, stakeholders, and other product people.
With the Development Team
If you spend a lot of time working on the product backlog trying to create perfectly crafted user stories or if you have to answer plenty of questions during the sprints, then you are probably not effectively sharing the product backlog work. Managing the product backlog should be a collaborative effort. The development team members should actively participate in the backlog work, discover, capture and update stories together with you, and help you prioritise the product backlog. This leads to better product backlog items, reduces the amount of questions you have to answer in the sprint, and frees up your time.
Additionally, you are often able to delegate (some of) the refinement work to the development team—assuming that the team has acquired enough knowledge about the users and product and that you trust the individuals to make the right decisions. This will further reduce your workload and enable you to spend more time on important strategic tasks.
With the Stakeholders
Some product people I have met spend a significant amount of their time on “politics”: negotiating deals, convincing people, selling ideas to important stakeholders. Consequently, stakeholder management can feel like herding cats. While you will always encounter stakeholder challenges, I find that a lot of time spent with negotiation, persuasion, and re-alignment activities can be saved when you embrace a participatory decision-making process.
The idea is simple: Involve the key stakeholders—together with development team members—in important product decisions, for instance, by using consensus or product person decides after discussion as the decision rule. This will increase people’s buy-in and reduce the need for continued re-alignment meetings or possibly some crisis management if you find out that people did not implement an important decision. (You can find out more about participatory decision-making in my article “Use Decision Rules to Make Better Decisions”.)
With Other Product People
If the previous two measures are not appropriate, then consider how big your product is and how many development teams you work with. As a rule of thumb, if there are more than three teams, then you may have to involve additional product people to help you manage the product. You could have, for example, one person in charge of the overall product and additional people who look after product features, as the picture below illustrates.
Alternatively, you may want to consider breaking up your product, for example, by unbundling one or more features and launching them as a separate product like Facebook did with the Messenger app in 2014. Both options will reduce your workload and make it easier to achieve sustainable pace. (Please refer to my article “Scaling the Product Owner Role” for more information on how to jointly manage a product.)
Prioritise
Many years ago, I was discussing a lengthy requirements document with the product manager in charge of a healthcare product. As there was too much work to do, I suggested prioritising the requirements. I’ll never forget the look I received and the answer the individual gave me. She said: “That’s impossible. They are all important!” The issue is, of course, that without the ability to prioritise, we don’t know when to say yes and when to say no. Consequently, we are likely to take on too much work and trying to accomplish too many things at once.
If you find it hard to prioritise—be it the order in which items should be delivered or if you should accept a feature request—then you will benefit from establishing clear and shared goals. As described in my article “Leading through Shared Goals”, I like to work cascading goals that form the chain shown in the picture below.
The goals in the picture above are systematically linked and constitute a hierarchy with the vision at the top and the sprint goal at the bottom. With the right goals in place, you are able to assess if you should add a new feature, for example. Here is how it works: If the feature is helps you reach your current release goal, you should probably take it on. If it doesn’t, then include it in the product roadmap—assuming it serves a user or business goal stated in the product strategy. If that’s not the case, then kindly but firmly say not to it. In the story above , the product manager would have benefited from having a clear and agreed release goal. This would have allowed her to order the requirements by considering how important each one was for meeting this goal.
Therefore, ensure you have meaningful and agreed goals available that help you prioritise the work. This will not only help you make the right decisions, it will also reduce the risk of being overworked and help create a sustainable pace.
| Published on Java Code Geeks with permission by Roman Pichler, partner at our JCG program. See the original article here: Sustainable Pace in Product Management Opinions expressed by Java Code Geeks contributors are their own. |
