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.

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 (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).

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.

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

Quick Links

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