While at barcampAustin this year, my pal Zane Rockenbaugh (Dog Food Software) and I recorded a series of interviews with barcampAustin and SXSW attendees and friends. We dubbed it Profiles in Courage, and now they’re yours to enjoy.
Download the episode directly here, subscribe to the RedMonk Radio podcast feed to have it automatically downloaded to iTunes or other podcatcher, or just click play below to listen to it right here:
Building a SaaS
In the fifth episode of Profiles in Courage, barcampAustin edition, Zane and I talk with Scott Diedrick, Director of Development at Mumboe which provides a SaaS for contract and agreement management.
Being the head of development for a Software-as-a-Service business, I start out asking Scott to walk us through how you build a development team and plan to deliver a SaaS. First, we talk about picking a technology stack: whether it’s rails, Flex, Ajax, or whatever front-end. Picking a stack is an important first, of course, because that drives the sorts of developers you hire. As a SaaS, you have to get your data-center lined up; while Mumboe has it’s own somewhere, Scott would recommend Amazon EC2 for new startups.
SaaS Development Teams
Next, we move onto the developer profiles. Scott puts a lot of emphasis on developers with user interaction skills. SaaS’s are often updated and refreshed much more quickly than packaged software, driving the importance of usability. Out of a team of 6 developers, Scott has two people focusing on usability and UI. Since Mumboe has a try-before-you-buy plan, a good interface is key to Mumboe’s marketing and sales process.
Thinking about the tense relationship between developers and UI folks in my past, I ask Scott to tell us how the day-to-day goes between the UI guys and developers: the designer/developer workflow/collaboration, if you will.
SaaS Project Management
Next, I ask Scott to tell us how the development methodology and project planning is driven by SaaS’s ability to deliver early, and deliver often. After launching, they were on a cadence of two week iterations to work out bugs and get feature refinements in quickly. But as they moved into adding “big features,” they’d need more than two weeks. Also, Scott points out, that a monthly update to the software drives a lot of new work for marketing, docs, and sales, all of which have to update their own material and knowledge for the new releases. With more frequent releases, comes more churn.
Is the hassle worth it? It sounds like so: customers see fixes and new features every two weeks, instead of six months or more. Customers, of course, enjoy this rapid feedback loop.
The Austin Condo Scene
Closing out, since Scott lives in a fancy condo over in East Austin, I ask Scott to comment on the condo scene in Austin. Scott divides it into two parts: the low-rise condos (usually a half or a mile away from downtown) and the high-rise condos (in downtown).
Nice recording… I almost cried when I thought Scott was saying they went from 2 week to 1 month iterations to tackle big features, but instead, the Mumboe team holds true to the "stay releasable" concept and continues with the 2 week iterations.
One interesting point on the use of interpreted languages in this context is that they provide a lot of the same benefit that SaaS products provide in terms of giving customers patches sooner. With Ruby and Python COTS, support people can often apply a fix on the customer's box (or the hosted server in the case of SaaS) with very little risk. Granted, I'm mixing languages and delivery mechanisms, but the point is that COTS products based on compiled languages often lose the patching battle because it's so hard to deliver a low-risk fix.
…end of rambling. 🙂