Monday, September 08, 2008

Business of Software 2008 - day one, part one.

This blog entry (and the ones that follow) are a summary of my notes from the Business of Software 2008 conference that I recently attended in Boston.

First off, I have been raving about this conference ever since it ended last week. I've been to lots of great conferences before, but this one has just taken first place. To understand why, I'll be collecting my random notes from many of the presenters. Hopefully something interesting will come out of it.

Seth Godin
The opening speaker for the conference. He seemed to set the tone for the next two days. I've been a fan of Seth's work for a long time now and his presentation did not disappoint.
  • "Ideas that spread, win." This self-evident truth is often forgotten. Instead, business's often spend millions of dollars trying to win with ideas that don't spread. That's a receipe for losing tons of cash.
  • "Your job is to spread ideas." This is a bit more surprising. I thought my idea was to build software. But no, at the heart of it my job is to spread ideas about software process, development strategies, customer needs, etc. As I spread those ideas, the business moves forward.
  • "Build stuff for the new medium." This is the crux of Seth'd preaching. The new medium is what it is. People use it the way they do. You won't change that quickly. Instead, find a product or service that exploits this way of doing things. That will make your idea much more likely to spread. Seth's Squidoo is an attempt to do this.
  • "Commitment before success." Seth's blog, which is now hugely successful, took nearly four years of his personal commitment before it started having any effect. Are you that patient?
  • "Successful businesses connect their customers to each other." Through community blogs, user groups, or whatever, getting your customers to talk to each other is a critical step today.
  • People who have read Seth's material will recognize the following diagram. If you haven't, pay careful attention. This is very different from the regular way products are marketed.

Jason Fried
Jason is the found of 37signals, the developers of Basecamp and Ruby on Rails. I love many of Jason's products, but I really disagreed with much of his presentation. He spoke about his experiences developing products for 37signals. Unfortunately, he made the mistake of assuming that his experience - a single data point - should be extrapolated to the entire software development arena. If he had been more careful to express his views as "his opinion" or "in our experience" I wouldn't have had the strong negitive response that I did.

As it was, hearing someone stand up and say, without qualification, that "Personas are BS" made it difficult to take the rest of his presentation seriously. That's too bad, because he had a lot of good stuff to say.

One of the more interesting comment he made was the advice to "find the right size for your business, and then don't let it get any bigger." This is a clever idea, but it had a lot of people perplexed. What if you product is awesome and thousands of people want to pay you for it? Do you just randomly turn half of them away because that would make your business bigger than you wanted? I suppose you could, but a lot of people found this answer unsatisfactory.

If Jason had a theme it was probably something like "only do what you have to, and decide what you don't want to do." For example, he revealed that 37signals essentially discards all the feature requests and suggestions from their customers, instead deciding to do only whatever they feel like doing on their own. That sounds less like a good bit of advice and more like a business that has been lucky and successful despite how they choose to operate.

I did like his advice to "Curate your product. Say 'no' more often than you say 'yes'". In other words, don't let your product become cluttered with features and widgets it doesn't truly need. As he said, "If something in your design doesn't change a user's behavior, get rid of it." The example he gave is the labels we always see at the top of every table. If it's obvious what each column contains, then get rid of the labels - they don't do anything.

Eric Sink
Eric is the founder of "SourceGear" and author of the book "Business of Software". He gave a great presentation on "What does a Product Manager do?". He used the analogy of parenting to show how all product managers take their products (babies) through six distinct stages.
  1. Prepare
    • This is conception and pregnancy
    • Happens before the first release
    • Dev Team is the mother, Product Manager is the father
    • Most important stage in any product's life
  2. Care
    • Version 1.0
    • Get messaging and launch right
    • 3am Feedings (tech support firedrills)
  3. Listen
    • Between versions 1.0 and 3.0
    • Product exhibits its own will
    • You can still tweak the strategy before it hits mainstream
    • Customers start wanting things
    • Must cross the chasm or die (ie. BeOS, Newton, etc)
  4. Talk
    • Elementary school to adolescence
    • Version 3 - mainstream
    • Most people can use your product
    • Ignore the competition. If you don't have differentiation by now, you never will
    • Customers need information: product comparisons, white papers, demos, etc
  5. Transition
    • Teenager years
    • Post 3.0 releases
    • Rebellion
    • Asking for things they don't need
    • Time to steer the product a bit less
    • Let product be what it wants to be
    • But, don't let it ruin its life
    • Never let a bad release ship at this stage, you won't recover
  6. Letting Go
    • Adulthood
    • Maturity, let it go
    • Let Marcomm and CS support and handle it
    • As Product Manager, your job is done. Move on to the next product
    • Failures at this stage: Windows, Office. They are done, just let them ride.
I really enjoyed Eric's presentation and came away understanding the role of Product Manager a lot better.

My next post will contain the rest of day one, including Dharmesh Shah, Jessica Livingston, Paul Kenny and details on the table sessions and reception.

No comments: