A small experiment: asking product managers how they deal with business conflicts

In our daily lives, we are always trying to solve problems or create things that make life easier or less painful — across engineering, technology, medicine, and beyond. Realistically, not all of these efforts serve a greater good for everyone. Sometimes they exist to solve a personal problem, and other times the real value lies in what we learn while building them.

The pain I faced as a software engineer got me thinking about building a tool that would make my work easier, and also help my product manager colleagues. That way, our work becomes less ambiguous and better planned. So I started building anchor. I am not going into much detail about the problem anchor is trying to solve, you can kindly read the below article for more details.

[embed]Product management is broken, Anchor will fix this. Product management is broken — or at least the way most teams practice it today.mohaned-mashaly12.medium.com

Anchor helps PMs catch potential product or business conflicts before development starts, by learning from patterns in past Jira tickets.

Detecting conflicts in product work by analyzing Jira tickets for alignment with business goals.

I reached out to multiple PMs and product owners to validate the problem and understand how Anchor could make their work easier.

My goal was to find out if this is a real problem for product managers, and if it is, how they handle it today. I had a bunch of good answers that gave a good insights on how they are currently trying to solve this problem.

One response that really resonated with me came from a product leader

This is absolutely a problem I’ve seen and experienced… Haven’t seen a good way to solve this, other than to experience it, store the context and react accordingly

What really hit me was that many of the replies shared a strikingly similar approach to the problem. It’s almost like an unwritten wisdom passed through the product management community: you learn to manage it the same way everyone else does, because no good solution has been found yet.

One product manager described the current way they deal with this problem:

1. Document decisions: Start with documenting the decisions that were made. For example a ticket you wrote asked for X but Y was implemented.
2. Build a knowledge base: Create a reference for yourself and your team so that future decisions can be better informed.

This workflow highlights the effort PMs put in to capture context manually, and why the problem persists despite these workarounds being implemented.

Copying each ticket and documenting the decisions behind them is tedious and time-consuming for product managers.

I am still reaching to different product managers to know more about the problem and how they feel about it.