Jul 14

Love the Problem, Not the Product

DeathtoStock_Wired6I’ve got a couple of great essays in the hopper (I know I promised a followup on why Excel is not great for product managers), that will be baked soon, I hope.

But in the meantime, I wanted to let you know about an essay I wrote recently for Mike Smart’s PM 2.0 blog.

What’s the most important thing you should worry about as a product manager? I think you’ll be surprised by my answer – and my examples of markets who have figured that stuff out.

Product managers often place the cart before the horse. We love to think about the product, the features, how “cool” the UI is, and how we can make the product better.

But when it comes right down to it, your product is the third most important thing you should be worrying about.

Yes, you read that correctly. There are two much more important things than your product you should focus on if you want your company to be successful.

Read the rest of the essay here: Love The Problem, Not The Product.

Let me know what you think of this (not so) radical position in the comments!

Jun 14

Why PMs Are Frustrated With Excel – But They Don’t Change

Functional requirements template in Excel (Image by IvanWalsh.com, CC 2.0 license)

Functional requirements template in Excel (Image by IvanWalsh.com, CC 2.0 license)

As PMs we know that we should “write things down” instead of trying to keep them all in our head. (Even PMs’ heads are only so big.) We have a few choices for this:

  1. Use a tool we already have on the desktop (Excel, Word)
  2. Use a tool that is really for something else, but might work (Jira, a wiki)
  3. Use a tool that’s designed for product managers

Mostly, product managers choose #1, ending up with Excel for requirements management, but they are frustrated – “There must be a better way.” So they evaluate the tools meant to replace Excel for product managers, but remain frustrated. Why?

We Love Excel – To A Point

Excel is incredibly good for lists of things, and at first glance, requirements seem a lot like lists. Indeed, for a lot of companies, most of the requirements are one-liners – often called “tweets”- and so they fit into an Excel list well.

And Excel – for lists anyway – is easy to use. It’s easy to add a new item, it’s easy to “improve” the schema by adding a column. You can color the cells in a spreadsheet easily, either ad hoc (i.e., making a row red so you remember to do some work on it later), or via a formula (i.e., making all the requirements that are 30 days from scheduled release orange). It has sorting and filtering built-in. What’s not to like about Excel?

The Problems With Excel

Well, we do know there are some things that are problematic with Excel:

  • It’s not multi-user. It’s hard to have multiple people making changes to the requirements, or, honestly, to have multiple people reviewing the requirements. This can be partially addressed by putting the spreadsheet into the source control system, or by putting it into Sharepoint, but we all know that’s pretty much of a hack.
  • Excel doesn’t do well with lots of text, especially if it’s formatted. Once your requirements become more than just “tweets”, you often have to put that information into another system, whether it’s a Word doc or a wiki or whatever. Of course, it’s easy to put a link to that rich content into your spreadsheet, so as long as referential integrity is maintained, that’s not too bad. Just another hurdle to jump over, but it’s not very high.

Requirements Are Not Lists

But the bigger problem with Excel, from a product manager’s perspective, is not related to those two issues, important though they are. It’s that intrinsically, requirements are not really lists. They are really nodes on a “graph” – that is, they are things that have relationships to other things. And those other things can be both requirements and entities like customers, marketing themes, strategies, competitors, and all the other things in the product manager’s conceptual world.

This seems theoretical, except that all those other things impact critical product management activities like:

 If your tool doesn’t support those relationships then you have to keep them in your head. That’s difficult, and it means your cognitive resources are not being used as productively as they could be.

Excel sees the world as lists, but the nature of the product management “schema” is that it’s a graph.

So Why Not Use A PM Tool?

Given all this, why don’t more people choose the third option for “writing things down” – the product management-specific tool? Well, there’s a good reason. Although most product management tools address the first two problems with Excel:

  • Multi-user support
  • Support for rich content

Unfortunately, just like Excel, they see the world as lists, and don’t know about the graph. That’s a big problem. You’re no better off than you were with Excel.

I’ll talk more about this problem, and give some concrete examples, in my next post.

For another take on this, check out Anders Lindorf’s recent post on the SensorSix blog about “How to Replace Excel As the Product Management Tool of Choice.”

Jun 14

A Weak Value Proposition Is A Symptom, Not A Disease

Templates - powerful when appropriate - like the one I describe in this post. (Image by Bill Bradform, CC 2.0 licensed)

Templates – powerful when appropriate – like the one I describe in this post. (Image by Bill Bradform, CC 2.0 licensed)

This post was inspired by an article about positioning that Gabriel Steinhardt (@blackblot) posted on LinkedIn recently. One of the best tools for coming up with good positioning is a good value proposition.

This term, “value proposition,” is thrown around a lot by product managers and product marketers, but as far as I can tell, mostly they don’t mean anything specific by it. There’s a lot of value in putting some structure around the value proposition and in this post I will tell you how I write one.

Recalling from Product Management 101 (you took that, right?) your product needs to:

  • Solve a problem
  • For a segment that’s willing to pay for the solution, and
  • Be better in a meaningful way from competitors

The value proposition should capture all that.

I use the value proposition template from Crossing the Chasm, by Geoffrey Moore. The template is:

<Product> is a <category>, for <segment>, that provides <benefits>. Unlike other offers in the category, <product> does/has <differentiators>.”

(Obviously, as you fill in the blanks here, you can do some wordsmithing.)

For example:

The iPod is a digital music player for everyone who wants to listen to their own music. It can hold 10,000 of your own songs and play them in any order you want. Unlike other music players, it’s simple and intuitive to use, and it’s connected to Apple’s iTunes, giving you instant access to millions of songs, including the latest hits, your favorite classics, and everything in between.

You want to capture the category into which the product fits, who the product is solving a problem for (the segment) and the problem it solves for them (the benefits), and why it’s better than the competitors. If you can do all that clearly, not only do you have an excellent basis for all the more detailed marketing you need to do, but you also have an excellent elevator pitch.

The value proposition has another benefit for you, though. If you can’t create a good one, it’s a good indicator that your product either isn’t solving a meaningful problem for a segment, or that it can’t be differentiated. The things that enable products to win – solving a market problem, differentiating from competitors – are laid bare in the value proposition. And if you can’t articulate them, how is your salesperson going to be able to pitch it – or your prospect understand why they should pay money or time for it?