What Is The Overt Benefit Of A Product Management Tool?

One of my goals is to help product managers create better, thicker value products. As a profession, I think we need better tools to do that more efficiently and effectively.

I’ve focused a bit on the source of the problem – the complexity of the domain of product management.  I’ve been a little weaker on specifics of a solution. In particular, I have not articulated an Overt Benefit, Dramatic Difference, and Real Reason to Believe for a new breed of product management tools as a category. (I hope you remember those concepts as the “Three Laws of Marketing Physics,” a great thinking structure created by Doug Hall in Jumpstart Your Business Brain.) If we had those, they would help us a) drive the development of these tools, and b) give us a basis for evaluating the various existing and new solutions in this space, to see if they offer the capabilities we need to deliver thick value.

Therefore I’ve been working on creating a clear statement of the Overt Benefit of product management tools for several weeks. It’s hard – a perfect example of what we face as PMs. We have to come up with things like benefit statements and value propositions and Overt Benefits, and it’s freaking hard. We want them to be *right*, and as technologists we tend to make them technical and feature-laden.

So the process is you write something, and some people tell you how full of crap you are, and you write something else, and pretty soon you have something at least better. And then you try it with customers, and they maybe look at the prototype, or they review your statements or mockups, and they say “wait, what about this?” or they say “that doesn’t make any sense to me,” or they say worse things, and that results in you learning more and redesigning and rethinking and re-articulating, and maybe at that point you’re starting to talk about value.

Reflecting on that process, I realized what I need to do is publish my first cut at an Overt Benefit statement and then let the party begin. Share it with you and see if that starts a conversation.

Now, as a PM, I’m the customer for PM tools. What do I receive, enjoy, or experience when I get a product management tool? As a first, cut, I have something like this:

I get help defining, designing, and delivering a better product, that delivers thicker value, so my customers are more successful when they use it, because the tool understands what I’m doing and how product creation works. 

A tool is beneficial to me if it helps me create more benefit for my customers and understands the process I’m going through.

But it does seem a little thin, doesn’t it? It’s almost mom and apple pie to say that. And I feel that I’m going to get some very good advice from you, as you tell me what’s missing.

(Oh, and let me know if you like the new design!)

Tags: ,

4 comments

  1. Has to save me time from my current process without reducing the output that I get.

  2. First, yes I love the new design and I guess logo?

    For me and this might be what you mean in your Part 2 Benefit Statement but….the biggest benefit I'm looking for is to have 1 system through which I have all of my stakeholder conversations that contains and easily displays all the data (customer/market & product/technical) I need for each of type of conversation I might have in a given week.. These can range from sharing my thoughts at a Strategic Market Perspective and with a Roadmap to match with Executives and External Stakeholders to Release level plans and feature/benefit details with my cross-functional team (sales, mrktg, service, support, etc.) who help my product succeed down to my Release, Sprint & Story/Bug level details when collaborating day to day, sprint to sprint with my engineering teams.

    I data set, multiple views, many conversations. BI for a PM.

    • Scott – this is great – and aligned with what I want as well. My big point is that I want all that stuff to also be as analytical as possible. In other words, when I have a conversation with a customer, I'm going to get specific requests for new features, or specific information on why something's not working, and I want to do more than just take notes on that. I want to be able to capture those insights (perhaps after the meeting, in reality), and say, for feature A, “hey, this customer really wants it” and for feature B “the customer is totally 'meh' about this one.” The idea being that later on, I can use that information help me make a decision about features A and B and their place in the roadmap.Of course, my “analytical” idea is pretty much 20th century thinking. Why can't the application do those inferences for me? I'm sure the NSA could already tell me, based on my notes, which features I should be prioritizing 🙂

Leave a Reply