Recession Requires A Focus on Revenue

Written by Sean Murphy. Posted in Events, skmurphy, TwoWeekSaaS

It’s starting to become clear that beyond just storm clouds, we are in for a recession in Silicon Valley. Which I suppose means that the next bubble will be delayed a few more years.

We started our business in mid-2003, helping several small consulting and software firms who were struggling to recover from Silicon Valley’s nuclear winter of 2000-2 when local employment dropped 25% from the height of the dotcom era. So we are not worried that bootstrapping firms will suddenly stop needing customer development. And, although fewer folks may decide to quit their jobs to raise VC funds, some may still choose to launch a consulting career or a software startup and discover the need for bootstrapping.

Clearly expense control at VC backed companies is going to be increasingly the focus at board meetings. But bootstrapping firms are born with expense control, for the most part they can’t exist on “build it and they will come” business plans.

Most new software firms are looking at Software as a Service models for deployment. And SaaS has implications on the sales model and the salesperson’s job. If you are wrestling with these issues, you should consider attending a roundtable we have scheduled for tomorrow that will look at sales issues for SaaS firms. In particular how does SaaS change sales management, sales compensation, and selling strategies.

It’s over a lunch from 11:30 to 1pm at Plug and Play, 440 N Wolfe Rd Sunnyvale, California 94084.

You can Register here.

SaaS Blurs Traditional Software Startup Roles

Written by Theresa Shafer. Posted in Events, TwoWeekSaaS

SaaS business models are proven and and gaining wide adoption. However they come with new issues: shorter release cycles, blurring of development team roles, and the need for new internal reporting and management controls now that you are responsible for the customers application infrastructure. Your development, support, sales, and product marketing folks must change how they monitor customer usage and satisfaction and reach a working consensus on customer feature requests and bug fixes based on different metrics now that you control not only your own application but your customer’s infrastructure.

Gone are the days of annual release cycle. For many companies, very fast releases are the new standard. Picking the best software release cycle impacts your customers, team, and management. These changes impact the team traditional roles and responsibility. No longer can development throw it over the fence to QA or documentation. No longer does marketing write lengthy MRDs. The team changes to balance the quality, usability, and time to market objectives.

As Sean covered in Iterating Towards Bethlehem: Michael Sippey at SVPMA 8/2/2006

“Let’s build a product” evolved 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. [...]
This concept of 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 startup’s development process.

After attending some sessions at CINACon earlier this month, I blogged about the “Benefits of a Saas Business Model.” If you are interested in taking part in a round table discussion on these issues, please join us Tuesday, Oct 30 for a SaaS Roundtable: Managing Rapid Release Cycles.

Benefits of SaaS Business Model

Written by Theresa Shafer. Posted in TwoWeekSaaS

I had a chance to hear two VCs outline the benefits of SaaS as a business model at the CINACon 2007 conference a on September 22. While Francis and Sean manned the booth I attended the Visionary Session.

First up was Ann Winblad, Co-founding Partner, Hummer Winblad Venture Partners.

  • Capital Efficient, allows for self-sustaining and reaching profitable as quickly as possible.
  • Predictable Revenue Stream

Tim Wilson, General Partner, Partech International

  • Users of software cannot steal the software.

At SKMurphy we’ve seen some other benefits from the SaaS model for startups

  • Higher Valuation
    With recurring revenues, steady monthly and predictable growth, a SaaS firm is able to demand higher valuations than a conventional on premises software startup. If you approach VCs with a scaling plan rather than a development funding plan, you can get a higher valuation.
  • Shorter Sales Cycles
    Here is data we find from our clients for B2B Sale Cycles

    • Pay-per-Use: 4-10 weeks
    • Subscription: 10-22 weeks
    • Time Based License: 28 weeks
    • Perpetual License: 40 weeks (assuming 3 year lifetime value of customer > $150K; caution: B2C may be very different).
  • Other Benefits for Your Customer
    • Lower Cost of Ownership (at least initially may end up higher as adoption/use proliferates)
    • Software Provider handles managing upgrades, bug releases and initial deployment setup.
    • Easy test drive, see that it works.
    • May be easy to switch to competitors, although data lock-in effects are subtle but real.

