Maker's tools, Manager's tools

It’s interesting to see the selection of tools and processes dynamic play out at larger companies. Managers and makers often have conflicting needs. Managers, especially senior leaders, typically select tools that align with their goals of visibility, accountability, and tracking.

But here’s the problem: these tools often lack what makers actually need. Makers benefit from tools that support problem-solving, shaping the work, evaluating tradeoffs, and iterating toward a solution. In other words, they benefit from tools that help them do the work, not just track and report on it.

The reality is that few tools effectively serve both groups. Since managers usually control the purchasing decision, tools tend to skew in their favor—leaving makers to deal with software and processes that adds little value to their day to day. Here are a few examples.

Many roadmapping tools (like Productboard, Roadmunk, Aha!) excel at tracking and reporting. If you input your data, configure the right fields, and tag items properly, you can generate detailed reports for executive planning and status updates. But the outcomes product managers seek isn’t just about reporting — it’s about figuring out what creates value for customers and how to turn that into value for the company. The best tools help synthesize customer insights, frame problems, and shape the work, see contrast and make tradeoffs between various alternate paths.

Most roadmapping tools fall short here. That’s why so many effective product managers turn to digital whiteboards like Miro or FigJam. These tools aren’t perfect, but they’re flexible, intuitive, and designed to facilitate thinking, iteration, and collaboration, rather than just documentation.

Same goes for project management tools like Jira, Monday, Asana, etc. From what I’ve seen most ticketing and tracking tools tend to be almost universally disliked by engineers. To them, these tools feel like overhead, something that’s more about tracking tasks than facilitating problem-solving or forging solutions. A good tool should help teams diverge in their thinking and then converge on a solution, but most of these tools don’t support that process and in many cases get in the way.

This is why we need to be more thoughtful in how we choose our tools. The emphasis should be on serving the makers and helping facilitate their work — not just solving for managerial struggles. As someone who’s a manager but also, first and foremost, a maker, I’ve felt the pain on both sides. Hopefully, over the next few months, as we take a look at our process and tools and refine them, I’ll write more on this topic.