If you’re a fellow IT-savvy millennial, I’m sure you also fondly remember the disk defragmenter utility that used to come with, like, Windows 98. Source: The Bleeping Computer Long before cheap solid state disks became ubiquitous, it was a common performance issue that, over time, the data on your hard disk became scattered all over the place. When you wanted to access a certain file, the magnetic heads of the disk would then have to (mechanically!

I’m a big fan of making things as simple as possible, but not simpler. As many of those witty quotes, this one is also frequently attributed to Albert Einstein, even though it’s unlikely he said it in quite those words. Nevertheless, he was surely on board with the meaning: Every idea, every concept, every argument can in principle be reduced to an essence, but one that’s often padded with a lot of fluff.

Product management is likely to be the most cross-functional discipline of them all. Conceptually, we’re trying to align desirability ("What does the market need?"), feasibility ("What kind of solution can we realistically build?"), and viability ("How do we make this a profitable business?"). That part of the job alone necessitates broad knowledge across a variety of fields, as well as a reasonable amount of depth in each of them.

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.

When I talk about strategy, particularly product strategy, and particularly to engineers, I like to start with a picture that looks like this: My goal here is to draw their attention away from what usually comes to mind about planning and prioritizing: Which features are on the roadmap and which aren’t? Where’s that issue ranked on the backlog? Will this enhancement request make it into the next sprint?

At an all-hands meeting earlier this week, I ran a little experiment: I polled the assembled engineers to find out how many of them felt that they had a solid grasp on the workings of our business model. Guess what? Not a lot of hands went up. But if I had turned around and asked the sales teams how familiar they felt with the architecture of our software products, I’d probably gotten a similar result.

In biology, there’s a concept called homeostasis: Living systems seem to effortlessly balance differences between internal and external conditions in order to remain within their existential boundaries. The human body for example maintains an almost constant core temperature through sophisticated heating and cooling processes, and thus manages to keep us alive and flourishing in a wide range of environments. Social systems on the other hand don’t come with such built-in regulatory mechanism.

Conflicts, especially within organizations full of smart and well-intentioned people, often turn out not to be rooted in substantial differences at all. Much more often, minor misunderstandings are what actually wreaks havoc on our ability to collaborate. Yet, the consequences can range from a diffuse sense of constant irritation to an unnecessary proliferation of endless clarification meetings. I therefore believe that precise communication is an organizational superpower, just as much as a lack thereof can quickly poison a company’s otherwise healthy culture.

Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors. To be honest, I’ve built a lot of terrible roadmaps over the years. Some resembled Gantt-charts and came with work packages, milestones, and deadlines. Unsurprisingly, these created an unjustified sense of security and commitment. Others were too lofty and vague, needed lots of explaining and still left behind confused and irritated audiences. I came to try various formats and templates, adapted and tinkered to address some of these issues, but I am yet to uncover the holy grail of roadmapping.

Back in the day, I once attended a big software conference somewhere in Germany. As chance would have it, I struck up a conversation there with an agile coach who was working for a big customer of the product that I was serving for as Product Owner at the. During the course of the event, we would occasionally bump into each other again and chat about our respective challenges: Me, shepherding a medium-sized product team at an international software conglomerate, and him leading the agile transformation of one of the most stereotypically conservative organizations in the world: The federal government of Germany.

Middlemarch by Mary Ann Evans (aka George Elliot). “Surely,” said Dorothea, “it is better to spend money in finding out how men can make the most of the land which supports them all, than in keeping dogs and horses only to gallop over it. It is not a sin to make yourself poor in performing experiments for the good of all.” — Mary Ann Evans (aka George Elliot), Middlemarch (1871)

“How long will this take?” is a tricky question. Most of us are terrible at estimating which is why organizations often make decisions based on either wildly inflated guesses, or wishful but unrealistic thinking. Furthermore, estimating itself takes time and binds resources that we could invest in actually doing the work instead. Intuitive Prediction by Daniel Kahnemann and Amos Tversky. Advocates of the #noEstimates movement argue that it is in fact possible to get the benefits of estimating without having to pay the (full) price, and they get a lot of traction these days.

In many instances software architecture is less a product of deliberate design and more an accidental result of countless interactions between people. Or, as Eric Raymond put it more pointedly: “If you have four groups working on a compiler, you’ll get a 4-pass compiler.” How Do Committees Invent? by Mel Conway. This idea was originally introduced by Mel Conway in his 1967 paper “How Do Committees Invent?

I once was given advice by a senior product manager that toppled one of the fundamental assumptions I had held about the PM role. What he said was: “Don’t go down with your products.” I had intuitively thought of the PM as the proverbial captain who is supposed to go down with his ship (at least as far as popular opinion is concerned) but what my colleague suggested sounded more like an invitation to opportunistically hop from one product to the next, jumping ship whenever things started to look dire.

I once worked for a manager who would send his employees home by 5:30pm every day. This was at a time and in an environment where looking productive by working at all hours was not only prized and honored, but to some degree even expected by upper management. His argument for limiting the amount of time people should spend in the office was rooted in a different mindset though: He rightfully insisted that nobody produces outstanding results while being exhausted and overworked.