SaaS business models are taking off: we use ones like Salesforce, WebEx, TypePad and Central Desktop everyday. The business models are proven and and gaining wide adoption. However they come with new issues. Issues like shorter release cycles, blurring of development team roles, and the management of customer feature requests and bugs when you control the infrastructure impact your customers, team and management controls.

SKMurphy is hosting a SaaS Roundtable: Managing Rapid Release Cycles on Oct. 30, 2007.

Brainshark at Software Business 2007: SaaS = Service

Written by Theresa Shafer. Posted in Events, TwoWeekSaaS

I went to a good talk today at Software Business 2007 by Joe Gustafson from Brainshark on “Establishing and Growing a Successful SaaS Business.” Joe characterized Brainshark is “Tivo for Business Content” available when users want to consume it.

He opened with the best part of a SaaS business: recurring predictable revenue makes it easier to manage. Also low cost of development is a big advantage, they have 5 versions of machines that need to be supported.

The thing he likes the least is it takes time to scale: the revenue from an annual SaaS contract is 1/3 to 1/4 of an equivalent on-premises perpetual software license. The hardest part of selling is becoming very efficient at managing a number of distinct transactions efficiently. Since the up front fees are low, developing customers cost effectively is critical.

In 2000, there was one sales team with a blended responsibility of selling, renew, and expanding accounts. Now they have four teams each with their own incentive programs and distinct quotas:

  • New Accounts
  • Renew Accounts
  • Expand Account
  • Small Business Account

All of Brainshark’s sales are direct. After the early sales, sales became a “build a machine” problem rather than “art of the deal” sales strategy. The other major message he hammered home: SaaS = Service. It’s a relationship based on trust. And that trust is not only a challenge to develop, it requires both a engineering development methodology committed to high reliability–Brainshark aims for “3 9′s” or 99.9% uptime: this is 0.1% downtime which is about 45 minutes per month and an ongoing–and a sales and support culture committed to service and customer success–the SaaS model does not reward companies selling shelfware (software that’s purchased by IT but not adopted by the business).

Renewals are the life blood of the SaaS model: and it always about service and building trust and maintaining. He strives for Ritz or Four Season customer service in his relationship with customers. For the full presentation see http://presentation.brainshark.com/campaigns/swbiz2007.asp (registration required but has narration in addition to slides: although it sounds like Gustafson didn’t do the narration in front of an audience, he speaks very clearly but has much less energy and modulation in his voice compared to his talk).

Startups Are Hard Work and Require Planning

Written by Sean Murphy. Posted in Quotes, skmurphy, TwoWeekSaaS

Guy Kawasaki had a great guest post “On The Other Hand: The Flip Side of Entrepreneurship” by Glenn Kelman, the CEO of Redfin, last week that was a well written counterpoint to some of the “make money fast in your spare time in your underwear” blather that Guy has been generating with “No Plan, No Capital, No Model…No Problem. ” Google Video of event here. Some of Kelman’s observations that really resonated with me:

Lately I’ve been thinking how hard, not how easy, it is to build a new company. Hard has gone out of fashion. Like college students bragging about how they barely studied, start-ups today take care to project a sense of ease. Wherever I’ve worked, we’ve secretly felt just the opposite. We’re assailed by doubts, mortified by our own shortcomings, surrounded by freaks, testy over silly details.

[...]

Like the souls in Dostoevsky who are admitted to heaven because they never thought themselves worthy of it, successful entrepreneurs can’t be convinced that any other startup has their troubles, because they constantly compare the triumphant launch parties and revisionist histories of successful companies to their own daily struggles.

“Revisionist histories of successful companies” is something that’s not widely appreciated. Eric Hoffer cautioned against this tendency in his observation “Our achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.”

Most start-ups find an interesting problem to solve, then just keep working on it. At a recent awards ceremony, Microsoft CEO Steve Ballmer tried to think of the secret to Microsoft’s success and could only come up with “hard, hard, hard, hard, hard, work.” This is an obvious cliche, but most entrepreneurs remain fixated on the Eureka! moment. If you don’t believe you have any reliable competitive advantage, you’re the kind of insecure person who will work your competition into the ground, so keep working.

