So I'm most of the way through this jaunt down the US East Coast and have yet to post even a single update (unless you count the occasional
tweet). I know, I know... what can I say? I've been busy. My first attempt was overly rambling so I'm going to focus on one aspect here and follow up with a few more posts over the next couple of weeks.
The main reason for the trip was a Product Management seminar led by
Steve Johnson of
Pragmatic Marketing—and I definitely recommend the course to anyone who's interested in this stuff. One thing I found interesting: in North America smalltalk usually means asking, "so what do you do?"; well at a seminar made up of 30 people who all do the same thing, that gets replaced with, "so where do you work?". Fun watching the puzzled looks on people's faces as they stared at the blank line below the name on this independent consultant's name tag. :)
The main focus of the course is on guiding product development through market problems and on grounding those problems in real data instead of hunches and "wouldn't it be cool if...?". I'm interested in Product Management from two angles: first, as a possible career direction and, second, in its applicability to open source projects, such as Seaside.
In past jobs, I've found myself naturally trying to fill an institutional void. I've been the one asking, "Are you sure the students want an on-campus version of Facebook? I kind of suspect they just want to use Facebook...". Actual demand for what we were doing, the exact problems we were trying to solve, and even the development costs have all been more-or-less-hand-wavy things. How do you know what to implement if you don't know what problem you're solving and for whom? Or, to look at it another way, if you develop without that knowledge, how do you know anyone will find the result valuable? It was revealing for me when I first learned there are people who make a living doing these things I found rewarding.
The applicability to open source is an interesting issue. On the one hand, it is almost intuitively obvious that most of the same factors apply. A project that meets a market need will succeed while one that does not will fail. A project that knows who its users are can be more effectively marketed; one that does not will succeed only through chance or an inefficient shotgun approach. What I'm not sure of yet is what is different: is it the formulas, the costs of the resources, or maybe their units of measurement? Or do we need to tweak one or more of the definitions? As a random example, Product Management makes a distinction between users and buyers of a product; what's the correct mapping for these concepts in open source? I'm still pondering all this... more to come.
Before I leave off, I should mention that the
Hilton DoubleTree in Bedford is one of my best hotel experiences in recent memory. Everything was efficient and painless. The room was roomy, modern, and spotlessly clean. The internet was fast and free. And the (three!) extra pillows I tossed on the floor were left there neatly for my entire stay instead of being put back on the bed. They even insisted on comping a meal I had in the restaurant which was, admittedly, slow in arriving but not to the point I was concerned about it. So, I don't know why you'd be in suburban Boston, but if you are, go stay at the DoubleTree.
