Monthly Archives: November 2007

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.

Product Management and Open Source initiatives

Ran across this posting on the Infoworld site. Some interesting tidbits here. And if you think working as a PM in a commercial ISV is tough, it’s much more complex in an Open Source environment where developers clearly have a lot of pull. But, some things are the same all over. For example, the Engineering view of what Product Managers do:

When I joined MySQL four years ago, there was quite a lot of debate about product management. We didn’t actually have any product managers and the view in Engineering was “we don’t need ‘em.” The rationale was that we were so far behind in implementing features requested by customers that there was no need to have another opinion. “We already know exactly what we need to do” or “The Community tells us what we should focus on” were typical responses.

So the engineering view is that Product Managers are only focused on feature prioritization. I worked for a company that had that view. I said to the head of the PM group, that I didn’t join the company to be “requirements boy”. i.e. it’s not just about collecting and prioritizing requirements.

The post goes on to describe how the engineers were convinced that they needed to have Product Managers.

By focusing on the skills of the candidates rather than the grey areas of the role, it became a much more productive discussion. Everyone saw that they brought a real world perspective that would be valuable. And we were successful in recruiting the candidates. A few months later, the question became “Where do we get more guys like this.”

I think this is a good strategy if you work in an environment that doesn’t understand the need for and value of Product Management. Identify the gap in the company and show how the PM team can fill it. It may not always work, but in my experience, there is rarely an overabundance of real-world experience of the target audience inside a software company.


Market segmentation, or lack of it at Facebook

I came across a new blog, a la 360, which just started a couple of months ago. The author recently posted a couple of articles related to Facebook. One blog asks “Which problem is Facebook solving?“. Another discusses market segmentation WRT Facebook.

I like both articles as they ask straight forward and fundamental questions that we all should be asking ourselves (if we aren’t already) when looking to create a new product or service. Now one could argue that without clearly identifying a target set of problems or clearly segmenting the market, Facebook is more successful than 99% of internet applications, so why bother?

The issue is not about Facebook, but simply about reminding ourselves to do our homework to help improve the chances of success of our products. For every Facebook that succeeds, there are hundreds that fail.


Product Manager vs. Product Management (part 2)

In part 1 of this series, I talked about the lack of maturity in the product management role in technology companies. Computer technology and software themselves are rather immature, and given the rate of change in the computer technology industry, that immaturity will be here for some time.

Maturity takes time
It took over 80 years — from the introduction of Ford’s Model T in 1908 — for the automobile market to reach a level of what I would call maturity. And by maturity I mean the ability for manufacturers to consistently produce high-quality cars and trucks that consistently deliver value and address market needs. OK, not all car companies do this, :-) but companies like Honda and Toyota certainly do and they have proven that it is possible to not only systematically do this, but to do it even in the face of severe economic and political obstacles.

I recently got rid of my 12 year old Honda Civic. We bought it back in 1995 just after we had our first baby. Later, when we bought a minivan (Honda Odyssey), the Civic became my daily commuter car.

I drove that car every day to work and back for about 10 of the 12 years: on average about 70 km per day. I would have kept driving it, except that a few weeks ago, someone drove into the side of my car as I was driving home. It was dark, and raining, and there was heavy traffic on the road. Luckily no one was seriously injured. After over 220,000 km, I had to turn in the keys on the Civic.

Recently I picked up my replacement car. It’s a great little car and driving it to work is easy. And guess what, it’s a 2003 Honda Civic. Yes, I went out and bought a newer version of the same car. And why wouldn’t I?

My previous Civic worked, plain and simple. It didn’t require special maintenance of any kind. I’m not a great car owner to be honest. I’m not always timely with my oil changes. I don’t check the tire pressure as often as I should. But my first Civic kept on working over the 12 years and had someone not run into me, I wouldn’t have gotten rid of it.

And coincidentally last month, Consumer Reports named several Honda and Toyota models as “Good Bets” for vehicles to last for 200,000 miles (320,000 km). Funny how no American makers made the list.

And why would they? The Japanese auto makers have transformed the automobile industry in the last 35 years. From a humble start selling low priced, low quality cars, both Honda and Toyota have embraced continuous improvement in all aspects of their design and manufacturing process. Numerous books have been written about these companies particularly Toyota:

So what does this have to do with software product management? Everything.

Product management must keep the process of continuous improvement in mind at all times. This not only means continuous improvement in the products delivered to the market, but continuous improvement in the processes, both internal and external, that deliver those products to market.

This is where the function of Product Management must be considered as opposed to the role of Product Manager.

Many companies mistake the two as being the same and that is a source of problems. Consider the analogy of the function of Engineering and the role of a software engineer. The former includes the latter, but there are other roles in engineering, such as architect, development lead, interaction designer, tester etc. that help compose the role of Engineering in the company. Each of these roles plays a well defined part in ensuring the output of Engineering meets demands and expectations. The same is true for the function of Product Management.

Software Product Management must focus on optimizing the business side of software, ensuring that the R&D investments made in developing product are the best ones given available information and that the processes used to roll out and take products to market are working to maximize the return on those investments.

Granted, this is not how all software companies view Product Management, but to be honest, they should. Because in reality, if Product Managers aren’t doing this then who is? Finance? Marketing? Sales? Sr. Management? Sr. Management is responsible for the overall business, and in small, single product companies, that may overlap completely with the business role of the PM. But in any company that has multiple products, Product Management must be focused on optimizing the business of the products and product lines they manage.

Now I’m not saying that Product Management should ignore the technology. No, that is a key aspect that needs to be addressed, but one shouldn’t assume that the same Product Manager, who is looking out for the overall strategy and business objectives of the product or product line can also focus on the technical details of the product as well.

In the part 3,  I’ll delve into how to decompose roles in the Product Management function to maximize the output of the team.


The rest of the series
Product Manager vs. Product Management (part 1)
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

Transparency in Product Priorities

Product managers are always looking for better ways to get feedback from customers on which new features are most important. A few companies have embraced the “Web 2.0″ model and are putting their feature candidate lists out there for everyone to see and comment on.

Dell has Dell IdeaStorm where anyone can register and submit their ideas and vote other ideas up or down.

Salesforce has, not surprisingly, creates a SaaS service which they sell to other companies but which they also use themselves. IdeaExchange is viewable by everyone, but only registered Salesforce users can comment or vote on ideas.

Sun has always made their bug (and FR) database for Java publicly available, which was certainly great back in my days as a Java developer.

It’s an interesting idea to implement this for the product I’m currently working on, but is it always appropriate? Just like with roadmaps, it’s not a good idea for small companies to put too much data out in public as it gives too much away to competitors. For companies like, Sun and Dell, there’s not much here that’s really a secret; it wouldn’t take a competitor very long to figure out the gaps in specific functional areas of Salesforce. But consider your own product – would giving away these details to competitors be a bigger drawback then the greater level of customer engagement you’d get in return?