Oct 14

PM Tools Should Help Us With The Hard Things We All Do

What are some of the annoying, hard things you have to do as a product manager? Here are two common situation from my experience. I wish the PM tools out there would step up to helping me do these more easily.

I sometimes get features that are only partially implemented, with respect to the original story or requirement. If the tool automatically understood in its guts that a requirement can be partially implemented, and that it might need to be decomposed along those lines so the remaining parts of the feature could be implemented later, it would be a big help. Perhaps a wizard that guided me in decomposing the requirement. It could ask questions like ‘is this requirement 100% completed?” If I say “No,” then it asks “Is it partially completed, and if so, what part? What’s the value proposition of that part?” “Do you want to take any of the existing requirement and turn it into a new requirement for implementing later?” And so on.

Of course, I want the tool to maintain the relationships in the process. E.g., the new requirement should be related to the original, probably with an “Enhances” relationship. Or it might be a “Delighter” relationship. (Because what didn’t get done is usually the “nice to have” portions, not the “table stakes” portions.)

Another thing – I need to write a datasheet entry for the feature, or a release note. Why do I have to go to Word to do this? Why doesn’t the tool have a place for the datasheet blurb related to this feature? And then the ability to write a draft datasheet based on these entries for the features implemented in the upcoming release?

I have to do these things anyway, and often I just try to do them in my head, which means that the next thing that I have to pay attention causes this one to drop on the floor, which means I have to rediscover it later, at a great cognitive cost. Since I have to do it anyway, let’s have the tool become the capture spot for it – which means it needs the right semantics to capture it, and it probably needs to remind me that it needs to be captured, because after all, “I am a product manager, big of head, and I will remember.” Which I won’t, really.

Feb 14

How to Augment Your Cognitive Capacity and Intellect

An old, outmoded model, but it looks good!

A good (product management) system can augment your capacity and your intellect.

Augmenting yourself

Like all knowledge workers, our most precious resource is cognitive capacity, and we lose it constantly throughout the day. If you’re like me, you end up handling 15-20 different activities and interruptions every day. Each of those requires a mental context switch, and context switches are expensive. Typically, you can’t avoid them, so anything that makes them easier will make your life easier. A good process, and the associated tooling, will do that.

There are three main ways process and tools help product managers out with the cognitive load problem (and help you seem smarter – thereby achieving a personal goal!):

  • Offloading memory
  • Enabling deeper analysis and investigation
  • Offloading process steps/status

Offloading memory

The less I have to remember – why a particular feature (“chunk of value”) is important, who suggested it to me, who made the most recent comment about it, even the reason we’re scheduling the next release – the more cognitive capacity I have left for doing the more interesting parts of the job, like creating more value, defining market positioning, or talking to customers.

