Category Archives: Blogroll

Variety in Product Management Blogs

We’ve compiled a pretty extensive list of Product Management related blogs. There are almost 60 of them so far.

It’s interesting to see some of the patterns in the blogs and how they’ve positioned or differentiated themselves from each other. Here are some of the 50+ blogs in our PM blog roll, and some comments/advice for some of them.

Named Blogs

A bunch of bloggers named their blogs after themselves: Let’s see now… Carl has a blog. So does Roger. As does Grant and Joao, Rob, Tim and Tyner…. er, I mean Scott. 🙂

OK, am I alone, or did a lot of you at first think Tyner Blain was a person? BTW, did I miss anyone?

Hmmm..there must be some female PM/PMM bloggers out there with blogs named after themselves. Or are most egomaniacs men? 🙂

<Adjective> Blogs

First there was Good PM, and the Cranky PM. Then came the Purist PM. Now, there’s the Brutally Honest PM.

  • Good – Jeff, good to have you blogging again. When’s the next post?
  • Cranky – more frequent posts please or is the crankiness subsiding?
  • Purist – good blog, but why are there no date stamps on your blog posts? Is that a Blogger “feature”?
  • BHPM – I’ll be brutally honest. You’ve only had 1 real post. It was on October 4, and it’s about cloud computing. Let’s see some more frequent honest brutality.

Product Management <stuff>

There are  a number of blogs with some what similar titles. And in another striking similarity, they are all quite good! I have a soft spot for Product Management Zen because it’s tagline contains the word balance, which is one of the words I use to define Product Management.

We’re Strategic

Strategy is a big part of Product Management, so of course we have the following:

We podcast

I really enjoy the podcasts on both of these blogs. And, full-disclosure, I’ve been in podcasts on both blogs.

  • The Heretech – my podcast with Tom Grant where we have a long discussion on important topics related to Product Management, yet never utter the word “agile”.
  • Product Management Pulse – my podcast with Michael Ray Hopkin, where Michael and I discuss what makes a great Product Manager.

Blogs from Around the World

I’m happy to see PM and related blogs from many different countries. I’m sure there are many more out there, so if you know of some, or write one(!), go to the Blog Roll page and let us know about it in the comments. We’ll add it to the list.

BTW, in this case, “around the world” means NOT in the United States! 🙂 At the end, I will give a bit of a shout out though to my Canadian blogging pals. There’s a bunch of us up here and we need to stick together. Otherwise, in alphabetical order by nation:

And the Canadian Contingent:

Take look at the Blog Roll and let us know if there are other blogs we should add.


Share this article:

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine


Product Management Parody Playlist

Tom Grant has a post a couple of weeks back with a Product Management/Marketing playlist. As Tom wrote:

If you were to make a musical version of what it’s like to be a tech PM, here’s what you’d put into the soundtrack.

I like the idea, but as a PM, I couldn’t simply create a “me-too” list. 🙂

So here’s my variation: The PM parody playlist. i.e. PM/PMM oriented parodies of famous songs.

  • Bugs in my Product – The Monks
  • We built this Product – Starship
  • I left my code in San Francisco – Tony Bennett
  • Sympathy for the Tester – Rolling Stones
  • Gimme Data – Rolling Stones
  • Software Product Management Blues – Bob Dylan
  • Shock the Market – Peter Gabriel
  • I still haven’t got what I’m asking for – U2
  • Roll Over Product Owner – Chuck Berry
  • Take me to the website – Al Green
  • Market Love – David Bowie

I’m sure there’s many others. Any that you’d like to add?


New Blog Roll


We’ve updated the blog roll and given it it’s own page:

Take a look and if you know of any Product Management, Product Marketing or other relevant blogs not listed, leave a comment and let us know and we’ll add them.



Primary product requirements

Some products seem to fail at their primary requirements. What is the primary requirement of your product? Here are a couple of examples from everyday life. I hope these examples help you reflect on the primary use case of your product and how well it delivers.Which one is the salt spreader?

Example 1: Salt Spreader