If you aren’t doing something worthwhile, you can’t get anyone worthwhile to work on it…You need a big mission to recruit people who care about what you’re doing.

If you can begin to enjoy the process of building a start-up rather than the outcome, you’ll be a better leader.

Applying the “Agile Manifesto” to Software Startups

Written by Sean Murphy. Posted in Rules of Thumb, TwoWeekSaaS

What follows are some quick thoughts on how to apply insights from the “Agile Manifesto” (see also Martin Fowler’s excellent essay on “The New Methodology” for a nice overview of what agile development entails) to early stage software startups.

Value This More In Preference To
Individuals And Interactions Processes And Tools
Working Software Comprehensive Documentation
Customer Collaboration Contract Negotiation
Responding to Change Following a Plan

Principles behind the Agile Manifesto

Agile Principle from Manifesto My Comments for Startups
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “early and continuous” are the two key adjectives here. Startup needs to move fast and be able to continue to adapt, refine, and improve subsequent releases.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Ultimately your value is to contribute to your customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. I think for Saas this is going to work out to be one to two weeks between releases. 
Business people and developers must work together daily throughout the project. Co-Evolution of Business and Technical Plans
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Essential in a startup.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Certainly where there is  a need to get emotional calibration you need at least voice (telephone, VoIP) but face to face is the highest bandwidth.
Working software is the primary measure of progress. If only because it’s the easiest thing for customer’s to judge. But a sales pitch that accurately represents what will be delivered is as necessary, and should in fact precede working code in the early days of a startup. Sell, then Build.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This is a “no finish line” model that assumes you will need to continue to tune and evolve your offering rapidly after it’s introduction.
Continuous attention to technical excellence and good design enhances agility. Especially if you can measure what you mean by excellence and keep score transparently for the whole team.
Simplicity–the art of maximizing the amount of work not done–is essential. Simplicity forces you to focus on customer’s key needs and minimizes the work needed for the next release. Giving the customer software to work with speeds their understanding of their true needs faster than almost anything else (if you start by observing their actual behavior in their environment).
The best architectures, requirements, and designs emerge from self-organizing teams. This to me seems a little to IT or development centric. Many times visionary customers will supply critical insights on architecture and requirements.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Wynton Marsalis advises that “the humble improve.” You need to balance regular celebrations with an appropriate amount of both internally driven and customer solicited evaluation of quality and productivity (yes your customers are making an assessment of how productive the team is and how quickly you can understand, master, and deliver on emerging needs).

More to come on this, in particular what one to two week release cycles mean for how you organize and execute as a software startup.

SaaS Requires Excellent Support Not Upselling to Proliferate

Written by Sean Murphy. Posted in Startups, TwoWeekSaaS

Rich Mironov profiles Replicate Technology (a current client) in Service Revenue and Upsell Marketing” and mischaracterizes–in our opinion–their strategy as upsell marketing. Replicate’s services are sold as a test lab: when a new customer is just starting out and only needs to test one or two configurations they get by very cost effectively. As the customer’s needs become more complex, or their development staff grows, in the same way that they would need to add to a physical test lab, they can instead add more virtual lab capacity. Besides scaling up with them as they grow, Replicate offers several key benefits that Rich Mironov identifies:

“By offering this as a service, Replicate saves 90%+ for customers versus licensing and running virtualization software in-house, with:

  1. An instantly working solution
  2. No need for customer to hire or train skilled virtualization engineers
  3. No need for customer to buy, maintain or manage dozens of servers
  4. No upfront capital expense
  5. Ability to add capacity (servers, configurations, storage) when needed
  6. Easily sharable test resources for geographically distributed teams
  7. Ability to “snapshot” systems with software defects and “replay” the defects for software developers”

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

Written by Sean Murphy. Posted in Events, Quotes, skmurphy, TwoWeekSaaS

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 Bangfailure 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.

Quick Links

Bootstrappers Breakfast Link Startup Stages Clients In the News Upcoming Events Office Hours Button