22
Aug 16

Selection Criteria for Product Management Tools

Tools For What We Do

As a product manager, I’d like to find some tools that help me do my job. I deal with:

  • Customers – finding their problems and listening to their product feedback
  • Markets – my segments, their problems, and how to reach them with my solution (and if they are big enough for me to make money)
  • Positioning and value propositions – what my product does for my segment, and why it’s a better solution than the competition
  • Strategy – how the goals of my company drive the solutions I deliver, and how my solution aligns with those goals
  • Revenue and profit – how my solution will generate top and bottom line dollars
  • Roadmapping – how my solution will be shaped over time
  • Competitors – who my competitors are, their strengths and weaknesses, and what I need to do to take advantage, or overcome gaps
  • Prioritization – out of all the features and solutions I could deliver, which ones should I deliver?
  • Go to market – how my potential customers hear about my solution, its value to them, and why they should buy my solution instead of our competitor, or instead of doing nothing

And oh, yeah:

  • Building a solution – addressing the customer’s problem effectively with technology, with enough differentiation that it’s possible to sell successfully

Tools for building the solution and managing that process are a dime a dozen.

But tools that help me with all those other things? Practically nonexistent. Mostly I have to use Word, or Confluence, or spreadsheets, or just my big brain, to manage all that.

My Selection Criteria

If a tool really cared about product managers, it would understand:

  • We have customers
  • Revenue is interesting
  • We do a lot of market research
  • There is competition
  • We have to take our solutions to market

And it would help us prioritize our solution based on those.

What You Can Do

  1. Irrespective of your tools, you need to keep all those things I listed in mind as a product manager.
  2. If your tooling doesn’t understand our domain specifically, you will need to augment whatever you are using to capture and manage that information. You can use templates, best practices, or just the power of your mind.
  3. If you’re evaluating or testing product management tools, make sure to ask the vendor about the topics I list above. How does the tool support your customer interactions? Your prioritization? Your value proposition?

08
Dec 14

Reversing Cognitive Decline – Podcast Episode #4

As a product manager, one of your most precious resources is your “cognitive storage tank.” It’s like a real fuel tank – when it’s exhausted, your cognitive abilities stop working well. And when that happens, it means you can’t be as innovative, you can’t be as creative, and your decisions get worse. To improve our effectiveness as product managers, one key step is managing the cognitive storage tank.

In this podcast I describe some techniques and tools for eliminating wasteful leaks from your storage tank – I hope the ideas will be helpful for you as you improve your effectiveness as a product manager.

Let me know in the comments on the show notes if you have additional thoughts or questions.

Show Notes

If you like this podcast, please subscribe via iTunes (you can search for “responsibility authority” to find the listing) or your favorite subscription method via this feed. And please consider rating and reviewing the podcast on iTunes. The feedback is very helpful for me.


23
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.


06
Sep 13

The Sad State of The Product Manager Toolbox

Dad’s Old Toolbox, from e.b. image, CC 2.0 licensed.

Face it. As product managers, we have a pretty poor set of tools. I don’t know you but I can guess what’s in your toolbox (coincidentally, Scott Gilbert posted a list of what’s in his toolbox yesterday):

  • Microsoft Word or Google Docs
  • Excel or Google Docs
  • A bug tracker like Jira or Bugzilla
  • A wiki like Confluence or Twiki
  • Balsamiq or Axure or Omnigraffle for mockups
  • Microsoft Project
  • A to-do list manager – Trello or Asana or Outlook
  • A mind mapping tool if you’re really advanced (I use Freemind)

I “get” to use a subset of that list as well. They are general purpose tools, all great in their own way, but nothing on that list has product management-specific functionality. (And woe be to you if you think Microsoft Project is a “product management tool.”)

Look around at your non-product manager colleagues. They are in much better shape. They all have tools that are built for them, that provide specific functionality for their jobs.

Sadly, that’s the PM tool situation for now (aside from all the new tools I’ve mentioned in a few previous posts). I hope the situation will improve.

But in the meantime, what do we? We take it up a level. We use tool-independent heuristics to help us be better product managers? Heuristics are:

  • Simple
  • Compelling
  • Cognitively appealing
  • Relatively easy to do
  • Flexible enough that they are applicable to most situations
  • Recognize that there is no right answer
  • Don’t try to put you in a box or methodology