This past Sunday I arrived at church and found the parking lot to be one big sheet of ice. It was worse than a skating rink because the temperature was above freezing, so the ice was thick but melting and thus wet. Some cars were sliding around with no traction whatsoever. Worried about the others arriving, I quickly found the salt spreader, pictured here alongside the tool that I ultimately used to spread the salt. You see, the salt spreader (blue) works very well when you have traction; when you push the spreader, salt falls through a hole in the bottom of the basin and a spinning disk throws the salt horizontally and very effectively distributes the salt across a wide area. The trouble is that when the spreader is on ice, the spreader simply slides along the ice, the wheels don’t have traction, don’t turn, and therefore the spreading disc doesn’t turn. This renders the tool completely ineffective. I believe I could spread salt on a surface of dry pavement, and no doubt it would work to spread grass seed on soil. But that’s not the primary use case! Normally when you’re spreading salt, you’re spreading it on a sheet of ice.

Faced with this deficiency, I pulled out the large snow shovel, filled it with salt, poured concentrated salt on the ice, and then went back with a push broom and spread the salt.

The snow shovel became my salt spreader, and the spreader sat idle, no doubt completely ashamed of itself and resentful of the designers who failed to take into account the most common use case.

Can’t you just picture the design requirements?

  1. Spreader must carry two full bags of salt.
  2. Spreader must throw salt to a radius of 10 feet when pushed.
  3. Spreader must allow user to select salt concentration. (There is an adjustment to control the size of the opening in the basin through which the salt falls.)
  4. etc …

Provided with these requirements, the engineers noticed that they had a grass seed spreader that could be easily modified to spread salt rather than seed. The hole and spreader geometry were adjusted to handle salt, and voilá, the product is ready to ship!

All of the requirments for this spreader could be stated in a single use case or problem statement:

  1. Spreader must allow user to distribute salt at a 10 feet radius while the user pushes the spreader across a sheer ice surface.

Example 2: My sock drawer

(These are not mine!)

How many unmatched socks do you have in your drawer? It absolutely mystifies me how this happens, but I have 25-30 single socks with no apparent matches. Somehow they disappear, and even when they don’t, I have arrays of similar-but-not-quite-matching socks, one array for each color; blue, black, beige, etc.

I don’t think I’m alone. In fact a search for “Lonely Socks Club” reveals that many people have written about the plight of the single sock that has lost its match. About 10 years ago a Canadian radio program had a feature where listeners could send in their unmatchable socks, and the radio host would diligently look through all the socks to match them up, and when matching socks were found, he would call the sock senders to piece together how these socks might have been separated. This segment was so popular that within a short time the radio station had to implore its listeners to stop sending the socks on threat of burning all socks. They ran a contest to determine what to do with the pile of socks, and the winning entrant proposed to mould the socks together into a couch!

All that to say that the lonely sock problem is pervasive.

So if you’re selling socks, what is your primary requirement, use case, or problem statement? Of course, socks need to be comfortable, withstand dozens of wearings without losing their ability to hug the calfs. But that ability is not a differentiator; it sounds like table stakes.

Color and fabric might be good buying features too, but all sock vendors have a variety of these.

For me, the primary requirement of socks is the ability to easily find its mate after the laundry is done!

Easy to match!

I realizePlain but still easy to matchd this when I bought the beauties on the left a few years ago. In the picture you can tell that I’ve nearly worn them out, probably because I like them so much. In all visible areas, they are plain black. But the toes, heels, and cuffs, are a distinctive color. I like to think of the color as my little secret under my shoes.

And if you don’t like that idea, on the right are some socks with a distinctive logo on the upper calf. Despite being plain black socks, I can always match these ones up without looking closely at the fabric.

So if you’re designing socks, here is your primary use case, after you talk about the “ilities” which in sock-land I suppose are wearability, breathability, and so on.

  1. User does laundry for 1, 2, or 5 people, producing a pile of socks. User wants to quickly match socks with identical matches without mistakes.
  2. User opens unsorted sock drawer in the morning, before putting on glasses, and before his morning coffee. The room is dark and he can’t turn on the light because someone else is sleeping in the room. User must be able to quickly find two socks that match. Bonus points for being able to identify whether the sock is blue, black, or some other dark shade, without benefit of good lighting.

When I shop for socks, I keep looking for socks that advertise themselves using the above use cases. I think socks with those features would outsell the competition, with little or no increase in manufacturing cost. Furthermore, the price sensitivity would also decrease, because I care more about matching socks in the fuzzy dark morning than I do about an extra buck for the pair of socks.

Does any of this matter for your product? Short answer: Yes.

