24
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.”


19
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?


18
Jun 14

Prioritizing Features – The Simplest Possible Example

Acme - Wile E. Coyote's favorite supplier. (Photo by Elliott Brown, CC 2.0 licensed)

Acme – Wile E. Coyote’s favorite supplier. (Photo by Elliott Brown, CC 2.0 licensed)

Say I have one feature in the backlog that would delight Acme Inc, and another feature that would delight Barclay Instruments. My strategy (i.e., my prioritization criteria) says that Barclay is the more important customer. If I can only deliver one feature, which one will it be? Obviously the one that Barclay wants!

Because I have a big backlog of features I could deliver, I want my prioritization scheme to help me pick the features that match my strategy the best. Tell me which features will further the strategy, and hide the ones that will not contribute.

If my boss comes to me tomorrow and says, “Oh, we lost Barclay, let’s focus on Acme,” then it’s also obvious which feature becomes more important.

But notice that the features themselves didn’t change in response to the strategy. What changed was their strategic value. The fact that Feature 1 is appealing to Acme is intrinsic to the feature. The fact that it didn’t align with the first strategy, and does align with the second strategy, is purely a function of the strategies.

Real-life strategies are more complicated than simply “Barclay Instruments is the most important customer,” so the calculation of strategic value gets harder. But the point remains – the strategy doesn’t change the feature, it just changes the value of the feature for that strategy. Another way to think of this is that the strategic value of a feature is a “point in time” value, that changes when the strategy changes.

The problem I see with many of the requirements (feature) management tools that include prioritization functions is that they munge the prioritization criteria (point-in-time data) into the feature. Essentially what they’re doing is to denormalize the data. And just as with a database, denormalizing means there is a big maintenance cost when the prioritization criteria change. When the strategy changes, the features also have to change. And this can happen a lot as in the example.

In other words, with most tools I’d have had to put in a score for how well the feature matched strategy 1 (Barclay) into both features. And then when the strategy changed, I’d have to go back into both features and change the score again.That’s a lot of work if my big backlog is more than two features!

For a better approach, check my post on prioritization schemes. Or stay tuned to this blog – I’m sure I’ll be following up. Because to enable my idea, you have to support relationships in your requirements data model, and none of the tools do that very well.