I’ve written about a number of these already including Cynefin, The Three Laws of Marketing Physics, and the Mission-critical Core/Context model (see yesterday’s post for a list).

These heuristics are great, but wouldn’t it be awesome if we actually had tool support for them? What if there were a product management tool that helped me work with my heuristics? What would that look like?

  • Helping me find the right heuristic for the situation: There’s exploring the space (looking for a problem), creating and validating your solution (product planning, design, and execution), and creating and validating your value proposition (product marketing, positioning, selling). Different heuristics are useful at different points, some are useful throughout.
  • Helping me organize my work with respect to the heuristic. For example, if I’m doing a Minimum Viable Product, the tool should insist I have a hypothesis I’m testing, and that I’ve designed the MVP to actually test that hypothesis. 
  • In some cases the heuristics involve doing research, such as “Get In The Van” and “Probe, Sense, Respond,” and the tool can help me collect the results and make sense of them.
  • In other cases the heuristics involve me being creative, such as articulating a value proposition (that encompasses elements of the Three Laws of Marketing Physics). So the tool could guide me through this creative process, especially enabling productive collaboration with my colleagues and partners. 
  • Some heuristics help me structure information so it reveals useful patterns, such as the Mission-critical Core/Context model. The tool should provide the structure for me to fill in, and guidance on how to fill it in. It could even help me with analysis of the patterns and how I might take actions based on them. 

A tool that did that stuff would be amazing. But I’m not done yet – there’s a lot more I need and expect. Stay tuned.


04
Sep 13

Requirement Chaos – Don’t Make Me Think

Even though “requirements chaos” seems to be about requirements, it’s really not. It’s about the process that requirements go through.

Help – I’m Stuck In Requirements Chaos!

If you’re a product manager, you suffer from “requirements chaos.” You have too many requirements to execute on, no matter how valuable each one is. You constantly comb through the list moving them from sprint to sprint and release to release. You strive to come up with designs that knock off multiple customer desires at once. You get some features partially completed but often don’t get to finish them to your satisfaction. There’s always an “obvious” hole in your favorite feature of the latest release that you just wish you could get someone to spend a few days on, but you’re out of time.

“Recognizing that our tool problem is not just about managing a list of requirements is a major realization.”

This sounds like a requirement problem, but it’s not. It’s a process problem. It’s the process of moving requirements out of the way while I work on the higher priority ones – but making sure they aren’t lost as I do so. It’s the process of prioritizing the work I’m going to do in such a way that it’s defensible to my boss and their bosses. It’s the process of making sure I am using my heuristics to help me make the best decisions about what to do next.

Don’t Make Me Think

For example, consider this common situation. You have a desirable requirement that will provide a lot of value, but you know you will not have the capacity to implement it in the next year.

Does any product management tool handle that situation for you? That will, for example, hide it for a year and then pop it up again? Or hide it until the product planning process seems to indicate that it might be of interest again? Or hide it until the product manager says, “Gee, I have a little extra resource for this release that I didn’t expect, what might be a good fillip to add in that will give customers a bit of excitement?”

Every tool I know makes me keep that requirement in mind. Or it makes me put it in some bucket that I’m supposed to remember to revisit later. I have a lot to remember already, and I don’t want this thing on my mind too. In fact, I want it off my mind for a while. I don’t want to have to remember to visit some bucket or other at some random point in the future. Instead, I often end up constantly seeing the list of things that I’ve deferred and making those decisions over and over again. That’s a big waste of my time, but I do it to make sure I’m not missing anything.

I want the system to get me out of this cycle. I want to trust that it’ll help me find that requirement right when it’s needed. Don’t make me use cognitive capacity now, but give it to me when I need it, magically.

I might be asking for a lot, but that’s what I want. And that’s only one example of a process I have to manage in my head, rather than being able to trust it to a tool. (I wrote about another such process-oriented capability I wanted a few weeks ago – call it “the datasheet metric” for a requirement.)

Accept360 had an approach that got me part way there – an analytical prioritization that would surface requirements that aligned with a particular set of priorities. So if next year my priorities shifted to favor that requirement I’d hidden away, it might pop up. But getting that capability depended on my having made a correct set of relationships – which isn’t terrible, except that Accept360 was not good at helping me create those relationships.