When I was at Wily Technology (now part of CA), our systems management product had three fundamental capabilities that no competitor could match:

  1. Product worked in a production Java EE environment with near-zero impact on the running system.
  2. Never take the managed application down.
  3. Provide useful data immediately.

The early user interface was not as good as many competing products, and competitors had many other advantages. But these basics enabled our core buying use case:

  1. User has high-volume, high-value applications that exhibit problems only under real-world situations, and frequently only after hours or days of successful execution. The user must be able to monitor the running application in real time, under real-world production applications, and when problems occur, get diagnostic information quickly and easily. The problem may never be reproduced.

The company moved on to sell proactive monitoring and management, and this of course is necessary. (Monitoring commands a far higher price point and buyer profile than diagnostics.) But in the early days, and in fact for several years, Wily was the only player in the market that could satisfy the drop-dead diagnostic use case above. With that solved, buyers would spend big bucks to ensure they continued to have this ability.

In other companies that I wish I could name, I’ve seen products where we could do myriad impressive things, but we simply didn’t solve the primary problem, or enable the primary use-case of our buyers. That was, um, a much more difficult sale.

The trick is that you need to know what those problems and use cases are. Stacey at Pragmatic Marketing (channeled by Steve) wrote a great article about this point. Your job is NOT to gather requirements, but rather to observe them. The examples above show this clearly. If you talk to sock wearers (shouldn’t be hard to find a few), you’ll almost never get the differentiating use case that I suggest above! They’ll tell you about color, how the sock hugs the calf, stays up, but allows for circulation. I doubt you’ll have many sock-wearers tell you about the sorting problem.

What is your prospect’s primary use case or problem statement? Are you enabling the use case or solving that problem? Share your experience with us!

– Alan

PS: Win/Loss Analysis is a great way to start figuring out the primary use case of your buyers! Many of our readers complain that they are not allowed to do win/loss, or are simply too busy. If that’s your situation, here are some strategies that might help:

Another new Product Management Blog

Here’s another new blog worth following.

Make sure you read the article entitled Utilize Patterns to Catalyze Innovation. Good stuff.

One very good point in the article:

I thrive on customer feedback, but I often forget that you cannot rely upon the customer to innovate. Let me say that again – you cannot rely upon your customer to innovate for you. Countless studies have shown that customers simply do not make the leap required to be truly innovative.

One objectives of speaking to customers (and partners, and lost accounts and in fact any other outside source) is to not simply understand what they want, or what they need, but to really understand their objectives and goals, their alternatives, their constraints, their dependencies and their dependents.

It’s not just about defining and understanding personas, but about the connections between personas and the motivations that drive them. This is not easy stuff to collect and is certainly not something that can be “time-sliced” into one’s job.

But, a small investment in this insight up front, will pay HUGE dividends downstream, both in optimizing internal efforts, but also in being able to create products that map well to market needs.


Product Strategist Blog or is it a Nooz?

Just came a cross a great set of articles written by David W. Locke on the web site

I don’t know what “Nooz” means (a play on the word news?), but David’s articles are pretty good. Some deep thought on issues affecting Product Management.

Some of them line up with some of my findings (will publish them soon, I promise) on the problems in Product Management.

So, take a look at David’s articles. They can be found at:


New Product Management Blogs

It seems you can’t go to a Product Management blog these days without running into a post on Win/Loss analysis! 🙂

Two new Product Management blogs both recently covered the topic.

Stewart Rogers started Strategic Product Manager on January 3. One of his first posts is entitled:

Your Strategic Friend, Mrs Win/Loss Analysis

Stewart writes:

A big part of being successful is to refine what is working today and make it better. Not so much from a “make faster horses” perspective, but maybe you can extend the reach to a new market or better enable the sales team to win some of the losses with stronger positioning.

Sue Raisty-Egami also has the beginnings of a great blog on the home page of her consulting company SURE Product Consulting. She too posted a Win/Loss piece recently:

Who should do Win/Loss?

Sue explains the logic behind performing Win/Loss:

…without understanding why you are winning deals and why you are losing, how are you to know what you’re doing right and what you need to change?  Are your sales people blowing it by not properly qualifying the deal or understanding the prospect’s problems?  Is your product a true winner or is it deficient in critical ways?  Are your products priced competitively?  Are you lacking in other components of the big picture, such as professional services or customer support?

Both blogs are in their infancy, but each already has several informative posts; foreshadowing more good content to come. Check them out and add them to your regular reading.