The Continuous Deliverist

I recently read an excellent article by Paul Graham that defines a startup (as distinct from any other new business) as the combination of two key attributes:

1. It must make something lots of people want
2. There must be a way to reach those people

Most businesses can do one of those things, but not both together. Software and the distribution medium of the web has opened up all kinds of possibilities for achieving both goals, which is why another key indicator for a startup is rate of growth.

The common unit of success for any startup, then, is the growth of the user base. This presents a problem for a business geared at selling to the enterprise: although the unit of growth is the user, the acquisition of users is done at the level of the corporate account. This creates conflicts all through the product development process. Building sexy and easy-to-use is great for the user, but they’re not the ones buying your software. Building rich business value will help you win accounts, but lack of adoption by the end-user within the business will doom you when it comes time to renew.

Because if this internal tension, I believe anyone doing product development geared at selling to the enterprise must consider one of two growth models:

1. Design to maximize number of accounts sold
2. Design to maximize number of licenses per account

You achieve growth in model one by selling to as many companies as possible. You accept as a ground rule that you will probably not achieve rapid growth by going wall-to-wall within any corporation that buys. As a product designer, you should focus your efforts on deep solutions for specific verticals (Marketing groups, Help Desk, HR). This focus allows you to solve the problems better than one-size-fits-all solutions that could be sold to a larger audience within a single company. You’ll win more accounts than Model Two, but with fewer seats sold per account.

In Model Two you grow by selling as many possible licenses into each account. The trade-off for going with Model Two will be that you must provide a solution that is either one-size-fits-all or extremely customizable. It must work across a huge variety of professional disciplines. Wall-to-wall adoption of a product across an enterprise is rare, and must typically focus on common problem-sets to all workers. Examples here include collaboration, management and productivity-enhancement tools. Selling a tool like this requires a value-proposition that makes sense to Senior Executives, and the adaptability of the product will likely mean that compromises must be made on ease of use for specific verticals. As a designer, you should solve problems in the most generic way possible, with an emphasis on strategic problems in the business rather than tactical ones.

So, what does this have to do with Continuous Delivery? In any start-up you must build a system that allows you iterate on concepts as fast as possible so that you eliminate designs that don’t lead to growth. If you are selling to the enterprise the importance of Continuous Delivery in your system will depend on which of the two models you choose. If you’re shooting for selling the maximum number of accounts, you can iterate on look-and-feel, and on solving the most common problem sets of your targeted verticals. This can happen rapidly because your have more total accounts to work with. If your ambition is to grow by deal size, your iterations will probably be longer because you will have fewer over-all deals to test your strategy against.

I think if you’re building enterprise software, deciding on one of these two paths to growth is key to focusing the Product Development process enough to iterate into a successful solution.