Day: May 27, 2008

links for 2008-05-27

Becoming a product manager when you aren’t one already

Being one of the top Google hits for “product manager resume” has its responsibilities as well as its perks. I occasionally, as I was today, get contacted by people trying to figure out things about the product management career path, and sometimes they ask really good questions. Today my correspondent asked, essentially, how to become a product manager. It’s trickier than it sounds, since you can’t really go to school to become one, and there’s not (yet) an independent certification that you can study for at night to build the skills, as there is for project management. So how do you build the credibility to become a product manager when it seems you have to be one to become one?

There are two ways that I’m aware of to become a product manager:

  1. Start as an entry level product manager at a firm, generally as an outside hire.
  2. Get promoted internally to the position.

Option #2 is hard, particularly if you’re coming from a technical discipline (I’ll explain why in a minute). Most firms that I’ve worked at have a hard time figuring out how to take someone out of what they have always done and put them into a role where they could contribute, but which would be a completely different classification.

#1 is also hard, because you have to convince the new company to hire you without the experience. This is where the MBA helps; it’s a signal to a prospective employer that, despite a lack of experience, you have the basics of what it takes. This is actually why I took the MBA–I knew I wanted to learn some business fundamentals about finance and marketing that I wasn’t getting as an engagement manager and architect in my job at a consulting firm.

Are there ways to do #1 without having an MBA or a product management job beforehand? This is probably harder than option #2. Basically, you have to come up with some other way to prove that you are product management material. The good news is that you can do this by looking at what a product manager does and figuring out how do to some of the things inside the scope of your current employment. Maybe you can get some opportunities to work directly with customers and taking their feedback. Maybe you can build a track record of being really, really good at documenting what customers want and building user requirements. Maybe you can take some opportunities to build internal business cases for taking on a new project.

So why is it so hard to become a product manager from a technical background? Why do some people find it easier to move from a marketing position than from a development position into product management? The reason is easy: the skill set required for marketing and product management overlap, to an extent. Marketing folks need to look at the market, figure out what companies’ problems are, and identify what it takes to get them to consider your product (oversimplifying grossly). Product managers look at the market, identify what business’s and users’ problems are, and identify how to build a product (or modify an existing product) to solve those problems and meet those needs. The first two skill sets are common; the last skill set is where there are specific disciplines that come into play.

I’m sure I’ve insulted just about every marketer or product manager out there with what I’ve just written. Anyone want to take a crack at removing the noxious generalizations?

Greatest hits, revisited: Whither SOAP?

I’ve been doing a bit of clean up on some of the early days of my site. Back then, I used Manila’s “story” feature (akin to WordPress pages), and a bit of code that allowed you to edit the front page of the site every day, flipping the old version back into the archives automatically when the new version was published. Over time I transitioned to using the “news items” feature of Manila extensively (what WordPress and just about every other blogging platform calls “posts”). When we did the WordPress conversion, some of my stories were translated into posts and others into pages. So I’ve been going through and changing a few over to posts and backdating them so that you can navigate the site with the calendar. The work isn’t done, but you can go back and read Esta’s protoblog now, and the Mothman’s trail report (or you will be able to as soon as I fix a bug with the path names).

Along the way I turned up some of my early “greatest hits,” those things I wrote that got a lot of people reading the blog and pointing to me, and that encouraged me to keep going. The earliest greatest hit was a piece unfortunately titled Apple: How to bury an important announcement, in which I critiqued Steve Jobs’ July 2001 MacWorld keynote address for talking about new iMacs rather than talking about the upcoming Mac OS X 10.1’s support for the low level protocols (SOAP and XML-RPC) that enable web services.

At the time I said that the unheralded announcement was significant because web services represented a significant evolution of the Internet, as significant as HTML; I said “XML-RPC describes how to allow different computer programs to talk to each other across the Internet.” I said that Microsoft with .NET (and Hailstorm! Remember Hailstorm?) was making a bet that web services were where applications were going, and that Steve was coming on board with that shared vision.

Was I right? From almost seven years later, I’d say it’s a mixed bag. The vision for web services was kind of originally the “cloud computing” vision–you’d have a rich client on your desktop that hooked up to complex software on the Internet using web services. What’s interesting is that while that has certainly happened — look at MarsEdit or other desktop blog editors, or the rich client that I helped ship while at iET Solutions — the real value proposition for web services has been in two areas: integration and mashups. Kind of two sides of the same coin but with very different audiences.

Integration is the business face of getting two computer systems to talk to each other. Think hooking SalesForce into your financial system, or into your ticketing system. Then imagine doing it if you had to consume a SalesForce COM object. Not gonna happen, right? The use of web service APIs to allow hooking systems like SalesForce together with other corporate systems has weakened the case that you used to hear, that your software must be sufficient unto itself because the cost of building and maintaining integrations was so high. It’s also, in an interesting way, increased the adoption of SOA and applications that live off premise. I don’t think you’d see such a high adoption of SalesForce if it couldn’t integrate quickly and easily.

Mashups is the name you use when you’re trying to be cute about doing integration with “consumer” data, or the stuff that you and I use every day. The interesting thing about mashups is that they enable easy connections between web applications–cloud-to-cloud connections, in the earlier analogies. So del.icio.us can automatically post things to my blog; everyone and his brother can get images from Flickr; and your latest Ajaxy website can go from start to finish without requiring you to do a single HTTP refresh.

Of course, mashups vs integrations is an artificial distinction. There’s no technical difference (aside from a bunch of WS* crap in the headers) between the SOAP spoken by WordPress and by SalesForce. It’s just angle brackets. People spend a lot of time positioning mashups as “situational applications” to be done by the unwashed masses, but I think the biggest difference between mashups and “integrations” is intended audience and permanence, nothing more.

With that in mind, we should be at the beginning of what can be done with web services. And that SOAP and XML-RPC layer in the Mac OS should be getting a real workout.