Anyone who’s done anything at a certain level for a reasonable amount of time will inevitably get asked about the tools they use. It’s probably in the top five questions I get over email and after conference talks:

• “What tools do you recommend for roadmaps?”
• “What tool do you use for product visions?”
• “What’s the best tool for tracking OKRs?”
• “What frameworks should I use?”¹
• “Can you recommend a wireframing tool for sharing concepts?”

People are often disappointed with my answers, which usually come down to “whatever your team already uses” and “Google Docs.”

The motivation to learn from others is certainly understandable, but I believe the question is misplaced, and it’s been gnawing at me for years. Here’s the novelist John Gardner, quoted by Austin Kleon:

In my experience the single question most often asked during question-and-answer periods in university auditoriums and classrooms is: “Do you write with a pen, a typewriter, or what?” I suspect the question is more important than it seems on the surface. It brings up magical considerations—the kinds of things compulsive gamblers are said to worry about: When one plays roulette, should one wear a hat or not, and if one should, should one cock it to the left or to the right? What color hat is luckiest?

If you want to be a better tennis player, you could ask Serena Williams what kind of racket she uses. What brand? Grip type? Swing weight? Rackets are undoubtedly important in tennis, but there’s a lot of other shit you need to learn before they even begin to matter. But it’s easier to ask her about rackets than that other stuff, and it’s easier for her to answer, so that is why people ask it.

Kleon continues, speaking as a writer and artist himself:

If you are just starting off and I tell you exactly how I work, right down to the brand of pen and notebook, I am, in a some small sense, robbing you of the experience of finding your own materials and your own way of working.

His piece helped me pin down why the tools question always gave me mild indigestion: if I give you advice, you just might follow it. More to the point, if I engage you in this conversation, I’m lending credence to the misguided belief that PM tools matter more than other fuzzier things that truly are important. And it was learning those things that made me a better PM. The tools didn’t matter.

I’ve also learned that the best craftspeople sometimes use the most primitive tools. Think of that brilliant programmer who stills writes all their code in Emacs, ever-resistant to the fancy IDE de jour. Or compare the thousands of dollars of guitar equipment in the wealthy hobbyist’s house with Tom Morello’s gear closet. Then compare their playing. As Morello says:

My take on gear is that it does not matter—at all—ever—in any circumstance.

Likewise, a talented photographer will take better pictures with their iPhone than I would with a $20,000 rig. A sentiment best expressed by photographer Chase Jarvis who, when asked which camera he recommends, replies, “the one that’s with you.”

Tools can be harmful

PM tools often dictate that you use them in a specific way. That makes sense. It’s pretty hard to design a product that supports every conceivable style of working. But be careful: that “certain way” often isn’t the most desirable. It’s usually the lowest common denominator way or merely the most popular way. That’s because it helps the tool appeal to the broadest audience of potential customers. Here’s Marty Cagan:

I have seen several tools that are designed to make it easy to tally the requests from different stakeholders and from different customers or prospective customers, so that the product manager can make a “data-driven” decision on what the priority of the requested features should be.

If that’s how you want to determine what your team will work on, then these types of roadmap tools are helping you towards that end. However, if you believe as I do that this is exactly the wrong approach to coming up with winning products, then a team forced to use a tool like this will have to fight the tool in order to try to do good work.

I’ve seen this recently with software for managing Objectives and Key Results (OKRs). Most OKR tools have all sorts of fiddly ways to nest objectives, features for prioritizing key results across multiple dimensions, dashboards and charts for observing daily progress, and smart workflows for assigning OKRs to particular individuals. But if you’ve learned as I have that OKRs are doomed to fail when you (1) have more than 3-5 of them, (2) rank certain OKRs ahead of others, (3) attempt to monitor progress too frequently, and (4) cram OKRs down to the individual level, then you’ll know that this tool is actively causing harm. The wrong tool is worse than no tool at all.

