Product management tool series: Meta-thinking on how to think about tools.

Besides features, integrations, and pricing, is there some prerequisites PMs should be aware when evaluating product management tools?

As your company, product, and product organization matures, you might start to rethink the processes and tools you use. With more problems, customers, product managers, and features, you ask, “What’s out there besides spreadsheets, docs, and slides?”

This is going to take awhile

Previously, I wrote about two specific product roadmapping tools: ProductPlan and Productboard. They received some interested readers.

Today, I’m taking a step back to discuss my thinking on how to think about PM tools.

The maturity of product management/managers.

Dive right in

Nowadays, it’s easier than ever to try software. No credit cards required, one-click, 14-day trials. While it’s natural to dive right in, sometimes we can get lost in the details of our problems. How do you know if one tool is better than another?

Hand-saw or chain-saw, which is better? What does it depend on?

For example, when I’m thinking about product roadmapping tool, I spoke with several PMs who described problems they were experiencing, which vary from strategic to tactical.

• With multiple product teams and varying skills levels, how do you standardize product roadmapping?

• How can you tie customer issues and feedback when setting product roadmaps?

• How do you share product roadmaps at the appropriate level of detail to various internal and external stakeholders?

• How do you sync information on product roadmaps with tactical project management information such as those captured in an issue tracker (e.g., JIRA, AzureDevOps, Linear)?

Prerequisite: Things to think about before you dive in.

Just as my hand-saw vs chain-saw picture illustrates the point that (it depends on the job), different product management software are best at different product management maturity model levels. This, a prerequisite is to think about where you are today.

But after reading a few models, I found using those maturity models to evaluate yourself is difficult. Also, maturity models tend to imply more mature is better, but that’s not always true. More isn’t “better”, more is just more.

So, I came up with a different process by reflecting on the self, organization, and product life cycle. Using this process, you’ll understand if you need simple, intermediate, or advanced PM software.

Definitions:

• Simple software is task-oriented that accomplishes a few things well. Simple software is easy to learn and use with no or very limited customization.

• Intermediate software enables some user customization, primarily for reusability. The customization increases the difficulty of usability. Besides having more features, intermediate software also tend to support two related but separate processes (e.g., creation and publishing).

• Advanced software focuses on collaboration (information collection and dissemination). Because coordinated collaboration is difficult (different users with different objectives and skills), advanced software must enable easy toggling between novices and experts.

Self Competency

The above illustrates the four stages of individual competency during learning.

For this discussion, I’ll simplify it into three:

1. If you’re unconscious about your competency as a PM, you don’t care much about PM as a profession. You’re either entirely unaware of your incompetence or so competent you don’t need to think about thinking. As a result, tooling for PM is not a concern.

2. PMs who are “conscious incompetence” will seek the “how” to improve their competence. As a result, tools that deliver results or teach are more valued.

3. PMs who are “conscious competence” will seek the “why”. Because they are already competent, they are looking to to strengthen their understanding of causation.

Knowing where you personally land will color your evaluation of product management tools. For example, “conscious incompetence” PMs often value tools that guide or train. Tools that require configuration or customization before use are perceived as too complex. Whereas “conscious competence” PMs can get away with blank spreadsheets, slides, Notion, Code, Airtable, which offer a considerable amount of flexibility and customization. It’s also the reason why they are more likely to say, “tools don’t matter”.

Organization

Whether you are evaluating a product management tool for yourself or for the entire product organization, it’s a good step to think about this problem as part of your company’s larger set of problems.

L. Greiner developed the stages of growth to help identify common problems all companies will face as they grow. I’ve highlighted the first four because they are most relevant.

Management Problem: The informal, founder-led process/product that got the company off the ground is no longer sufficient. There’s a demand for standard processes, decision-making, specialization (i.e., professional management). This is typically experienced during seed - Series A/B.

Autonomy Problem: Professional managers have centralized decision-making and introduced hierarchies, but this is no longer sufficient. Individuals at the lower-levels struggle between following procedures and taking autonomous initiative when procedures aren’t applicable. This is typically experienced during Series B - Series D.

