On Process

John Cutler recently published a nice piece “In Defense of Frameworks (and Process)". And some defense is indeed in order, as the very idea of structured, well-documented, repeatable processes has suffered quite a few attacks over the previous decades: They’re too heavy, they stifle creativity, they diminish an organization’s ability to respond quickly to change, they’re not agile. But let’s not throw out the baby with the bathwater: To “learn, collaborate, and lighten cognitive load”, as Cutler puts it, are great reasons to install frameworks and processes in the first place, as are increased transparency, predictability, and involvement. So, can one gain at least some of the benefits without incurring all of the detriment?

One the one side, it’s sad but not uncommon for processes or frameworks to get in the way of actual work actually getting done. Either because all that upfront conceptualizing and theoreticizing sucks up too much time and energy, like a flame that consumes all the oxygen in a room, or because we mistake rigidity for clarity and end up defining guardrails so narrow that there’s no space left for creativity, improvisation, and learning. Especially when forcing highly educated, motivated, and well intentioned individuals to adhere to what is ultimately someone else’s idea of how they should do their jobs, we rob them of a great deal of autonomy. And here comes the catch that concerns me most: Product-led companies in particular are at risk of that when they try to standardize how they make strategic, product-related decisions: What starts out as a well intended effort to increase transparency and stakeholder involvement can quickly escalate into a bureaucratic behemoth which takes away all accountability, and thus all sense of ownership, from your product managers or product owners¹.

But, as Cutler also points out, well defined processes are great sources of guidance and clarity. Their mere existence helps reduce the cognitive load each individual has to bear by creating certainty about who will do what at which point in time, which artifacts will thus be produced or consumed, and which decisions are being made when and by whom. The benefit of that transparency can hardly be understated, but I believe it can be attained whilst retaining your product managers’ sense of autonomy and responsibility.

But let’s first look at a process which, in many organizations, is the high water mark for structure and clarity: Hiring. I can think of very few things that companies are more eager to standardize, because (a) hiring typically occurs often and regularly and thus benefits from a solid level of replicability, and (b) transparency is highly important so that the applicant, as well as the hiring manager and everyone else involved know what’s going on. Thus, your typical hiring process looks pretty much like this everywhere:

The process itself makes it totally clear who’s in charge, which documents are required, and which decisions are made at which point.

Of course, that level of transparency would also be appreciated when it comes to how strategic decisions are being made, especially which features make it onto our product roadmaps or at which position they land on our backlogs. But in many product organizations, that process seems more like a chaotic black box: Everyone deposits their feedback and ideas with the product managers, but what they chose to do with it is often completely opaque:

Having spent a good deal of my career inside that box, I can attest that there’s in fact a lot going on in there: The interdependencies and anticipated cross-pollination effects between the inputs alone are endless. Layer on top of that personal experience and expertise, technical and organizational constraints, market, competition, strategy, mission, vision, and… turns out, prioritization done right is much more of an art than a science. There’s a certain kind of creativity involved here which can never be formalized entirely. Countless efforts have been taken to prove the contrary though: I’ve worked with many variations of frameworks and scorecards over the years, but found none which actually got the job done entirely. Even worse, if we force these things onto product managers who are used to a great deal of autonomy, we may actively encourage their use primarily as means for rationalizing their pre-existing opinions rather than as useful tools that guide actual decision-making.

Nevertheless, there are some things that we can do to increase transparency and build trust that the right decisions are being made.

Cadence

A simple one is to clearly articulate the cadence in which the output artefacts, e.g. the backlog or the roadmap, will be updated and where these things can be found. Even if you let all the decision-making reside in the black box, at least your stakeholders can trust that plans won’t change at random but rather every sprint, every month or every quarter, and that they have a way of keeping up to date.

Involvement

On top of that, I found it helpful to create transparency about which inputs went into the black box in the first place. For example, you can make your sources of market or competitive intelligence, as well as the analysis you base on them, open and accessible to everyone in the organizations. Even better, solicite contributions from other departments in crafting these things: Sales, for instance, can be a great source for competitive insights or win/loss analysis, as can marketing or customer success. By turning these stakeholders from passive consumers into active contributors their buy-in into the whole process can greatly improve.

Participation

Finally, you might ask, why not simply survey your stakeholders about what they think is important? No doubt that’s a good idea, but there are two obvious pitfalls: (1) Do it in a structured and collaborative way. Of course it’s nice to have a coffee chat with someone from sales about whether they find feature A to be more valuable than B, or vice versa. But doing that, you run the risk of misinterpreting anecdotal evidence for empirical facts: That sales person might not be as deeply into the topic as you are and thus may give you an uniformed or biased opinion which can end up doing more harm than good. And regardless of whom you ask it’s always their personal opinion, not the voice of the entire sales team.

Hence, try to create an environment in which they can evaluate the options they’re presented with in depth, have a chance to collect additional opinions and data, and then make up their mind. Provide them with the facts, give them time, and make clear in which way exactly you want them to provide feedback. A simple way to do that which I found useful is to prepare a list of possible features, each described in the same format and in the same granularity, and have the stakeholders rank them individually according to their respective ideas of what’s more important than what.

And (2), make it absolutely clear that their input, in whatever shape you decide to request it, will be a major part in your decision-making, but that the decisions themselves will be taken by someone else. It’s quite easy to mistake being asked for your opinion with being asked to make a decision, particularly if you want to believe in the latter.

Processes and frameworks are a thorny topic almost everywhere you look. But the challenge of balancing the autonomy of individual contributors, such as product managers, with transparency and clarity does stand out particularly in product-driven ones. The decisions we make as PMs can hardly ever be quantified or explained in complete detail. And even if, they would still remain controversial—that’s nothing more than part of the job. Nevertheless, to attain stakeholder buy-in we have to establish trust that the right decisions are being made. That does not mean to offload our responsibility or autonomy, but to involve others in a structured and transparent way—using, you guessed it, processes and frameworks.