From the tool developer’s perspective, they’re just doing what makes sense to them: they’re trying to grow a business, and the best way to do that is to show that their specialized product is better suited for OKRs than something more generic like, say, Google Docs. And the only way to demonstrate that is through loads of superfluous OKR-specific features. But it turns out something like Google Docs was already the perfect tool for describing a small handful of company-level OKRs and sharing them with the team. Google Docs’ simplicity and lack of specificity to the task actually prevent you from cutting yourself on all the sharp edges that doom OKRs. Worse is better.

Photo: Smithsonian Institution

Yet another mistake companies make: obtaining a tool but not giving everyone access to the tool. Maybe they don’t think everyone needs it, or that it’s too expensive, or perhaps the company is just too cheap to pay for enough licenses. The unintended side effect is someone’s job just got more challenging—probably the tool wielder’s—and the company has created a new gatekeeper. Worse, stakeholders must consume the work product outside the tool (because again, not everyone can access it), which means everything needs to be done twice or exported into a lossy format. There’s also a good chance that stakeholders are looking at something that is now out of date. Months later, nobody will be able to find the work because it’s locked in a walled garden and not searchable. (And don’t get me started on what happens when the tool company gets acquired or goes out of business.)

What to do about it?

I certainly don’t mean to dismiss tools entirely. Of course, they can be helpful (and I hope my friends at software tool companies aren’t too mad at me). The proper tool can streamline collaboration, improve documentation, and make us individually more productive. I’ve seen products such as Coda, Miro, Github, Figma, Slack, and Notion² supercharge already high-functioning teams.

If you’re looking for tools to fix a process that’s broken, though, they won’t help, and as we saw above, they can make matters worse. If your tools force you to work in a new way, move on. Tools should fit the wielder, not the other way around. There’s no silver bullet: tools can’t make you a better product manager. As long as you enter the search for tools with the appropriate mindset, they can be a good thing.³

If tools can’t make us better PMs, how can we learn from others? Try asking different questions. Let’s go back to the examples at the beginning of this email. How do we switch them from “Serena, what kind of racket do you use?” to “Serena, how can I become a better tennis player?”

• “What tools do you recommend for roadmaps?” → “How do you communicate what’s coming in the future to internal and external audiences?”
• “What tool do you use for product visions?” → “How do you motivate your team around a shared future vision?”
• “What’s the best tool for tracking OKRs?” → “How do you decide and communicate what’s important to the company and what’s not?”
• “Which do you recommend, Scrum or Kanban?” → “How do you decide what to build and what not to build?”
• “Can you recommend a wireframing tool for sharing concepts?” → “How do you communicate early product ideas?”

I bet you’ll learn a lot more from asking these questions. And I would also bet that their answers will have nothing to do with tools.

Comic by Austin Kleon

Lest you think I’m all high and mighty, I decided to write this because I recently found myself slipping into the same trap. When I decided to go into business for myself, I reached out for advice to friends who have been coaching and consulting for years. Fairly early in the conversations, I found myself excitedly asking, “what CRM do you use?” and “which system do you prefer for billing?” Only when I caught myself did I learn things that can help me. One example: “It doesn’t matter what billing system you use, they’re all fine. But some company is going to mail you a paper check someday. Be ready for that.” Isn’t that a way more useful answer than “I use Stripe”?

1. Yes, frameworks are tools. ↩

2. You might have noticed that none of these examples are really “PM tools.” They fall into two broad categories: (1) flexible offerings built to address a particular pain point that many people across industries share, such as whiteboarding or documentation, and (2) software for functional experts, like engineers or product designers, that evolved to help those folks collaborate better with their adjacent stakeholders (including product managers). ↩

3. PMs love playing with new products (see also: Product Hunt). You can find yourself spending way more time and energy evaluating new tools than you could ever save by adopting them. It’s tempting to let that productivity sink bleed over to your team. Even if you can’t resist your urges, please don’t distract your team by regularly asking them to “test out” new tools. The road to product development hell is paved with well-intentioned but discarded tools. ↩