Control Problem: Greater autonomy via delegation. However, there’s now the challenge of coordination and collaboration. Top executives feel a loss of control (want to regress to the previous stage) and lower-level managers/employees either are overwhelmed with coordination or run their own shows with no coordination. This is typically experienced when there are multiple products, more specialized functions, especially multinationals.

Collaboration Problem: More formalized processes and staff (e.g., product ops, sales ops, program managers) are brought to help coordinate collaboration. There’s a clear separation between corporate/headquarter functions and business units/lines of business functions. However, all the formalized processes and staff add administrative costs and stifle innovation. People complain it’s too expensive or slow to start something new. This is typically experienced at multinationals.

As you can see, different stages have different problems necessitating different tools. For example, seed stage, single-product companies would value creativity and speed of communication. As the organization grows into the next stage, it values more organized, structured information. Further growth and that information need to be collected and distributed for more autonomy decision-making at the lower level while balancing some control of top executives for key initiatives. Knowing the stage your company is in highlights the type of problem top of mind, which will influence how you think about product management software.

Product Life Cycle

Products go through different stages. While product discovery and delivery activities are common across stages (e.g., listening to customer feedback), the importance placed on each activity will vary.

For example, in every product life cycle stage, it’s important to “listen to customer feedback”. Yet in the early part of the introduction stage, PMs quickly shift from listening to general pain points to identifying a specific pain point to solve. This is different when the product reaches the mature stage. Here, instead of focusing on a specific pain point, it’s important to serve multiple customer segments simultaneously.

Knowing this information, you should identify the type of activities within product discovery and delivery that are most important to support you current product. In turn, those activities will heavily influence how you evaluate product management software.

Putting it together

The above should highlight some intuitions. These include:

• PMs who are trying to improve their competency will value software that’s opinionated, that have put “best practice” into practice. These software often prevent users from deviating from how the software works. There are articles and trainers available to help guide the user. This is is also beneficial for companies in the facing Management and Autonomy problem phases.

• PMs who are more experiences will value software that enables customization or at least selection among differing options. This is because PMs understand there isn’t a single “best practice”, but a stack of good practices that are better at getting some jobs done.

• Companies, especially multinational or those with multiple product lines, will value software that enable coordinated collaboration over point solutions. This is true regardless of of the competency of PMs. Because work must be accomplished by multiple people, coordination and collaboration are more important than individual creativity. Furthermore, best practices in one function my conflict with another, thus finding compromise is critical to coordinated collaboration.

• The most important product management activity that’s top of mind will determine the feature you value today. Yet because products will go through different life stages, the relative importance of those activities will change over time. Paradoxically, the success of a product will necessitate adjusting what type of tooling is necessary. Cut down enough trees with a hand-saw and you’ll need to switch to a chain-saw, not because hand-saws were bad. The hand-saw got you to the stage you needed a chain-saw.

Minor notes:

The above can feel more philosophical. Thus, I would be remissed if I didn’t mention two practical concerns when thinking about software. These are the two major constraints:

• Budget: Yes, you should have an idea how much you’d be willing to spend. It’s a constraint.

• Available time (implement, configure, onboard, learn): Less of a constraint, but how much time you can allocate, both at the individual and organization level.

While it’s good not to forget these, these two constraints are highly conditional and not directly related to the effectiveness of the software. This is why I didn’t focus on these two criteras in this reflection.

---

This is not a paid or sponsored post. All opinions are mine. If you like my writing, support with a Venmo donations @Shaw-Li or purchase a copy of my product book.

Special thanks to Mitchell Maffeo, Ryan Searle, Vineet Thanedar, Jake Walker, and Louise Baker, who took the time to chat and share personal experiences.

Sources:

• Design Maturity Model (by Invision)

• Gartner’s Product Management Maturity model

• ProductFocus’ Product Management Maturity model

• Inductive design of maturity models

• Organization life cycle wiki

• Evolution and Revolution as Organizations Grow