As Amy Hoy (http://unicornfree.com) says:

  • Almost all productive people are far too busy to remember everything they do each day because they’re Getting Shit Done.
  • Almost all people are numb to their own pain.
  • Their most dangerous problems aren’t the minor irritations that sting, but the dark shadows that lurk below the surface, unsaid, unnoticed, unmanaged

Enabling deeper analysis and investigation makes you a smarter product manager

And it’s not just your memory that benefits, but your intellect as well. Even a simple and obviously valuable query like “what features were requested by both customer X and customer Y?” is typically beyond the capacity of a normal person’s – even a PM’s – memory.

But if that information is in the system, and it’s easy to retrieve, I don’t have to remember it. And, as a bonus I can use it for analysis and investigation that I couldn’t do if the information were all in my head. That means I’m smarter.

Offloading product management process steps/status

Tools also help you with processes, per se. For example, if you’re developing your product in a traditional manner, you spend months building it, and then a few weeks launching it. Every few months you have to remember how to do a launch, remember what went wrong (or well) in the last launch, and decide how you’re going to do it differently this time.

A system that not only keeps a list of the steps required for launch, along with who is responsible for each, and a history of what happened last time, means you don’t have to invent this every time, and you can learn from history. Again, you’ve offloaded the process into the tool, leaving more room in your brain for the good stuff.


Feb 14

Making Product Management a Modern Business Process

Central System of Record

Having a central record of truth – a system of record – has propelled the modernization of business processes over centuries, from the notion of “the ledger” in accounting, through ERP, to CRM, to the code repository for a software company. Product management is one of the last business organizations to work with ad hoc records – emails, Office documents, Post-it Notes, and wiki pages.

Not quite – this is a system of tape. We’re looking for a system of record. (CC 2.0 licensed by Dean Terry)

All the inputs to product management are ad hoc and random:

  • Emails
  • Documents
  • Tweets
  • Ideas from the idea management system
  • Phone calls
  • Defects from the defect tracking system
  • Enhancements from the defect tracking system
  • Support requests
  • Executive “suggestions”
  • And so on

These all need to brought into a single repository, and organized so they can be of use.

Simply making the step up to having a “source of truth” for all PM artifacts creates incredible advantages for product managers and their companies. And if the product management system of record actually understands product management processes, and how the different pieces of information interact, then so much the better.

This is an excerpt from my upcoming new book, a template that product management organizations can use to automate the PM process. Look for it soon from an e-book distributor near you. To be notified when it’s available, please sign up for my mailing list over in the right sidebar.

Oct 13

To Be a Better Product Manager You Have To Stop Thinking In List Mode

The big problem with PM tools is that they are stuck in “list mode” – they mostly treat requirements as a list to be gotten through. Agile has made this even worse – because it doesn’t even know about dependencies and other relationships. But many-to-many relationships, and even squishier relationships than that, are the stock in trade of product managers.

A big part of the job of a PM tool (in addition to keeping useful lists) is to be an offboard memory for me, so I don’t have to make the same decision twice, and if I do need to revisit a decision, I can easily remember what led to the original decision. I’d also like it to help me find the things that I’ve already done some thinking about and enable me to reuse that thinking in the same context or a new context.

So, some of the questions I regularly ask myself, and I’d rather ask my tool:

  • Did I have this idea before? (It’s amazing how often this happens!)
  • What did I push to the back of the line a while ago that I should check now?
  • Why did I make this decision versus the other decision?
  • Is there anything like this in the system already?
  • Have I already been through this thought process for another feature, and can I reuse that thought process?

What I want is the system to recognize patterns, even very simple ones at first, and surface them to me. It has to be non-stupid, but it can be simple. For example, for the various impact areas I discussed last week, there are three potential states: “not applicable,” “ask me later,” and other. (“Other” being the actual description of the impact.) It would be hard to correlate the “other” answers – not impossible, there’s technology for it, but it would be hard. But it’s easy to make use of the N/A and “ask me later” states.

Obviously, “ask me later” means the system should remind me later, at a reasonable time in the future, that I haven’t answered those questions. Just as it might remind me at various points that I haven’t written the value proposition yet, or other things. For the N/A answers – at least it could list out the other features that have a similar set of N/A answers, which might reflect an underlying similarity that can be reused.

Taking that a step further, if I answer N/A for some impact area, that presumably means that the feature doesn’t impact that area at all, which has implications for the cost of implementing the feature. Some areas are costly to make changes to, while others are less costly. So if I get a low estimate for a feature that has an impact in a high cost area, the tool should warn me.

Another analysis of the same situation – if I have a feature that has an impact in a high cost area, I should double-check its rationale for existing – important customers want it, or it’s important to align to market themes, or whatever it might be.

Simply going through a list of features is never going to give me these kinds of insights. And today I have to remember to do all that myself.

Oct 13

Overt Benefit of Product Management Tools – Take Two

Doh! [Palm to forehead] There were two big problems with my post yesterday on the Overt Benefit of product management tools. First, I buried the lead (or “lede”). But worse, I was wrong – my first cut at an Overt Benefit for product management tools was, in retrospect, way off the mark. Here’s what I should have written:

The real benefit for me of a product management tool is that it captures all the information I need to do my job, including all its relationships, so that I don’t have to remember it all (or reconstruct it each time), so it becomes an enterprise asset, and so I can use it for analysis and reporting.

There are three key points I want to make about this:

  1. I have a lot more to say about all this information and its relationships, which I will come back to in the future (some of which I’ve already said in earlier blog posts).
  2. I need to manage this information and its relationships now, I just have to mostly do it in my head. As Evan Williams said in his XOXO talk last week, one of the best paths to Internet riches is to “Take a human desire, preferably one that has been around for a really long time…Identify that desire and use modern technology to take out steps.” Humans have been been driven to create product innovations ever since the some proto-human made that first improvement to the three-chip stone axe two million years ago.

I also want to point out that my two posts, yesterday and today, reflect a common occurrence in product management and innovation. I have a great idea for a solution to a problem, I make a first cut at a solution or a statement about the idea, and then I go home. The next morning in the shower, or after talking to other people about the idea, or just after further thought, I realize that my original idea or solution was wrong, not good enough, partial, or otherwise not ready for prime time. This is valuable! I’d rather have the right answer, even though it’s embarrassing to state a wrong answer first.

So another Overt Benefit I’d like from a product management tool is this:

Don’t punish me for changing my ideas.


Oct 13

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!)

Sep 13

Our PM Tools Are Pencils Fastened To Bricks

Pencil and brick. (CC 2.0 license, Attribution, Some rights reserved by danxoneil)

Rob Rivera wrote, in a comment on a previous post:

If we think that having a better or easier tool will make us more effective product managers, we may be fooling ourselves… We should be spending 80% of our time understanding, measuring and tracking how our solutions impact our customers’ bottom-line. For that we need very few “tools.”

He goes on to recommend a tool called LeveragePoint that focuses on measuring customer value. Definitely an interesting perspective, and I can’t argue with the idea that we need to focus on customer value.

But I’m not completely on the same page as Rob. I think it’s true that tools don’t solve problems. On the other hand, it’s clear that better quality tools, and especially tool innovations, often lead to better quality or totally new solutions. For example (from a different domain) I have a cheap table saw at home. I could use it to build some kitchen cabinets. But my cabinets would be kind of crooked. I’m not an expert cabinet maker, but even if I were an expert, my cheap table saw would make it really hard to build non-crooked cabinets, compared to having a good quality table saw.

For a great perspective on this, I suggest reading Doug Engelbart’s riff on the pencil as a tool (in his great 1962 paper), compared to ways the pencil might have evolved:

We fastened a pencil to a brick and experimented. … With the brick pencil, we are slower and less precise. If we want to hurry the writing, we have to make it larger. Also, writing the passage twice with the brick-pencil tires the untrained hand and arm.

How would our civilization have matured if this had been the only manual means for us to use in graphical manipulation of symbols? For one thing, the record keeping that enables the organization of commerce and government would probably have taken a form so different from what we know that our social structure would undoubtedly have evolved differently. Also, the effort in doing calculations and writing down extensive and carefully reasoned argument would dampen individual experimentation with sophisticated new concepts, to lower the rate of learning and the rate of useful output, and perhaps to discourage a good many people from even working at extending understanding.

I’m saying that the current PM toolkit is pretty much like a pencil fastened to a brick.