Can there be an all-in-one product management tool?

This is a question we hear a lot.

What is the best product management tool?

Often this discussion goes down one of two paths. On the first path, what often follows is a laundry list of tools that often includes Slack, Trello, Jira, Google Docs, and so on. It’s interesting how often those are brought up as answers given that the question is often about a single tool.

The reason so many people skip that is that there’s a huge assumption out there that no such tool exists. This takes us down the second path. Typically an answer sounds like, “There is no single all-in-one tool for product management. PMs have too many responsibilities, and a single tool can’t encompass them all.”

That’s not an unreasonable statement, because product management can be tough to define. Most of the tools that exist focus on engineering tasks or project management as those have long been well-defined fields. But it’s a wild thing to think about. For decades, product managers have delivered millions of products for users all over the world. But no one has ever created one for them! Even sales has a dedicated tool with Salesforce, marketing has one with Marketo, and so on.

The cost of multiple tools

Ok, but let’s tackle the multi-tool argument for a moment. We heard this recently:

“Using existing tools is better because you can mold them to suit your needs and tie different use cases together. You can stitch together the tool you need.”

It’s a reasonable point. You may have a finely tuned process in place that makes use of various tools, such as Jira for capturing feedback in tickets, Excel for prioritizing features, and Trello for the roadmap. But is this scalable? What happens when one of the tools in your chain, none of which were designed for your specific PM use case, makes a substantial update that alters functionality? You have to sit down across your entire organization to come up with a new process to accommodate this change.

More importantly, what happens when you, or the designers of this process, leave the company? Or how easily can you onboard new people onto this custom process? You may have this documented somewhere, but how easy will it be to maintain it? How flexible is it to change if new vocal PMs come aboard and think the process should be completely different?

And of course, what about the actual cost of running many seats for multiple tools? The bill adds up.

This is something we heard from someone that we think gets close to this problem:

“It’s a lot more efficient to use 2 tools to get 80-90% of what you need than using 5-6 tools to get 100% of what you need.”

Flexibility vs guidance

When you create your toolset, you dictate the process down to its detail. This may seem like an advantage over an “opinionated” tool that is built on a set of ideas of how things should be done. For the latter, you often see job descriptions asking for people familiar with Microsoft Excel or Salesforce because those tools require an understanding of their mechanics and the operational philosophy that drives them. But is this the wrong approach?

I’d say we perceive tools as “opinionated” the moment they force us to adopt a process that’s suboptimal for our needs. Up to that point, the structure they provide is welcome. That structure controls the flow of information (like user feedback, feature requests, or prioritized feature ideas ready to be pushed into a development planning tool). It standardizes the way data is captured, visualized, collaborated on, and put to use. And the very way it does this can implicitly communicate best practices that you might have had to read several blogs and books to figure out on your own. We think this is the superior approach.

A dedicated system

The structure we built into productboard is holistic: a solution that lets you:

1. consolidate ideas/requests/feedback so you can spot trends around what users need.
2. prioritize what to build based on clear objectives.
3. share your roadmap, and collect more feedback on what’s on it.

But our goal isn’t to adhere to an unchanging idea. There are variations in users’ opinions and processes that we will continue to analyze and determine how to best address. Just as Salesforce and Jira weren’t fully customizable from the beginning, we’ll continue to explore how to strike a balance between structure and flexibility. For example, we’ve been surprised to learn how users are using our generic “component” entity. These discoveries often inspire new features or options for customizability.

A dedicated, all-in-one tool like ours gives you the base level of structure needed that we can and will continue to adapt to best practices advocated in the product management community but is flexible enough to suit your needs.

TRY FOR FREE NOW