Last night I attended CloudCamp Atlanta, part of the CloudCamp series. CloudCamp is an unconference, which is a less-structured way of holding a conference. In the pure unconference model, there is no pre-set agenda; attendees collaborate to schedule talks at the beginning of the conference. In a very real way, the attendees take ownership of the content; if you don't have a good experience at an unconference, it's your own fault.
That's in theory, of course. Last night's event was fairly good, but because of the limited time available -- four hours, on a workday evening -- some sessions were pre-filled, including an expert unpanel. John Willis did a good job of arranging these sessions, but it seemed to me the sessions were a mixed bag.
In addition to the unpanel, I attended sessions on "what is a cloud?", using Puppet to manage cloud computing and Microsoft Windows Azure. The "what is a cloud?" session, led by Ben Charian, ended up going in an unpredicted direction, due to some specific questions about end-user applications in the cloud. The audience was mostly business-oriented, as opposed to technical, which means the conversation ended up rather high-level, but it was still interesting, overall.
The Puppet session, which I came to late, was led by Luke Kanies of Reductive Labs. It was a more technical session, which was great, but the direct applicability to cloud computing seemed tangential. Still, very interesting stuff, and good information to know.
The final session on Windows Azure, led by Chad Brooks of Microsoft, was also a mixed bag for me. The subject was perfectly suited for the unconference's charter, but I really chose the session as the lesser of several "evils" (not imply any of them were actually evil per se).
All in all, it was a good evening, but I can't help thinking that it might have turned out differently if more of the open spaces had not been filled beforehand. I did have several good conversations with other attendees, which is the main purpose of any conference, and learned of the existence of AWsome, the Amazon Web Services user group.
Wednesday, January 21, 2009
Friday, January 16, 2009
Product Management is Hard.
Every time I think I know what I'm doing, it turns out there's a whole bunch of stuff I forgot. Then the scope starts ballooning, so I have to tamp it back down, then it balloons up again, so I have to keep tamping, but it never stays in quite the same shape it was before.
I have to keep reminding myself, "stick to your core competencies", but what do you do when you're trying to expand into a different market?
I have to keep reminding myself, "stick to your core competencies", but what do you do when you're trying to expand into a different market?
Monday, January 5, 2009
Things I learned inadvertently
Over the holidays I've been doing a little bit of reading, and I inadvertently learned a couple of things that I am going to apply to my work.
The first, which I read in the book Dreaming In Code, which is about the Chandler project, is actually from the 37 Signals book, Getting Real. The exact quote is "build half a product, not a half-ass product." It's a reminder to think small, at least at first, or the thing you build won't do anything well. I can't tell you for how many projects I've been involved with this has been a problem. We always try to build the ultimate tool that will do all things for all people, and as a result it is full of holes and bugs. Instead, we should be striving to focus on the key features that will make our product the killer in its market, and then worry about adding other features only as necessary. This jives really well with other agile principles like YAGNI.
The second thing I learned was from an article in the Harvard Business Review (my father-in-law got a subscription with his soon-to-expire frequent flier miles and hasn't read a word of it) titled "Nudge Your Customers Toward Better Choices." This article provides some detail around how to provide default options (for software configuration, for example, or for add-on packages to another product). The article is not available online unless you pay the big bucks, but I'm sure you can find it in your local newsstand or library (my county library provides online access to most periodicals, and I'm sure yours does too -- that's a service of which too few adults take advantage).
These may be general knowledge in the product management field, but I'm new so they are worth mentioning.
The first, which I read in the book Dreaming In Code, which is about the Chandler project, is actually from the 37 Signals book, Getting Real. The exact quote is "build half a product, not a half-ass product." It's a reminder to think small, at least at first, or the thing you build won't do anything well. I can't tell you for how many projects I've been involved with this has been a problem. We always try to build the ultimate tool that will do all things for all people, and as a result it is full of holes and bugs. Instead, we should be striving to focus on the key features that will make our product the killer in its market, and then worry about adding other features only as necessary. This jives really well with other agile principles like YAGNI.
The second thing I learned was from an article in the Harvard Business Review (my father-in-law got a subscription with his soon-to-expire frequent flier miles and hasn't read a word of it) titled "Nudge Your Customers Toward Better Choices." This article provides some detail around how to provide default options (for software configuration, for example, or for add-on packages to another product). The article is not available online unless you pay the big bucks, but I'm sure you can find it in your local newsstand or library (my county library provides online access to most periodicals, and I'm sure yours does too -- that's a service of which too few adults take advantage).
These may be general knowledge in the product management field, but I'm new so they are worth mentioning.
Subscribe to:
Posts (Atom)