Corporate Blogs redux

I’ve had a few good responses to the questions about corporate blogs, but only a few out of several hundred hits.

Which makes me wonder … do any of you read corporate blogs? Blogs at all?

Send me a note … do you read blogs? Which ones? What do you like?Any corporate blogs?

Come on, dear reader, be heard!

Alan (email me)

Question for you: Corporate Blogs

I mentioned earlier that my company has a blog. So, what’s new about that? Well, like many things, there are good blogs, bad blogs, and good and bad corporate blogs. I dislike blogs that are blatant marketing pitches, and it’s clear that readers don’t like them much either. One of my recent entries was picked up by Jesse Wilkins, where he gave a very nice compliment, namely that “I can recommend it comfortably as a good example of how to do a vendor blog”. Thanks Jesse!

Blogging for my company has got me thinking, and Jesse’s comment focused it for me: what makes a good “vendor blog”? In a future post I would like to write about corporate blogging from the perspective of product management and marketing. But who better to ask about this topic than you, dear reader?

Here are my questions for you:

  1. Are you involved in your own company’s blog? If so, drop me a note and tell me a little more.
    1. What is the purpose of your blog?
    2. What works for you and your blog?
    3. How do you measure success?
    4. How do you avoid irregular posting schedules
    5. How do you deal with company confidentiality vs. transparency, and … here’s a hot issue, how do you share openly while staying “on message”?
  2. Do you read any blogs regularly? If so, what are they? What do you like about them? Are there any corporate blogs on the list?
  3. Any war stories about publishing your content would be most helpful.

I hope to hear from you. You can email me here: Alan Armstrong.

More Haiku madness…

The CrankyPM,
Pivotal and Steve Johnson
inspired me to write

Product to be launched
Have to find the perfect name
Damn, all good ones gone

Good Beta Programs
Don’t just happen, but require
planning and focus

Customer input
Never enough time for it
Let’s build something now

Can’t work together if we
have different goals

PMs who have no
domain knowledge suffer great

End of the quarter
Must help the sales people but
I don’t go to Club

Product Management
Business Optimization
Not Requirements Boy!

What’s axiom 2?
Yo! Nail it then scale it!
Must remember that.

Got an idea?
Pass it through Stage-Gate process
It’s bound to kill it.

Design software well
It’s all about the user
Apple knows this rule

Customer Support
Gotta really love those folks
Really smart, thick skinned

Be a great PM
Read this set of articles
What a blatant plug!

Prioritizing Features does not equal Product Management

I came across this blog post today: How to Outsource Product Management to Customers.

With a title like that, I had to read it. The post starts out well:

Product management is one of the most critical functions for any enterprise software company.

Hard to disagree with that! 🙂

But then the author writes:

As a product gets used by more and more customers, requests for new features start to pile up, and the job of a product manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep.

Somehow that doesn’t jive with the first line, particularly if you end up “outsourcing Product Management.” Yes, prioritizing requirements is an important part of a the role of Product Management, but managing customer feature requests is only one small segment of the work Product Management performs.

The post on “outsourcing product management” is about an open source software company, Intalio, and how they fund development of key features in their product.

Their process works something like this:

  • Identify which features should be developed by having customers discuss and vote on a public list of candidate features
  • Estimate the efforts to develop the top rated features as ranked by the community of customers.
  • Solicit bids from customers for the development of the feature
  • Close the bidding process and start the actual implementation once enough customers commit to paying for it
  • Once a feature is complete, decide how the functionality will be made available to customers

While this process does work for Intalio, it is not really “outsourcing Product Management”, because, and perhaps it needs to be said explicitly:

Wikipedia defines Product Management this way.

Product management is an organizational function within a company dealing with the planning or marketing of a product or products at all stages of the product lifecycle

The emphasis on “at all stages” is mine, but it is key when thinking about the function of Product Management.

Product Management, particularly in technology companies, must be seen as a business optimization function across the product lifecycle, and NOT simply as a technical role in the planning of products.

Let me paraphrase myself from a recent post if I may:

If all a PM does is collect and prioritize requirements, then their job title may as well be “Requirements Boy” or “Requirements Girl”.

That is not the description of a strategic role. Although unfortunately there is no single, widely implemented definition of Product Management, the folks at Pragmatic Marketing have done a great job at succinctly defining areas of focus and roles for the Product Management function. Their famous “grid”

pragmatic marketing grid

(click to enlarge)

shows a very broad range of activities under three different roles. Now, I don’t necessarily agree with exactly how this grid is laid out, but that is a minor issue. Notice that “feature prioritization” is not even explicitly listed in any of the boxes!

Two of the boxes in the middle column: Market Requirements and Product Roadmap, come closest to the feature prioritization bucket. But also notice that the one box is “Market Requirements” and not “Customer Requirements”.

Customer requirements are a subset of overall Market Requirements, and thus anyone or any company that views the single focus of Product Management as collecting and prioritizing requirements doesn’t understand the need and value of Product Management. It’s like saying that the role of Marketing is to create brochures, or the role of sales is to meet with prospects.

So, I hope I’m not simply preaching to the converted here, but this past week, I’ve come across two separate blog postings (1, 2) about Product Management at Open Source companies, and in both cases, the incumbents at the companies — developers at mySQL and the founder of Intalio — pigeonholed Product Management into the “requirements prioritization” bucket.

Any ideas on how to change this misconception? And soon?


SaaS for Systems Integrators: Danger lies ahead

I recently posted an entry on my company‘s blog. And the previous sentence has the highest density of self-interested links per word than any other on our blog. In that corporate blog entry, I drew on the context vs. core argument I made in a previous blog entry and opined on the future for Systems Integrators. (Full disclosure: I even reused some of the content from this blog. Tsk Tsk.)

 Updated: Here is the link to my argument, specifically, that Systems Integrators are in trouble with SaaS on the horizon.