Even so, Accept360 was unique in this capability. I think and hope some of the newer tools will  step up to this. In particular ProdPad has a basic analysis that compares “Effort vs. Impact” – which is something like what we had in Accept360. I haven’t validated that their “Impact” metric is as flexible as I’d like. (I talked about an algorithm for analytic prioritization in an article last year.)

The point is our tool problems are not just about managing a list of requirements. And anything that focuses on the list, and managing the list, is just going to move around the chaos for me, instead of reducing it. Solving the real product management problem is going to be harder than that. It may require taking technology to a new level – it’s definitely not just going to be using frameworks to put data on the screen. It will be exciting to work on these tools, and it will take some programmers who are ready to think outside the normal Web 2.0 box and step up to doing some unusual and amazing things.


22
Aug 13

Three More Product Management – Err… Roadmapping? … Tools to Watch

To follow up on my post last week about three new product management tools I’d heard about as of last week, I now have heard of three more.

  • Reqqs – “The smart roadmap tool for product people.” Their initial release will focus, according to their website, on requirement prioritization. This is a topic with which I have some familiarity, so I’m looking forward to seeing what they’ve done to manage this process. 
  • ProdPad – “Your toolkit for better product management.” Of these three products, ProdPad is the only one that’s actually available to use right now. One of their most interesting features, to me, is again a prioritization tool – in which they highlight “Quick Wins” and “Time Sinks”
  • Uberito – “Revolutionary product management tooling for the cloud.” Based on the website, they seem to include some gamification aspects in the product, which I think is potentially valuable, as I’ve discussed in the past

Of these ProdPad is the most mature, being a currently available product. Both Reqqs and Uberito are pre-release at the moment. I have not yet tried any of these, but they are all interesting based on the websites, and I hope to learn more about each of them.

As as aside, it found it curious how many of these new products position themselves as “roadmapping.” Back in my Accept days I did some research on “roadmapping” versus “requirements management” from a marketing perspective, given Marketing’s tendency to shy away from positioning Accept as a requirements management product. I’ll have more to say on this in future posts.


20
Aug 13

The Importance of Tools To Product Managers and Other Humans

In a seminal 1962 paper Doug Engelbart outlined a research program that came to be called “Augment,” short for “augmenting human intellect.” He illustrated the importance of tools to human progress with the following story about the pencil and how society might have evolved without it:

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. The concepts that would evolve within our culture would thus be different, and very likely the symbology to represent them would be different — much more economical of motion in their writing. It thus seems very likely that our thoughts and our language would be rather directly affected by the particular means used by our culture for externally manipulating symbols.

Why do I go on so much about tools? Better tools are key to improved productivity, and productivity is what creates value. All major transitions in human history have been related to new tools.

ABANA style treadle hammer

A treadle hammer, which multiplied the productivity of blacksmiths. When you attach it to a water wheel or to steam power, it helps usher in the Industrial Revolution (image by tmib_seattle, CC 2.0 license)

And product managers are the last group without tools of our own. Everyone else has tools that help them do a better, faster, higher quality job, and that are specific for their needs. Developers? Interactive development environments (IDEs) like Eclipse or Microsoft Visual Studio, plus source code control (SVN or Git), build tools (Jenkins), libraries (JQuery), bug trackers. Engineers? 3D cad systems, finite element modelers. Accountants and finance people? Any number of ERP and backoffice tools. Salespeople? CRM systems like Salesforce.com. I could go on.

But product managers don’t have tools. Or rather, we have a book-writing tool – Microsoft Word – and a finance tool – Microsoft Excel.

That’s why I spent seven years at Accept, working on a tool for product managers. That’s why I blog so much about tools and why we don’t have good tools (yet). And why I’m so excited to see a number of tools coming to market now and recently.

I’ll be posting soon on another batch of product management tools, all new, that I’ve heard about in the past few weeks, as a follow on to last week’s post about Aha, ProdThink, and The Skore


14
Aug 13

New Product Management and Product Planning Tools – Can They Pass the Test?

I complain a lot about product management tools in this blog. I’m happy to say that some people are taking up the gauntlet – and some are even talking to me about what they are doing.

