TBM 250: Dear Executive...

Celebration: The 250th TBM! Help me celebrate by sharing this post. This is the first post I’ve written that is MEANT FOR SHARING. I wrote this post for you—product nerd and general fan of the mess—to share with an executive at your company. Product development isn’t their main jam, but they’re whip smart. They’ve watched you make a fool of yourself trying to explain modern product development. They may have said, "Sounds interesting…" but you've received feedback that "the message isn't landing." The books you’ve sent them are lonely in their bookshelf.

Let me try to help. PS: there’s a lesson in here for you as well.

Dear Executive

I am writing this post on behalf of [Your Name], who sometimes sounds like a crazy person. They might as well be John Nash at the chalkboard in A Beautiful Mind. You can't figure out what they are talking about and advocating for.

I'm writing to ask you to give this person another shot.

I've been this person (the John Nash character) and have learned several things over the years. Heck, I battle this to this day—just yesterday, even. I also know a decent amount about high-performing teams in many different contexts, so I speak with some authority here.

One of the key problems is how experts perceive tradeoffs. Let me explain with this post.

Thanks

John

---

Ask an everyday driver about driving tradeoffs, and you'll likely hear something like, "When you go around a corner, you need to trade off speed and control." The mental model is "slow down just enough to keep control around the corner."

A professional driver will think differently. Their mental model revolves around tire grip and temperature, the optimal racing line, throttle control, suspension, aero settings, brake balance, tuning the car for the track, and weight transfer management. They might point out that the amateur isn't exactly wrong, but they might say, "At the end of the day, it boils down to tire friction, aerodynamic limits, mechanical limits, and human limits."

Telemetry from two drivers on the same course.

Amateurs aren't entirely wrong; they're recognizing some inherent limitations. What differentiates professionals is their ability to approach these limits more closely and consistently without exceeding them. They have a deeper understanding of where the boundaries are and how to navigate them. 

I was thinking about this recently as it relates to product development. As you gain experience, you start to view tradeoffs in different ways. A classic example:

• Beginner: There's a straightforward tradeoff between quality and speed. If you want to produce something quickly, you need to sacrifice quality and vice versa.

• Intermediate: The tradeoff is about speed now versus speed later.

• Expert: You don't have to choose between speed and quality. Quality enhances speed, and speed improves quality. It's a virtuous loop. Of course, there are situations when this doesn't apply.

Another classic example:

• Beginner: If we dedicate time to one project, it'll be done in 'X' weeks. If we split our time between two projects, both can progress concurrently, even if it takes longer. Effort is a linear resource: time and output are directly related, and multitasking is a way to optimize resource allocation. We have gaps in one project's timeline, so why not fill them with another project?

• Intermediate: Switching between projects has its costs. Plus, shipping a feature means ongoing maintenance and potential iterations based on feedback. There are non-linear costs involved with multitasking and shipping new features. It's not just about building; it's about refining and maintaining.

• Expert: Effort allocation is more than time; it's about strategic focus, learning from the market, and understanding how products evolve. Rapid iterations on a single project can provide valuable feedback, and deep focus minimizes context-switching costs. Every project shipped is a long-term commitment; our bandwidth is more than just calendar time. There's a dance of development, maintenance, market feedback, and iteration. Projects are living entities. The true cost of context switching goes beyond time—it affects quality, team morale, and long-term productivity. That said, there are times when you need to shake things up artfully: teams can get into a rut, and sometimes, multitasking and pivoting is just what you need to keep things fresh.

I could list dozens of perceived tradeoffs: centralization vs. decentralization, flexibility vs. standardization, innovation vs. maintenance, alignment vs. autonomy, specialization vs. generalization, cost vs. quality, growth vs. profitability, explore vs. exploit, individual productivity vs. team collaboration, data vs. intuition, etc. In each example, beginners and experts have very different views on the nature of the tradeoff or whether it is a tradeoff.

Experts are good at acknowledging polarities vs. tradeoffs. For example, while a novice might see the choice between "centralized vs. decentralized systems" as a simple tradeoff where one is better than the other, an expert understands this as a polarity. There are times and situations where centralization is better (e.g., reinforcing a small number of consistent norms), and other contexts where decentralization, with its flexibility and empowerment, is advantageous (e.g., use whatever tracking tool makes sense, or don't use one). Instead of viewing it as an "either-or" decision, experts seek a "both-and" solution. As you get more experienced, you become more comfortable with "liminal spaces"—the in-between spaces where things are less defined, more ambiguous, and more uncertain.

But here's the problem. Notice how the experts sound bat-shit crazy? It doesn't sound actionable. It sounds like a plumber coming to your house and saying, "It depends," while a river of sewage waste leaks behind the drywall. You just want 1) human waste not in the drywall and 2) a functioning plumbing system. 

The more experienced you become at something, the more your view of tradeoffs changes, and your views on tradeoffs are likely very different from someone not as experienced in that area.

As an expert in your field, you no doubt understand exactly what I'm talking about. Maybe you're involved in sales, and someone is making a simplistic observation like, "All you have to do is lower the price, and people will buy more." Maybe you are in finance, and someone says, "Why don't we just cut costs to increase profits? It's that simple." Perhaps you are in marketing, and someone says, "If we just had a viral video, our brand would be everywhere overnight." So you know exactly what I'm talking about. Notice how that makes you cringe?

I don't want to let [Your Name] off the hook. They are probably not spending enough time trying to find common ground. They are probably not focusing as much on your needs. They may not be spending enough time or have enough time (your calendar is tight) to explain what they're trying to describe.

But I'm writing on behalf of [Your Name] to suggest that there's probably something both of you can learn about each other. You may perceive tradeoffs in product development that aren't actually what an expert or more experienced person will perceive. And there are almost certainly tradeoffs in your world that [Your Name] Doesn't understand.

So, in the spirit of finding shared understanding, please schedule another meeting and let your name have another shot.

Thanks

John