Sometimes navigating life’s complexities can feel a bit like wandering through an unfamiliar landscape in the dark. You know—vaguely—where you’d like to end up, that is, you have goals you want to achieve and aspirations you’re striving for. But if they’re ambitious enough, it’s not clear exactly what path you need to take to get there. You also have—at least intuitively—a general sense of direction; you have moral and ethical values, behaviors, and attitudes you consider right or wrong, which give you guidance on an abstract level. But for me, neither goals nor values are specific and actionable enough to help me make better decisions every day. Yet life constantly challenges us with immediate choices, big and small, that need to be made: Turn right? Turn left? Go uphill? Go downhill? Each small action (or lack thereof) can have a profound impact down the road on us and the people we care about. But as uncomfortable as it can be to take decisive action, we need to choose thoughtfully and with intention—or else, others will make choices for us that may not always be in our best interests.

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!) move around like crazy, tremendously slowing down the reading process. Defragmenting counteracted that by re-ordering the bits and pieces of information on the disk, so that data which was frequently accessed together also was physically stored next to each other. During the defragmentation process itself, your computer was pretty much unusable—and it sounded like it was munching on pebbles. However, the hassle was well worth it, given how much smoother the whole system ran afterwards.

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. For the sake of clarity, you should therefore strive to strip away as much of that packaging as possible. But the catch is: This essence itself is ultimately irreducable. Try to make that even simpler and the idea loses its meaning and its value. Hence, the key question becomes: What’s the essence?

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. But that’s only one side of the coin.

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?

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? And so on, and so forth. Questions like these do of course matter. But when we’re focussing too much on tactics (and think that we’re “being agile” by doing so), we’re in danger of forgetting the big picture. Consequently, our products will start resembling a hodgepodge of bells and whistles, with seemingly arbitrary features attached here and there but lacking a coherent narrative. Customers und users will be confused, and thus have a hard time trusting that we’re on the same page as them. Our teams will miss clarity and direction and will, rightfully, complain that they’re unable to make any long-term decisions. So, we need something that can help us tackle more forward looking questions: Why are we actually doing this? What are we trying to achieve here? How will we know if we’re on track towards our objectives?

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. Same thing for sure had I questioned the marketers about their understanding of our contracts, the support team about our revenue and cost structure, or the CEO about our cloud deployment model.

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. Tensions between individual employees, different teams, or entire companies and their shareholders, partners, and customers, rarely resolve on their own. Much rather, deliberate effort has to be invested so that the forces at play don’t pull an organization apart. And that, in my view, is one of the key elements of leadership, regardless whether that’s formal or informal, and independent of the hierarchical level at which it occurs.

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. Be aware that Product Roadmaps Relaunched also offers no such silver bullet, nor does it provide a single, correct, gold standard roadmap template that everyone should use all the time. But had I stumbled upon the book already when it first came out in 2017, I might well have avoided a few unsatisfying sidesteps.

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. An interesting real-world example that shows how #noEstimates can work comes from a team at Adidas runtastic which dropped estimations while still being in tune with a company-wide OKR system.

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?” and has since turned into what is now known as Conway’s Law:

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. It’s often more beneficial to let go of a pressing issue for the moment and coming back to it after a good night’s sleep, a relaxing walk, or a workout.