In the last few months I’ve heard about three new tools for product managers and product planners. I have not used any of these products extensively, and some I’ve only seen demos of, but what excites me is that people are still tilting at the windmill that is product management automation.

  • ProdThink (@validately) is focused on managing feedback from customers and prospects on new features and concepts. This is part of the “Build-Learn-Respond” cycle of the Lean Startup. One thing we know from the complexity of product management is that you need to get real-world feedback on your ideas, because your first ideas are usually crap, and ProdThink’s goal is to help you do that better.
  • Aha! (@aha_io) just came out in beta. At first glance the product is extremely ambitious, covering roadmaps, product positioning, and requirements, as well as a strategic analysis capability that reminds me a bit of one of the best parts of my old product, Accept360.
  • The-Skore (@skoresoftware), not yet out in beta, has the tagline “Requirements discovery software for tomorrow’s product teams.” It has a very nice graphical interface (which I’ve only seen a demo of) for capturing requirements and their relationships. 

I have the challenge at the moment of working in a Jira + Confluence environment. I am working on setting up pilots for one or more of these new tools, which with my workflow will be challenging. But I plan to try all of them, and I will give my thoughts back to the community, as well as to the vendors, as I go.


07
Aug 13

The Requirements Management Feature I Really Want

Let’s say I have a great product capability in mind, and it has a bunch of features. (Maybe these are user stories, whatever.)

Some of those features are “must haves.” I can’t really deliver the capability without those. Some of them are “nice to have” – the more of those, the better the experience my customers will have, but they aren’t truly necessary. And some of the features will differentiate this capability from my competitors. We will all have capability X, but my version of X will have feature Q which they don’t have and that customers will find really valuable.

What I want in my requirements management tool is the following:

  • Let me decompose a capability into features.
  • Let me characterize the relationship between a feature and its parent capability – is it a must have, or a nice to have, or a differentiator (or, or, or)?
  • Can I ship it? (All must-have features are ready to ship.)
  • Can I put it on the datasheet? (I am shipping at least one differentiating feature.)
  • Can I demo it? (If I’m only delivering must-have features, then I won’t demo the capability, but if I have some nice-to-have and differentiating features, I’ll show them in the demo

Would this work for you?

 


02
Jul 13

5 More Features That Product Management Tools Are Missing

My post about the capabilities a product management tool should offer was good as far as it went, but perhaps a little wimpy in terms of coming to grips with the complex nature of product management. So I’m going to dive back into it.

One aspect of complexity is “emergence” and it’s certainly true that designing and developing a great new feature is an emergent activity.

A Complex Process for a Complex Outcome

I write a user story as a crappy first draft, based on a few inputs (customer suggestions, my own insights). Then I go and edit it, and it gets better. Then I have some people review it, and they give me comments, and we start to incorporate those comments into the design process, which often means big changes, like cutting out whole chunks, or dividing the story into multiple features, or creating a whole new epic. At the same time, the team (because it’s a collaborative process) is not just “elaborating” the story, but elaborating its relationships to other things in our world, such as customers who will be affected, or competitors we may be able to respond to.

And there’s always the situation that when you first try the design out in working code, it just isn’t that nice to use. It might just be a matter of tweaks, but sometimes your fundamental concept of the interaction turns out not to work in reality. At some point, after a multitude of changes like this, you have a feature that’s usable, and engaging, that has been tested by users (perhaps in an MVP), and delivers value to the users – and is likely very different from your original concept.

Every input has the potential to drive not just a small change but a large change

The process this feature went through was far from “here’s a suggestion, implement it.” It was far from simply elaboration. Every input had the potential to drive not just a small change but a large change (a familiar aspect of complexity). Some inputs, indeed, resulted in eliminating parts of the design.

How Tools Can Support This Process

In my experience, this is the normal way features come to market. But I have yet to see a product management tool that recognizes that the entity is going to change a lot of over time, and which supports and aids in that process. Sometimes you have to be able to say to the team, “All that stuff we talked about before was interesting, but forget about it – the feature is now these new things.” And if the tool supported semantics like that, it would be a load off my mind.

Other related capabilities that I would love to have:

  1. Transcluding other information
  2. Helping break the story up in a useful way if it gets too big or unwieldy
  3. Versioning stories or groups of stories
  4. Combining the story with other stories that are related or overlap
  5. Creating dependencies between stories

Existing tools don’t support these capabilities well. Of course, you can do all of this in nearly any tool, even Microsoft Word or Excel, but the point is that means you have to manage it all, track the relationships in your head, find the duplications, make the copies, whatever it might be. But these are things that computers are good at. If the application took care of them, you’d have more cognitive capacity for being creative.