Product Management in Two Steps

Step one: Follow the rules. Step two: Change the rules.

In my work as a product manager and coach, I have spoken with many people who are very nervous about finding the “right” product management and development process for their organization. They have a lot of questions about the what it means to “do Agile,” about the difference between Scrum and XP, about how to socialize a new system in a process-averse culture. Will the engineers take well to pair programming? What time should the daily stand-up meetings take place? How big should the teams be? How many hungry engineers can two pizzas actually feed?

The truth is, there is no perfect product development process for any company — let alone for every company. But to find a process that works well, an organization must take two seemingly contradictory steps: follow the rules to the letter, and change the rules without fear.

Step One: Follow the Rules

Many books about agile software development will tell you to avoid “customizing” an off-the-shelf process before you’ve completely implemented it. When I first encountered this idea, it struck me as deeply counterintuitive at best and flat-out arrogant at worst. Why should you trust some Level 92 Certified Scrum Warlord to tell you how to run your team? Why follow specific rules if you know they won’t work for your organization? Customizing things early on gives you a chance to assure the folks on your team that none of the stuff they like will change — you’ve personally customized the process to make sure of that.

For better or worse, though, those Level 92 Certified Scrum Warlords are often right. Every single time I’ve customized a process before fully trying it out, I’ve come to regret it. It turns out there are, in fact, very good reasons to follow rules that you are pretty sure won’t work. Pain points often need to be felt to be fully understood. The rules that are likely to be omitted from a “bespoke” process are often the ones that an organization needs the most, precisely because they will be the most painful to implement.

I’ve seen this exact scenario play out many times with organizations that try to adopt the practice of “timeboxing,” or imposing finite and absolute limits on the lengths of their meetings. The first handful of timeboxed meetings are usually a disaster. People lose track of time, and leave the meeting feeling like they accomplished nothing. Somebody in a leadership position sees the hard stop at the end of the meeting as an opportunity to hold court uninterrupted. Those who are inclined to oppose rules and process see this as proof that important meetings cannot and should not be constrained by some kind of arbitrary and absolute time limit — or at the very least, proof that the limit should be changed. Is it worth missing something important to follow some stupid and arbitrary rule?

And yet, through that very conversation, deeply rooted organizational assumptions are called into question. What exactly is important to discuss in a meeting? Who decides what is and is not important? Why are we even having these meetings in the first place? Slowly but surely, people realize that the most powerful aspect of timeboxing is not that it makes meetings shorter, but rather that it forces organizations to openly address these questions.

Step Two: Change the Rules

Changing the rules and breaking the rules are two very different things. In fact, breaking the rules makes it much harder to actually change the rules. Each time a rule is broken, each time an exception or compromise is made in the name of expediency or a “special situation,” the entire process loses some of its structural power. People begin to perceive rules and processes as impediments to getting things done. When those rules and processes are changed for the better, they are ignored just the same. All the old, unspoken assumptions still dictate the way work is done, and become more entrenched by the day.

I am a process-averse person by nature, and I have often feared that hard and fast rules would make it more difficult for my team to grow and change. But I now believe that it is actually much harder to iterate and improve upon the way a team works in the absence of formal rules and processes. This is particularly true at high-growth companies, where informal practices that work well for small and close-knit teams can become toxic and destructive as the company grows. Something as amorphous as “culture” can be very hard to act upon, but formal rules and processes provide leverage points that can ultimately have a profound effect on deeper systemic issues.

Spotify has built this idea into the very structure of their organization, devoting an entire team to auditing and updating internal processes. When they change an internal process, they clearly communicate both the specific procedural changes they are making and the results they expect to see. If, after a period of time, they realize that the rule is not working as intended, they clearly communicate the difference between what they had expected to see and what is actually happening. Each new rule is given a chance to succeed or fail, and the lessons from its success or failure are reinvested back into the organization.

You don’t need to be a well-funded organization helmed by process-inclined Swedes to see and feel the benefits of this approach. Several years ago, thinking through the intended and actual results of a procedural rule helped me understand why my team’s daily stand-up meetings weren’t working as I had hoped. The intended result of these meetings was that engineers would get unblocked quickly, but the actual result was that engineers were putting off discussing new blockers until the following day’s stand-up. I now recommend to many organizations I work with that they forego the daily stand-up entirely, and instead create a clear expectation that anybody who is blocked on a specific task will reach out directly to the relevant team members as soon as they can.

And here’s the great thing: sometimes this works, and sometimes it doesn’t. Some teams take to this approach immediately, while others realize over time that their particular product or team structure makes it too burdensome or complicated to communicate blockers without a daily stand-up. It doesn’t really matter which approach a team adopts first, so long as they stick to it, pay close attention to what works and what doesn’t, and change the rules rather than breaking them. I used to get defensive when folks I work with would say “we tried the specific thing you suggested, and we realized that we need to change it.” Now my response is usually a sincere and heartfelt “congratulations.”’