Iterating Towards Bethlehem: Michael Sippey at SVPMA 8/2/2006

January 3rd, 2007 Sean Murphy

Michael Sippey’s original title for his August 2, 2006 talk at SVPMA was “Iterating Towards Bethlehem” was changed to a less cryptic Making the Shift From Being a Packaged Software Person to Being a Hosted Services Person. The original title was a riff on Yeats’ Slouching Towards Bethlehem (not the Joan Didion book or the Angel episode).

The talk was outstanding.

He started with a laundry list of everything that needs to be produced and packaged to ship software:

Disks. Disk labels. Disk sleeves. Manual. Manual addendum. Installation guide. Welcome letter. Invoice receipt. Box. Shipping box. Shipping label.

The software development cycle was

define > design > build > test > release
<---- Elapsed Time 12 - 24 months --->

Michael’s job was market validation

• Is the market real?
• How big is the market?
• Does the product fit the market?
• What are the sales costs?

How we did it.

• Find 30 prospects. Set up meetings.
• Demo your idea / alpha / beta / product.
• Ask questions. (Lots of questions.)
• Take copious notes. Score your results.

Critical questions.

• Do you have this problem?
• Does this solve your problem?
• How much would you pay for this?
• Base hit or home run?
• How would you spend $100 of our money?

By going on-site and talking to prospects, they always learned new things. Sometimes, very new things. In one situation they abandoned the product they were working on to develop a second one based on the jumble of notes and post-its they kept seeing at trader’s desks they switched focus and developed a trade order management system called Moxy.

For his next act he raised a lot of money during the bubble to build a next generation jukebox and learned the difference between end user and economic buyer. It’s not enough to have cool features for the end user, you have to satisfy the bar owner who is going to agree to situate the jukebox in his facility.

He then touched on the TypePad’s “Big Bang” failure over the July 4th weekend of 2005 when they tried to upgrade to version 1.6 of the service:

“Let’s change how users design their blogs. And how they’re rendered. And how users manage their communities. And most of the app’s JavaScript. I mean, hey! If it’s this big already, what’s one more thing? We get more bang out of QA, right?”

What went wrong that weekend scarred everyone involved (“Dude, you just had to be there”).

His talk included an excerpt from Yeat’s Second Coming

Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world,
The blood-dimmed tide is loosed, and everywhere
The ceremony of innocence is drowned;
The best lack all conviction, while the worst
Are full of passionate intensity.

That he put early in the presentation but is probably more accurately a reflection of his state of mind after the 1.6 debacle. The failure to successfully execute a successful release (and more importantly foster user adoption) of 1.6 triggered a series of iterations that evolved “Let’s build a product” into “Let’s iterate a service.” SixApart determined that the right periodicity was a release every two weeks. This means that three key processes must proceed in parallel:

• Define and Design
• Build and Test
• Release.

The keys to making it work include keeping the roadmap and schedule on a wiki, using lightweight specifications and FogBugz, and staying committed to gradual improvements over time.

Sippey proposed the following key takeaways

1. If you can’t get 30 meetings…you don’t have a product.
2. Nothing’s better than seeing a user in context.
   (My GOD, that’s how they use our product?)
3. End users aren’t the only ones that matter.
   (Can’t ignore the other actors in the value chain.)
4. Prove it with a prototype.
   Especially when you’re breaking new ground.

This concept of a making the transition from a software product to a service (or Software as a Service — SaaS) that’s on a two week release cycle will be a theme for this blog: we will explore in more detail why it brings significant business advantages and requires just as significant a set of changes in a startups development process.

Entry Filed under: Events, Quotes, TwoWeekSaaS, skmurphy