War and Peace And Product

In business as war, Product Managers are the consummate sergeants.

We are duty bound to help our fellow comrades understand and solve the current problem at hand, leading them through to victory. We are obsessed with efficiency of execution, opportunity and its capitalization therein. We love to lead from the front, and the best of us likewise love to have our boots muddied and body scraped with the same badges of warfare our teams bear.

Tactically, we excel: most of us strive to get the job done, done fast, and done well — rapid learning and pivoting and survival: our orders; JIRA and database queries and whiteboards: our weapons.

And yet, for all our talent in applying these skills to our business’ output, we generally struggle to apply these principles to the business, and our business, itself. We rarely rise above the roar of action to organize ourselves more methodically for the greater theater of war playing out above the trenches we too eagerly toil in.

Lead from the front though we may, we oft forget to or, more frequently, fail to command from the back. Sadly, in matters of war and scale, this is a fatal weakness, as with scale, as war, there become too many fronts to fight on effectively. And in that weakness comes failure: to grow, to evolve, to continue to succeed as a team, a unit, a business.

These observations are drawn from my own frustrated floundering, as I myself wade through the parallel, metaphorical war I draw parallels to in pursuit of the general’s stripes.

Having gone through a fair term of boot camp, I’ve sullied and subsequently cleaned the shit off my boots at companies small and large, and I long to apply those lessons in more direct ways than to pen reports left unheeded by my commanding officers.

I wish this if only to help those I’ve fought with avoid the trench warfare which we’ve become all-too-acquainted.

As product companies grow in number, and the role becomes more mature, the challenge of scaling a product organization has become a more palpable one.

And so, with great optimism, I find myself gazing upward towards rank as I polish my boots, only to be moments later downcast by the stubborn realization that scaling up a product department is hard as— well, as Sarge might say, a pair of young boys with a Sears catalog.

Strategy vs. Tactics

Why the grim outlook? Chalk it up to some rough tours of duty.

As a sole product manager, or one in a very small group, it’s easy to act in the business’ best interest and remain effective. Divvying up the massive amounts of analysis, preparation, and decision-making into large, meaty chunks is relatively easy when you’ve but one lead and one set of troops to execute on larger skirmishes in isolation.

Prioritization is likewise an easier task: with only one execution funnel, it’s pretty simple to assess what will have the biggest impact whilst managing cross-team dependencies, and the inevitable challenges of cross-team communication, are non-issues. Kill the biggest, toughest guy first and then work your way down, you might say.

But once you have multiple platoons, and multiple sergeants, there emerges a game of thrones that too often goes played improperly, resulting in catastrophe.

In service of solving this problem, the many companies I’ve soldiered for have tried many different takes on how to organize a group of product managers and teams.

For the most part, these can be generalized into a singular approach: separating product management from product ownership or, in other words, separating the job into two, the strategic vs. the tactical.

Ultimately, this strategy is informed by the desire to have the tactical “owners” play the role of the sergeants — fighting in the shit directly with the teams, focusing on execution, and ensuring that no one dies along the way — while the strategic “managers” assume the rank of officers — looking beyond the immediate skirmishes to the bigger battles on the horizon; fretting not about implements but about positioning and timing; pouring over key strategic analysis and investigation necessary to avoid costly mistakes of leadership.

On paper, this strategy is sound, and in war and history, this strategy has proven successful time and time again. Establish a hierarchy, organize by rank, order from top-down, and bang, victory, yes?

Well, no. In the heat of battle, as modern war has shown us, hierarchy without execution excellence, without tactical consideration and context of the battle belied by the board’s game, often creates more tension and turmoil than it avoids.

Particular to product, asking the sergeants to go to war with no knowledge of the greater strategy is futile: tactical product owners need just as much business context as the would-be strategic product managers.

Trying to separate the role results in the “product owners” lacking critical context necessary to make good tactical decisions while “product managers” are distracted from tomorrow by the immediate fires of the here and now and subsequently do both jobs poorly.

As a result, like too many of our parallel forefathers and mothers, too often these product owners find themselves surrounded without the information needed to survive.

The Chain Of Command

So why, then, do so many companies try this approach fruitlessly?

I think at the heart of the decision stems an allergy to process and particularly the kind bound to autonomic decision-making necessary for effective tactical execution.

Process is largely a dirty word in a lot of product organizations, particularly engineering-centric ones. The general consensus seems to be that process equates to overhead and bureaucracy, which is in direct opposition to the notion of agility which drives modern-day product development (and is used for recruiting and retention, importantly, therein).

But process-driven development and waterfall are not synonymous, nor does process automatically inhibit innovation or stymie progress.

Good process should ensure that needless churn, needless cross-team “collaboration” (read: multi-hour meetings), and needless “design by committee” (countless stakeholders all of whom need to nod in agreement before executing) can be avoided. It, by design, speeds up execution — or, at least, it should.

Good process should streamline decision-making by identifying key artifacts and key decision-making frameworks which alleviate, rather than rely on, bottlenecks and result in a traceability that prevents both repeat mistakes and mid-execution interruptions.

Process, done right, is not for the managers: it’s for the executors. It should simplify execution, and it should enable teams to make autonomous decisions on lower-level, tactical matters without requiring the overhead of a chain-of-command. It should remove the friction of approvals, eliminate “running up the flagpole”.

And it’s there that the war analogy falls apart.

