I recently had the opportunity to talk with Blake Thorne on The LaunchNotes Podcast. I think I’m a little rusty with the speaking thing, but I did have a lot of fun here. We covered a bunch of topics, including how people got into product management before Inspired was published, how to enable autonomy and ownership in product teams, the value of writing and publishing what you learn, and also somehow… my favorite kettle. Give it a listen if you’re into that sort of thing!
Product Management and The Fog of War
I think about The Fog of War in the context of product management often. The term started as shorthand for an important concept during battle:
The fog of war is the uncertainty in situational awareness experienced by participants in military operations. The term seeks to capture the uncertainty regarding one’s own capability, adversary capability, and adversary intent during an engagement, operation, or campaign.
Of course, most of us of a certain age know this concept mainly from video games where it refers to enemy units, and often terrain, being hidden from the player until the area is explored. Here’s an example from Command & Conquer: Red Alert 2:
This concept—both in its military and gaming contexts—can be really helpful to guide our thinking about planning, prioritization, and execution. Let’s first look at the original meaning, and how the 3 uncertainties of the “fog of war” can effect our decision-making on planning and prioritization:
- The uncertainty regarding one’s own capability. We are often worried that what we build might not be good enough to win over customers.
- The uncertainty regarding adversary (competitor) capability. We are often worried that competitors might build something faster and better than we would (ChatGPT, anyone?) and that it will destroy us.
- The uncertainty regarding adversary (competitor) intent during [a project]. We don’t know what our competitors are planning to build next.
These uncertainties can sometimes paralyze our decision-making—or worse, lead us down a path of making decisions based on our fear of the unknown. When we go into our planning cycles we have to make sure that we act only on what we know about our business and our users, and the information we have available to us. We cannot let the fog of war derail us to make prioritization decisions out of fear and uncertainty of what others might do.
That leads into what we can learn about execution from the gaming context of this concept. When I talk to our teams about project plans I often refer to our planning documents as “a road sign into the fog.” I encourage teams to make sure the direction and first few steps are known based on the information we have, and then to add and edit their plans as the fog starts to lift.
At Postmark we use a project plan template that you can view on Github here. I’ve written about this document a couple of times (see here and here), and the most important principle we live by is our commitment to these plans being “living documents”. We don’t fill out the whole thing up front (there’s too much fog out there!), we host it in Google Docs, and everyone on the team has full edit access. We truly work on it together—and as the fog lifts, we keep editing until we feel comfortable with the level of uncertainty that remains in the system.
The next time you enter a planning cycle I encourage you to think about the fog of war and how it might be influencing your decisions. When are you guided by uncertainty, despite all the things you do know about your business and customers? When are you trying to map out areas that no one has explored, and that you simply don’t have enough knowledge about yet? How can you focus just on “the next right thing” and trust that as you go, the fog of war will lift, and the road will become clear?
How your product is discovered and adopted is part of the product
Shift left on go-to-market to build better products is a great post by Frank Tisellano on why product managers have to consider Go to Market efforts while they are still deep in the understanding/planning phase of a project:
Great PMs recognize that building a good product is table stakes and that the way to truly differentiate themselves is by taking a strategic approach to how customers or users find and adopt their products.
In other words, great PMs shift left on go to market, considering and developing their distribution strategy while they’re still prioritizing problems to solve, long before a PRD is written, let alone a line of code.
He goes on to give some practical tips—and examples—on how to make GTM a bigger part of the PM process.
Hyper-growth, and the power of doing more with less
David Poblador writes about The Pitfalls of Hyper-Growth: How Companies Can Do More with Less. Startups tend to operate more with a scarcity mindset at the onset, but as they grow…
As businesses grow, they often rely on flawed indicators of success that do not necessarily correlate with sustainability. One of the most common measures of success is headcount growth. Unfortunately, hiring lots of new employees can create inefficiencies, harm company culture, and reduce productivity. When hiring becomes the only tool to get the job done, it can detract from the most important things, like focusing on priorities and managing the company’s lifecycle.
David’s post led me to a fascinating interview with Jesper Kouthoofd, who is the founder of music-tech company Teenage Engineering. In the interview he talks about why they specifically avoid running after hyper-growth:
We only want to make great products and when you don’t focus only on making money and have reached a certain level, everything becomes about quality. Right now, there is a certain cultural fascination with fast growth, IPOs and so on, but I want to go slow, really slow and think long-term. It takes time to do good things. You see, this cultural phenomenon of speed and growth at all costs is displayed in every startup, they all look the same, it’s like fast food: it looks good, its taste is consistent but then you feel horrible afterwards.
This is obviously not desirable or true for all companies, but it’s worth noticing that there is more than one way to run a business.
Taylor Swift, Fender Guitars, and Product Management walk into a bar
I recently came across two articles that combine the topics of music and product management. That is basically catnip for me, so I have to share.
First, I know “What X Can Teach Us About Y” articles have become a bit of a trope, but trust me on this one. What Taylor Swift Can Teach Us About Business by Rex Woodbury is an excellent case study on what good product management is all about. I’ve always been impressed by Taylor’s business strategy, and this is the first article I’ve seen that really digs into it. On Taylor’s decision not to sign with RCA because they wanted to pigeonhole her into being a country singer:
The key insight here is that RCA underestimated the market. Yes, country listenership was declining among young people. But great products revitalize stale markets and ultimately expand their markets. Swift did both, first proving that there was an opportunity in country music, and later growing beyond country to become a bona fide pop star. Swift’s story reminds me of a fatal error in startups: underestimating market size.
There’s too much goodness to quote here, so just read it.
The second one is an older piece that I found via Jeff Gothelf’s blog. It’s an interview with Fender CEO Andy Mooney on the company’s mission, and once again it showcases some excellent product management principles. In the example below, Andy talks about the creation of the Fender Play app. I am breaking the quote up with some of my notes, since it encapsulates the process so well:
The marketing is tied around creating the emotional connection, being ‘why should I do this?’.
Note the focus on Jobs to be Done. Their research showed that people pick up the guitar mostly because they want to play and sing along to their favorite songs—not because they want to be rock stars. That’s the emotional connection they are going after.
Again, with Play, we felt that it was a milestone to get people to commit if they were able to master their first song. So we teach the skills that you need in Play around doing exactly that. You come into the product, you declare your genre and that gives you a potential setlist.
Note here how they identified their activation metric / a-ha moment and built the product around getting users to that moment as quickly as possible.
Then you get taught the skills to master those songs rather than the other way round. I taught when I was very much younger. You know, are you going to teach somebody to play major minor scales or are you going to teach them how to play House Of The Rising Sun? My approach—which I’m glad was all intuitive back then—was a song-based approach because you were teaching them how to play the chords within the context of the song.
Again, note how they focus on the how music makes you feel, not on the theory behind it. We are all used to this kind of marketing now but it’s worth remembering that until the iPhone came along, phone marketing was all focused on storage space and RAM, not on here’s what you can do with it.
There’s much more in the article about the extensive customer research that Fender did, and how they used those insights to create Fender Play.
Link roundup for March 18, 2023
This feed of imagined alternate universe tech products is mind-bendingly wonderful.
Employees Are Feeding Sensitive Business Data to ChatGPT. Feels like this should be a bigger story. “Employees are submitting sensitive business data and privacy-protected information to large language models (LLMs) such as ChatGPT, raising concerns that AI services could be incorporating the data into their models, and that information could be retrieved at a later date if proper data security isn’t in place for the service.”
How companies can better understand neurodivergent employees. Good reminder: “If you use closed captioning, text messaging, or noise-canceling headphones, or have pushed a stroller or ridden a bike over the ramps at the end of sidewalks/curbs (see the curb cut effect), you’ve benefited from design that prioritized users who had these needs but are not the convenient ‘majority’ for whom many products are designed. Designing for difference enables innovation and productivity while setting up an enterprise to be future-fit and successful.”
I needed to hear this, so I’m sharing just in case you might need to hear it too: “When we have a lot on our plate, we tend to neglect the very things that equip us to handle having a lot on our plate. We leave aside exercise, which is important for physical and mental health. […] Leaving out our health to fend for last place in our list of priorities is bad enough. However, doing it when you most need your health to contend with a growing list of priorities is worse still.”
This latest Amazon forced “return to office” news is bleak. “The fact that Amazon’s S-Team did not blink, and refuses to soften the return to work policy signals that they either don’t expect much attrition, or have calculated with additional attrition. […] At the same time, looking at the market, it’s hard not to ask the question: if people want to leave, where will they leave to?”
Chat apps are no substitute for documentation. “Chat apps like Discord [and Slack] end up diluting the available knowledge because the content shared in them isn’t persistent, and the allure of an always-available answer breaks down when the person that could answer is no longer available.”
Modern Font Stacks. System font stack CSS organized by typeface classification for every modern OS. “No downloading, no layout shifts, no flashes — just instant renders.”
In The Name of The Father provides a fatherhood lens on the first season of The Last of Us that really resonated with me.
The new M83 album is out and it is, in my opinion, a return to form. On repeat over here.
Authentic leadership is about getting in the trenches with our teams
Here’s an interesting take by Sheril Mathews on why people often don’t trust their managers, or find them inauthentic:
Managers don’t come across as authentic because more often than not they don’t have an intimate understanding of the day to day realities of how their teams actually get work done.
Sheril goes on to discuss some some great advice on how to show up for our teams in authentic ways (spoiler: it’s about getting our hands dirty in the trenches). But I also wanted to share this 1973 (!!!) quote from Henry Mintzberg in The Nature of Managerial Work, because it really stopped me in my tracks:
The prime occupational hazard of the manager is superficiality. Because of the open-ended nature of the job and because of the responsibility for information processing and strategy-making, the manager is induced to take on a heavy load of work, and to do much of it superficially.
Hence the job of managing does not develop reflective planners; rather it breeds adaptive information manipulators who prefer a stimulus-response milieu.
Sheril’s article—and that quote—is inspiring me to take a real hard look at my own work, and where there could be opportunities to weed out the “superficiality”.
This is a bit of an addendum that I think is valuable enough to add here. I shared the above Mintzberg quote among some friends and the discussion ended up being really interesting. Vince pointed out that as for the assertion that superficiality is an inevitable outcome of management, he prefers Russell Ackoff’s take from 6 years later. Here’s what he said in 1979:
Managers are not confronted with problems that are independent of each other, but with dynamic situations that consists of complex systems of changing problems that interact with each other. I call such situations messes. Problems are abstractions extracted from messes by analysis; they are to messes as atoms are to tables and charts … Managers do not solve problems, they manage messes.
Pete (who I’ve been begging to start a blog, please go yell at him as well) also went the less cynical route with his comments:
As you move up the levels of a company, you move to higher levels of abstraction. Every level takes the output of the level below, and distills and summarises it, passing it up. It also takes direction from above and tries to nudge the processes below in that direction.
I think that’s the just way it is, the way it has to be. I can’t think of any examples where a different model has been applied successfully at scale.
The key to this working successfully though is to make sure that information is correctly analysed, distilled, summarised and communicated at every level.
The problem with superficiality is not abstraction. It’s dillution. If you throw away the good parts and keep the wrong parts when summarising, the system starts fraying. And you’re setting those above you up for making the wrong decisions, and thus setting up those below you for failure.
How to help our managers work with us more effectively
I’m sure we’ve all seen those “here’s how to work with me” documents (and the controversies around them), but I like this slightly different take. In her post 9 Managers in 4 Years: Creating Continuity in Chaos Genevieve Conley Gambill shares a framework for helping our managers understand our skills, our work, and our career goals:
- Foundation – What are my unique strengths and capabilities?
- Trajectory – How do I view my current role and performance?
- Aspirations – What am I working towards in the future?
- Support – What do I need to adjust or build on to get there?
She also shares a great Google Doc template with more details. The post goes into more detail on each section of the framework.