PMs Should Allocate A Percentage of Time To Each Stakeholder
Different functions like engineering, UX, marketing, sales and support want different things: engineering may want to improve scalability, reliability and security. Designers may want to improve the quality of the user experience. Marketing may consider new feature more important than improving existing features. Support may not want new features; they may want the features that we already have to work well. These different functions see the world from different perspectives. No matter how much you try, you can’t align them, because their goals are fundamentally different. At the risk of exaggeration, it feels like trying to get a cop and a thief to see eye to eye: you won’t be able to, since they want opposite things.
The traditional solution to this problem is to have the PM be the arbiter between these different functions. But that just makes it the PM’s problem; it doesn’t solve the problem. As a PM, it’s frustrating that no matter what you do, people are unhappy with you. And it’s frustrating for other stakeholders to be told that their priority is not the PM’s priority at this point, or having to beg the PM to get what they want.
A better solution is for the PM to proactively allocate a certain percentage of time in each sprint [1] to each function. Say 20% to engineering, 5% to support, 5% to design, 5% to sales, and 5% to marketing.
Each function maintains a spreadsheet of what’s important to them, sorted by priority. For example, marketing’s spreadsheet reflects the priorities from the marketing head’s point of view. The PM will not reorder the items, imposing his own priority.
When planning a sprint, the PM pick one or more items from the top of each spreadsheet and include it the sprint. If the PM thinks a particular item is a bad idea, or misaligned with the product goal, or has a dependency on something else that can’t be done now, or amounts to doing double work, the PM can say no to that particular item, but otherwise, the PM won’t impose his opinion of what’s important when it comes to the time allocated to each function.
Each item in the spreadsheet should only be a link to a task in the bug tracking tool like Trello. It should not have any descriptions like “Improve import”. That’s subjective — someone might improve import in a way different from what (say) the marketer wanted, and we should not have a discussion after the fact of the form “But that’s not what I wanted!” The items in the spreadsheet should only be links to the bug tracking tool. That way, the spreadsheet doesn’t add ambiguity.
The time allocation can be more or less in a given sprint. For example, if a function’s time allocation is 5% but their work ended up taking 10% in a given sprint, their work will be skipped in the next sprint. So it’s an average allocation. This is more productive than putting a hard stop and 5% and forcing an engineer to context-switch midway through a sprint.
When we say that marketing has a 5% time allocation, it doesn’t mean that only 5% of time can be spent on marketing. It means that the head of marketing gets to decide how 5% of time is spent. The PM picks tasks in the remaining amount of time, and some of these might very well be tasks the head of marketing wants. So the amount of time spent may very well be more than 5%.
In summary, conflicts naturally arise as part of work. When left unhandled, they can mutate into deeper issues of lack of trust, certain people feeling like a lower caste, strain in a relationship, inefficient collaboration, etc. To prevent these from happening, we need to find ways to release a small amount of pressure continuously, much like a pressure cooker has a safety valve [2].
[1] Instead of allocating a percentage of time in each sprint, an alternative is to set aside one sprint in a quarter for (say) sales. I don’t think this is a good idea, for several reasons:
If sales needs something, they have to wait a quarter, which dilutes the point of this effort.
Scheduling many sales tasks at once may not work because of dependencies between tasks.
You want to create discipline among leads of different functions that if they want something, they can’t have something else, because the team as a whole has limited bandwidth. A small amount of time every sprint, such as one task, creates that discipline.
Doing things in a big-bang way, like a sprint dedicated for sales, raises the stakes compared to do a little every sprint. If things go wrong, it can derail the entire sprint. Whereas one task every sprint
Having a sales sprint requires everyone to work on sales tasks. By contrast, having one task every sprint gives you more flexibility on whom to assign it to.
[2] There’s another way of empowering functions to get what they want done, which is embedding software engineers in every team, but most leads are not cross-functional enough to pull this off.