BA 38/52: The Right Tool

This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.

---

At bigtech corp, the tools have already been picked for you.

At startup corp, you will constantly cycle through tools looking for the right one.

The right tool, what a dream.

Every person has their own opinion of what the “right” tool.

Design team uses Asana and Figma; Engineers prefer vim, VSCode, Android Studio, or Xcode. TPMs and PMs, well this is an interesting one, the tools we have to choose from is often met with the most scorn from our other comrades: Jira, Aha, Confluence, Notion…

The pessimist will say “no such thing as the right tool”.

The optimist will say “lets give this tool a chance, I know its painful but it works.”

The pragmatist will say “this is the right tool for us… right now… until we move on to better tool for our future needs”

Here is everything I have learned about picking the right tool from my days at BigTech and Startup Corp:

• No matter what tool you choose, only 80% of the users will be happy and 20% will hate it even if it works for them.

• They may hate it, but they have to use it; any room to not use it, your loudest opponents will take it. The cracks begin.

• Before rolling out the tool, give everyone an opportunity to provide input, whether on the choice of tool or how we use it.

• Periodically measure how the teams are doing with the tools (NPS survey).

• Golden Rule: One tool in, one tool out. Never run parallel tools unless it’s a pilot to replace the other.

• For new hire onboarding, document how the team uses the tool, not how the tool maker intended the tool to be used.

• Tools don’t make teams productive but they help illuminate what needs to be done so teams can make the right choice towards higher productivity.

• Eventually, all startups grow to be bigtech and must start investing in custom tools.

• Its better to have a few specialist tools that are great at doing one thing rather than an all-in-one tool that is adequate/sub-par at many things.

• New tools come and go but sometimes all you need is a good old text file for everyone to collaborate in to solve all your problems.

• When you are a small team, you can experiment constantly with the tools in use. As your team grows, focus more on disciplined use versus experimentation.

• When you are a small team, designate a tool champion who learns/knows the ins and outs; get them to teach everyone else “how to fish.”

• Tools can solve procedural problems but never human ones. Remember that when people complain “the tool is not working” or when pitching the tool to the powers to be.

Picking tools is both an objective and subjective exercise. It is hard if not possible to be objective in this.

Ultimately, as TPMs and PMs picking a tool for teams to use, focus on the problem you are trying to address. Never try to implement a tool then go searching for a problem to solve.

Until next time 👋 .

-Aadil.

---

How is this week’s newsletter?

🤯 Amazing
😁 Good
😊 Okay