Admittedly, the thin red line separating a decision which is purely tactical from that which affects the strategic is blurry at best, and that’s where the classical definition of the chain of command falls apart.

Separating product owners from product managers fails because it leans too heavily on privileging strategy over tactics, on top-down management over bottom-up execution, on theoretical outcomes versus actual output.

Ironically, it is this stubborn complacence with the chain-of-command which unfortunately grinds our war machine to a halt more often than not.

The separation of duty, strategy from execution is misguided and simply does not work in the wars we fight. In our wars, seargents and generals need the same information; indeed, the distinction in this light is counter-productive.

Inevitably, tactical POs try to make decisions and fail, which results in a bunch of overhead requiring PMs and POs to constantly collaborate.

In short, this distinction prevents informed, autonomic, tactical maneuver based on information at the ground level without clearance from above — and that makes it not just pointless but in fact dangerous.

War Time vs. Peace Time

How, then, do we focus on the battle at hand and the greater war at large in tandem, then?

Doing so, I believe, requires re-defining what the “war” is in the context of product management and product development.

In my experience, the metaphor of war is really only applicable to the immediate release at hand. With that in mind, product managers become both sergeants and generals: they lead their army tactically and strategically, but they do so as “War Time” PMs.

The first version of a product is the war, as an example. It’s not a battle in the greater war on the product. No, version 2 is War II, and as such, the decisions for War I should be made entirely in the context of War I: for if you lose War I, there will be no II.

There exists an entire other body of work and thinking to be done, though: the long-term visionary work — the opportunistic assaults of tomorrow and the campaign-defining battles of thereafter.

I think, then, the better way to delineate work between two product managers in pursuit of scaling a product org is to instead cast the two as a “War Time” PM versus a “Peace Time” PM.

This may seem like a simple rebrand “strategic” vs. “tactical”, but I think there’s an important philosophical, and role-defining, distinction which makes all the difference.

War Time

In war time, say during an important customer delivery or a product migration, War Time steps in to take a given bit of product work right into the front-lines and ultimately to victory.

This PM prioritizes tactical work with a mind for the greater strategy at large, but if tasked with a decision to accommodate tomorrow’s battle at the behest of today’s skirmish, he or she will always strive for the most immediate win. He or she does so amongst his other War Time PMs, acting in the best interest of the war at hand.

This approach ensures that progress continues to be made in pursuit of immediate victory. Saving rations for tomorrow’s fight is pointless if today’s result is death.

Furthermore, War Time PM himself or herself must be entirely combat ready: he must be fully capable of surviving and thriving in trench warfare while paying heed to the greater game of chess playing out around him. He can’t simply forgo the fact that his immediate, tactical decisions affect the today’s of his peers in other platoons — and that’s a key element of War Time’s role.

Peace Time

In parallel, Peace Time can focus on the peace time tasks. He or she focuses on the far future, thinking about analytics and optimizations, dealing with the diplomacy of tomorrow’s battles (like external customer meetings for future releases).

Importantly, though, he or she does so without too much concern for how War Time is faring, thinking more on the business requirements or problem and the over-arching strategy than the nuances of implementation.

The key distinctions now come in to play, as we need to reconcile the two roles: how and when do Peace Time and War Time debrief? Over time, Peace Time will inevitably become out of touch with the realities of war that War Time had to accept and accommodate.

The missing piece of process here, then, requires Peace Time and War Time to debrief before and after switching times.

In times of peace, say right after a version has launched, War Time can focus on helping Peace Time understand and clean up some of the aftermath of the necessary tactical decisions while preparing for the next bout of war time.

(Of course, inevitably, there rarely exists a true “peace time” in our wars. And so, I think the last bit of organizational design is to rotate PMs in and out of the role of War Time.

In service of avoiding a single point of failure, PMs should be spreading knowledge and niche amongst one another, anyway, and no PM (nor team) can handle endless war time. This also ensures that every PM is equipped to handle both times.)

A War Of The Roses By Any Other Name

Admittedly, the distinction between “strategic vs. tactical” and “war time vs. peace time” may not read as clearly as it feels it would be when in the fray, but then, neither must the idea of taking orders from some officer thousands of miles away behind a computer for those of our soldiers on the actual front.

I think there are important differences, though:

Allowing War Time the complete autonomy to decide what’s right for today’s battle is something that simply isn’t common — at least where I’ve been.
Aligning War Time’s teams to the execution approach of War Time vs. Peace Time (which requires a great deal of institutional conditioning and acculturation; boot camp?)
Ensuring War Time can actually fight in the trenches, including demonstrating competency in the weapons of the war at hand (e.g., the APIs, UX, and tech stack fulfilling the marching orders)
Ensuring War Time can understand the larger battle strategy (e.g., where his fellow PMs are and how they’re fighting) and can make sound tactical decisions with all fellow platoons in mind

These are the key things that I think separate the too-simplistic (strategic vs. tactical) approach oft taken from one which may have a better chance to succeed.

Then again, these could just be the weary ramblings of a tired old sergeant who sits, pen and pad in hand, trying to make sense of a war that seems unyielding. Scaling a product team is hard, and the chain of command has existed, designed by smarter men for bigger wars.

Perhaps I’m naive to question it.

I’m left only to hope that, one of these days, in one of these wars, maybe I’ll finally make rank. ‘Till that day, though, back to the suck.