Assembla Blog: Category Software Business

US visas run out. What's the solution?

andy@assembla.com — Sun, 08 Apr 2007 09:52:00 +0000

We ran out of H-1B visas on the first day. US Immigration services received 150,000 applications for 65,000 H-1B visas, which are the visas most commonly used by programmers seeking to work inthe United States – as summarized by this Cnet story. Last year, it took two months to reach the same limit. What does this mean?

America still is the land of opportunity. Our technology business has recovered, and we are ready to work. We need to bring in talented people to build and create our entrepreneurial businesses.
Our government has converted this opportunity into a problem – a problem for employers, and a problem for offshore talent.
It has become even more important to figure out how to effectively manage distributed teams, so that we can work our way around bureaucratic obstacles.

There is another, important implication that I think has been overlooked by almost every commentator on the immigration issue. Employers are increasingly eager to bring skilled workers to the US, instead of leaving them in “low cost” countries, because the cost differential has narrowed. It doesn’t cost much extra to move someone to the US. If US salaries were much higher, there would be a bigger incentive to leave workers at home.

In the last year, salaries in places like India and Russia have risen rapidly, the dollar has declined, and US salaries have risen only moderately. So, the demand for H-1B visas indicates two favorable trends for US skilled workers. First, there is a big demand for local skilled labor here in the land of free enterprise. Second, the price war that fueled outsourcing has mostly run its course, and the next field of competition is about quality and the freedom to do a good job.

Although the advocates of raising the H-1B cap deny that H-1B visa holders push down wages for skilled Americans, I think it is probably true that wages get pushed down somewhat. A pure economic analysis would show that wages are held down, while the number of jobs is increased. I am willing to admit that I am not sure that this is a bad thing. I like the idea that jobs go to the best candidate. And, I work for a number of startups that are strugging to attract local technical talent so they can move forward.

So, we are working to fill this demand by building our local recruiting skills, and by constantly improving our ability to manage globally distributed teams.

How to select good trial tasks

andy@assembla.com — Sat, 27 Jan 2007 11:53:00 +0000

We use trial projects to help find the best developers to work with. We hire candidates to do paid trial tasks from our live projects. In working with the candidates, we understand how good they are and how well the they work in our process. We try to sign the good ones for longer term contracts. Itâ€™s a lot of work, but it is well worth the effort.

Sometimes, clients want to do this themselves. Or, they want us to perform in a trial, which is a hassle for us, but a good idea for them. That brings us to the subject of how to select trial tasks. To make the process work, we need good trial tasks.

I find that a managerâ€™s first instinct is to create a â€œtestâ€? task. Itâ€™s a small task that can be assigned to lots of candidates. That way, they save time by doing one specification, and they get the advantage of being able to compare results from multiple candidates. Or, they select a task that they have already specified and completed. That way, they save even more time because they donâ€™t have to do a new specification, and they can compare the candidate result with the previous result.

I donâ€™t use either of these approaches (a test task, or an already completed task), because they make the task meaningless. This causes two problems.

Good developers (including us) are busy, and work very hard, and donâ€™t have time to do meaningless work.
These trials fail. As a busy manager, you will never bring yourself to pay enough attention to a meaningless task to get a good result.

So, I only assign trial tasks and features that I intend to deploy, or that are R&D / prototyping for something that I intend to deploy. I only assign meaningful tasks. I think to do otherwise shows disrespect to the hard-working candidates I hope to work with.

For trials, I take a real system that I am working on, and ask for a meaningful improvement. Essentially, I assign tickets out of our live projects.

I hear three objections to this approach

â€œI need the deliverable. I canâ€™t risk it with a new guy.â€? If that is true, then hire two guys to do it.

â€œItâ€™s too much work to specifyâ€?. Thatâ€™s true if you are working with mediocre developers. However, if you are working with people who require precise specifications, and they just do coding, they arenâ€™t saving you much time. They would save you a LOT more time if they could take the general idea and a do something with it. So, it makes sense to test for that.

â€œMy systems are too complex for a quick trial.â€? Thatâ€™s true if you are working with mediocre developers. If you are working with good developers, you should be able to throw them into a complex system and get some forward motion pretty quickly. From a qualification point of view, complexity can help you. If the build process is such that you canâ€™t get new people set up easily, then you will benefit from improving the build process. That in itself can be a trial task.

Lessons for Hyper-Agile product development

andy@assembla.com — Sun, 07 Jan 2007 21:15:00 +0000

Recently we were called upon to build and launch a new Web product with a hard deadline in a seasonal business. By the time we started our work, only three months remained until the planned launch date. It was a big system. Our mission was to build a new and greatly enhanced version of a product which had taken 15 months to build in its last iteration. So, we had a benchmark.

In this case, we ran more than four times faster than a similar project implemented last year with older tools and development methods. We also came in on-time and under budget, and we ended up implementing features faster than we could figure out how to use them.

How did this happen? Want to try this at home? I will share our lessons below. Good luck.

Donâ€™t do things that take time to arrange
Donâ€™t get dragged down by old code
Establish the data schema
Pile on with new team members
Use a ticket list / work queue
Build something now, even though we know we will have to rebuild
Donâ€™t split the codebase into components
Daily releases instead of stabilization periods
Make a usage dashboard
Web services are your friend
Hire users as product managers
Donâ€™t create obstacles: Users provide the data
Documentation on a wiki
Find the one thing people will use

Here is the expanded version, for people who actually do this for a living.

Donâ€™t do things that take time to arrange

We get big time savings by not moving people around. Travel takes time to arrange, and it takes time to do. People should be working, not moving, and they should start now. I donâ€™t do interviews. I found that even arranging a phone interview takes five to seven days â€“ a big chunk of a 70 day project. Instead, I let people start work and I evaluate their work later. I also donâ€™t set up conference calls for the product team. In my observation, time spent on the phone is a good indicator of communication problems, and is best avoided by improved management and communication.

Donâ€™t get dragged down by old code.

I believe in doing a lot of research and trying to adapt existing open source code, as an alternative to diving into new development. We spent a week of our precious schedule taking a in-depth look at open source alternatives. We considered a system with a friendly academic license and $4M worth of development behind it. What we found was big, complicated enterprise software with lots of heavy baggage. We talked to people who were adding to Sakai, and found that they were typically taking 8 months to do things that I thought should take a month. We discarded the existing product for the same reason. We moved on to a more agile architecture and never looked back. I had to change my thinking because, in the new world, it often is faster to build from scratch.

Rails is simpler than java for this type of application, and the build was much faster as a result.

Establish the data schema

It is easy to add to a data schema, but difficult to change it. I sometimes visit old clients and find that the people, products, and code that I knew are long forgotten, but the data schema remains. Data schema is the one piece of up-front design that we do before diving into the build.

Pile on with new team members

It is possible to bring in a lot of new team members and let people pick their own tasks. Using this technique, we were able to triple our output in three weeks. This approach is the exact opposite of the “Mythical Man Month” recommendation, which holds that adding new team members imposes a cost of learning time and management time which will delay a project that is on a short time schedule. In my experience, adding team members DOES delay a project, if you need to guide them and manage them. The pile-on method works if the new developers are good and can find their own way. We are helped by our â€œinspired by open sourceâ€? methods, which were developed to serve large teams with loose central management, and the fact that some of the new developers are very good. We can weed out the rest a few weeks later.

An obvious related lesson is to work with good people. I am not even going to put it in the list of lessons from this project because it is far from a new lesson. A good developer seems to be about 5 times as productive as an average developer. In this project, there were several cases where a team member spent 2 weeks working on something, did not finish it, and then found it replaced by something our best guy finished in 2 days. Given the potential gains, most project managers donâ€™t invest enough in recruiting and retention.

Use a ticket list / work queue

We put all of our tasks, bugs, and new requests into a list of “tickets”, often called a work queue. We use Trac. In fact, we use Assembla.com. We sort the tickets by priority and milestone, so the tasks from the next milestone are on top of the list (queue). Itâ€™s easy to figure out what to do. Just look at the list of tickets and pick something near the top. You can try to adopt a more rigorous agile methodology, but you will find that it is hard to improve on this simple and effective technique.

Build something now, even though we know we will have to rebuild

We started building copies of the old product, and copies of features that we saw in other products, before we even had a coherent visual design or plan for the new product. Then we ripped out a lot of the guts and rebuilt it. This was still faster than waiting around for a coherent design and product plan. Why? In this new environment, development is faster than product management. From a product management point of view, it is faster to ask for changes than to figure out what the product should do from scratch. It takes forever to build something that is unknown, but if you know what you want, builds are fast. So, the two steps (copy and redesign/refactor), with clear instructions for each, are faster than one build from a blank sheet.

Donâ€™t split the codebase into components

In this application we needed several types of servers that were different â€“a permissioned application, a public portal, and a central user registration server. We lumped them together in one repository and one application with configurable â€œrolesâ€? that turn features on or off. This made the code a bit more complicated. However, it made other aspects of managing the app â€“ setting up developers, testing, staging, deployment â€“ a lot simpler.

Daily releases instead of stabilization periods

In a normal Web 2.0 style release, you just run beta releases of increasing quality, until you are ready to do a bigger announcement. In this case, I didnâ€™t think we had time for such gradual stabilization. I initially recommended that we do a code freeze with a week of testing and stabilization. The resulting product might not be perfect, but at least it wouldnâ€™t crash. We started with a daily release process and no code freeze, and it worked well enough that we didnâ€™t need to a code freeze and stabilization period. Itâ€™s not bug free, but we fix the bugs as fast as people notice them. I now have abundant evidence, from several projects, one of them a big enterprise ASP, that users will tolerate a product which comes directly from developers, every day, with minimal testing, if the time to release a bug fix is less than 24 hours.

Make a usage dashboard

Program a custom dashboard that shows registration and usage statistics. Everyone on the team will use it every day as soon as the beta period starts.

Web services are your friend

Arranging integration with external systems can absorb a lot of calendar time. We were able to use SOAP services (easily offered or called in Rails) to make it go faster than I expected.

Hire users as product managers

Product management â€“ figuring out what the product should do â€“ became the bottleneck early on and remains the bottleneck. Using the above techniques, the developers pull requests off the ticket stack and implement them as fast as we can make the requests. Our strategy to deal with this is to hire users as part-time product managers, and let them each work with a mockup team to redesign the visual parts of the app. With the distributed team system, itâ€™s easy to integrate part-timers like this.

Donâ€™t create obstacles: Users provide the data

We took out the centrally controlled categories and allowing users to just type their own tags for the content that they entered and shared. I think we would still be waiting if we had to build our own categories. We got a surprise when we released with a comprehensive list of US data, and we had immediate requests from dozens of countries. I now think that users should be able to post additions to any part of the database if they need to. Why block them? Sometimes the additions can be released directly, and sometimes they may need to be approved by an editor.

Documentation on a wiki

If your application changes every day, you need to put the documentation on a wiki. If you set up the documentation wiki early in the development process, you can start linking to it from inside the app, just like embedded help pages.

Find the one thing people will use

If you can find the one feature that people will use and adopt, it makes the whole system simpler. So, release early and often and watch your dashboard. Find that thing.

Marketing In A Web 2.0 World: Why The Best Products Sometimes Win

andy@assembla.com — Wed, 13 Dec 2006 22:03:00 +0000

Read the full article at OnStartups

Here is a summary:

For 100 years, it has been a truism that “the best product doesn’t win. The product with the best marketing wins.” At the risk of being thrown out of capitalist society, I claim that on the Web, this is no longer true. The best product often does win, with virtually no marketing, if it is easy to adopt.

In this new product cycle, figuring out how to get users to adopt is the hard and expensive thing. Marketing serves the adoption work by bringing in the right number of prospects for us to experiment with.

What a turnaround! Software is now a terrific business

andy@assembla.com — Sat, 15 Apr 2006 13:22:00 +0000

Less than a year ago I wrote an article titled â€œIs the Enterprise Software Licensing Business Dyingâ€?. It was originally posted on IT Managers Journal, but it got picked up by Slashdot and various bloggers and podcasters. It pointed out that enterprise buyers had stopped buying software licenses â€“ the mainstay of the software industry. This caused years of misery for software professionals, years during which software was a bad business to be in. But the light at the end of the tunnel was apparent even then, in the form of new packaging and revenue models. Faster than I imagined, the prospects for the software industry have been transformed. We now have a wonderful alignment of good fundamentals â€“ increasing demand, declining costs, and rapid innovation.

Any industry with increasing demand, declining costs, and rapid innovation has got to be a great place to invest time and money.

INCREASING DEMAND

I recently did some research into market size for Assemblaâ€™s business plan, and what I was interested in was â€œon-demand softwareâ€? or â€œsoftware as a serviceâ€? – traditional enterprise applications packaged as subscription online service. Almost every company that I looked at was growing at more that 50% per year. This accounted for more than $3B in revenue. So while the overall enterprise software market may be flat, there are big categories inside it where business is better than ever â€“ better than in the 90â€™s boom. Revenue is actually growing faster, from a bigger base. Thatâ€™s the macro view. The micro view is that globalization has doubled the pool of available programmers in five years, and weâ€™re already running out of them.

DECLINING COSTS

At a presentation about social software at Harvard Business School, one of the questions the presenter asked was â€œwhy now?â€? Why are we seeing big, free social wikis, networking sites, blogging sites, classified markets, spaces? Why now and not 5 years ago? His answer was: because the basic costs are a lot lower now. The servers, server software, and network bandwidth are cheap enough to give away. Thatâ€™s why people can support bigger communities. Thatâ€™s why businesses give away free online services instead of hiring salespeople. Itâ€™s cheaper.

The cost of making the applications to run on this platform has declined even more. I estimate that my cost of building and launching an application is about 25% of what it was six years ago. Labor is much less expensive because we now shop globally. The productivity of that labor rises continuously as we adopt better tools and processes. We have more open source components to draw on, which has a big impact because studies show that code re-use is the single biggest contributor to increasing developer productivity.

Inside established software companies, lower costs mean higher margins. The margins rise faster if companies take a pro-active approach to moving customers to lower cost software as a service platforms â€“ or as a friend of mine dubs it, â€œlift, shift, and maximizeâ€?. Software investors have some challenges and some opportunities. One opportunity is to look at software as a cash producing business, doing LBOâ€™s, giving up on growth, and paying down debt and dividends with the cash not spent on new sales, marketing, and launch activities. A new generation of entrepreneurs is figuring that out. A challenge for software VCâ€™s is to figure out how to participate in a market with shrinking deal sizes. In theory, that means they can do more deals, and give another bump to innovation.

RAPID INNOVATION

Weâ€™re in the middle of a rapid burst of innovation that I call Wetware. Wetware is open source, globalization, Web 2.0, and user-generated-content. Itâ€™s the smart node in the stupid network. Itâ€™s people working together. Inevitably, they will accomplish great things.

Wetware is a relatively obscure burst of innovation because it is new. We used to follow Hardware. When computers first became big business, we measured innovation by the rate of new hardware introduction. Software was an obscure component. Then came software. We created Mooreâ€™s law for hardware, and software became a more interesting business. We followed platform launches and browser wars and client server and software as a service. Weâ€™re still in that phase. Here comes Wetware. We canâ€™t measure units of human innovation, and we donâ€™t measure the speed of organizational reconfiguration. But we should, and we will. Itâ€™s coming fast.

Max Planck said â€œscience advances one funeral at a time,â€? and so it is with this innovation. Todayâ€™s teenagers live their life in global networks, and spend a lot less time hanging out in parking lots than my contemporaries did. Theyâ€™re going to take over the workforce, one retirement at a time.

Project.net - new open strategy and releases

andy — Fri, 17 Feb 2006 12:17:00 +0000

We have finally announced the new strategy and releases for Project.net, at OSBC on February 14. Over the next few months we will release open source, hosted on-demand, and enterprise packages based on this product. We picked up some nice articles in the press.

Internet News
News.com

This relaunch of Project.net has been a long time in the making, since I first discussed it with Roger Bly, the president of Project.net, last May.

At the time, Roger was wondering how Project.net could go to the next level. The company had a nice product and a few good enterprise customers. However, it was too small to thrive in the increasingly brutal enterprise selling cycle, as described in my article Is the Enterprise Software Licensing Business Dying?

I discussed with Roger some opportunities that Project.net could take advantage of:

Many of their best customers were doing some kind of customization. However, Project.net did not have any kind of shared source or open source licensing or process in place to serve those customers. They didn’t have any strategy in place to take advantage of open source marketing, community resources, and customer innovation.
They were making most of their money on the bigger deals, over $100K, and really didn’t have any way to benefit from serving smaller groups.
They built a nice Web-based, multi-tenant application, but they did not offer any kind of ASP or on-demand service.

Over the next six months we worked together to design a new strategy and get the company sold to ICS, which was willing to put in resources to back the new strategy. That deal closed in December.

Then we set to work rebuilding the development team and process as an open-source compatible global team and process. It was an amazing experience, during which we looked at 130 candidates, selected 11 for competitive trials, and were amazed when 9 of the candidates turned out to be great. Now, we have guys from 7 countries working together every day.

The results from the sales and marketing process have also been great. Leads, renewals, and sales are running ahead of expectations. There has been a surge of interest in Project Portfolio Management solutions, and all of the players are benefiting. Project.net has a bright future in this space.

The rise of dynamic languages / programmer productivity

andy — Mon, 13 Feb 2006 14:16:00 +0000

I have moved my own development mostly to dynamic languages Ruby and Python, and I can see that these languages have had a big jump in popularity over the past year. This is not a fad. It is a very real and permanent response to increasing developer productivity.

Most people learned to program with Basic an older dynamic language. Dynamic object-oriented languages like Lisp/Scheme and Smalltalk have been around for decades and have always had a cult following. The highest productivity hackers have always appreciated the things that make them dynamic: that changes to code are interpreted immediately, and that objects can be modified at runtime and in real time.

The key observation is that these are the highest productivity hackers. They are the guys that program so quickly that they need immediate feedback on builds, rather than daily or weekly. They also dont feel the need to do a lot of planning around their code, since they figure they can fix anything that goes wrong on a similarly short cycle.

Other people did not feel the limitations of their build cycle so acutely, and they tended to avoid dynamic languages because of their limitations in speed, stability, and resource usage during actual deployments.

I hypothesize that the demand for dynamic languages is driven by developer productivity. When the amount of work that you can do in 30 minutes goes over a certain threshold, the build cycle itself becomes a limitation, and you want a dynamic language.

What if the merely good programmers started moving as fast as the exceptionally fast programmers? There are a lot more merely good programmers than exceptionally fast programmers. What if the WHOLE CURVE shifted? Then the demand for dynamic languages would skyrocket as the majority of programmers found they needed them. That is exactly what is happening. Programmer productivity is increasing.

For 40 years, programming was assumed to be a labor-intensive activity with very low productivity growth. Computers got faster and faster, but developers still required the same amount of time to produce a function point. The problem was exacerbated by the fact that projects got bigger, and bigger projects have inherently lower productivity per individual. And, there were a lot of inexperienced developers coming into the labor pool, which slowed things down. So several factors conspired against productivity increases.

However, I believe that something changed in the mid or late 90s, and developer productivity started increasing much more rapidly. Adding to the momentum, the bust of 2001 forced everyone to get better. I intuitively estimate that developers are at least twice as productive now than they were six years ago.

Why did this happen? Im not sure, but improved tools, computers, processes, accumulated knowledge, and the availability of free software, may have finally had their intended effect.

The increase in productivity is now being amplified by other factors. When software gets standardized and broken up into Web services, project sizes can get smaller, which adds another boost to productivity. Offshore developers who can rapidly and at low cost jump into a project push up productivity per dollar even more. Open source software means more code re-use, which really pushes up productivity. Finally, the availability of audiences that are willing to absorb beta quality software has compressed release cycles.

The evidence can be found in the structure of the industry, where development team sizes are shrinking, implying an increase in productivity per developer. Ruby is an interesting case. The language is essentially developed by one person. Rails is developed by a very small group. These guys can have asmuch impact as much bigger java teams did in the 90s.

So, there is a whole cluster of phenomena that come from the same root cause of increasing developer productivity: smaller teams, shorter release cycles, and the use of dynamic languages. Its a permanent shift. It affects all of the tools we use, the ways we organize ourselves, and the structure of the software industry.

The Unbreakable Software Business - your best friend or worst nightmare

andy — Mon, 21 Nov 2005 16:53:00 +0000

How can we design a business that will be it’s competitor’s worst nightmare, if not unbeatable, at least unbreakable. Put another way, how can you design a business that would be your worst nightmare if it became a competitor?

This business would be pareto-optimal, in the sense that you could not beat it on critical measures such as innovation, market awareness, cost of sales, service response cycles, and fixed costs.

Such a business will use global talent, instant service, open source, and user innovation. It will use these tools in all aspects of its business, to make the product, support the product, and sell the product.

The unbreakable competitor probably will have some of the following attributes:

Very low fixed costs
Modern startups use contract labor, rented servers, and the bare minimum of office leases. That makes them hard to break, and easy to scale. If 80% of your costs are incurred month-to-month, you are probably at a Pareto-optimal point.

Global talent base
If you can get, and keep, the best available contributor from anywhere in the globe on two weeks notice, you are probably at a pareto-optimal point.

Rapid Innovation
The optimal competitor will innovate rapidly, tirelessly, and ruthlessly. Ray Kroc is alleged to have said “if your competitor is drowning, stick a hose in his mouth”, and that’s visual picture of what a relentless innovator does. Under the right circumstances, innovation comes naturally because any given customer base applies pressure for innovation, the world changes, and people respond. Unfortunately, there are also many, many self-made barriers to innovation. On examination, it is usually possible to find and remove many unnecessary barriers to innovation – in architecture, delivery, budgeting, licensing, and other areas. Can any one of your employees get an idea implemented and tested? Can any one of your customers get exactly what they want? Do you immediately make innovations available to other customers? It’s possible if you share the responsibility. Open and democratic in this case means letting innovators go around your planning process if they need to. An optimal competitor combines strong and democratic internal innovation with an open product that customers can mold to their own needs.

Improving Product Quality
It’s possible to beat the “unbreakable” software business on product features and quality, by spending a lot more money, by having a lot more product maturity, or by having some patent advantage. However, if the business is unbreakable, it will eventually fight back with potent weapons: releasing early and often, and an open development process. That will ensure that the product rapidly improves along the dimensions of quality that are important to the users.

High Volume Marketing and Lead Generation
The market leader has the optimal marketing and lead generation position, because a prospect will always give some consideration to the market leader. I would count as the leader the product with the most new adoptions, rather than the biggest installed base. The product has to be really easy to adopt. If it is by nature not easy to adopt, because it involves system change, maybe it needs to be packaged as a component of some outsourced service that is easy to adopt. The optimal competitor is the best in your category on cost of adoption.

When people adopt, they talk. The unbreakable competitor will engage customers immediately in a community of sharing, peer advice, and innovation.

Low Cost of Sales
You want people to call you when they are ready to buy, or as late in the sales cycle as possible. This reduces the cost of sales. The unbreakable competitor only engages the sales team after a customer approaches with the intention of actually buying something.

How to make this happen is the trick. One popular method is to provide free software and services. Declining technology costs mean that in many cases it is cheaper to support a bunch of users who are not ready to buy a product, than it is to sell a product to prospects who are not ready to buy.

There are other method that rely on having the right product presented at the right time. The unbreakable competitor will find the demand.

Immediate Customer Service
Customers should get immediate service, or at least service that is more immediate than any competitor can provide. This can be accomplished by having the right escalation structure, going straight to senior management for requests that aren’t satisfied on a short timeline. In a software business, having a shorter release cycle makes the time to satisfy customer requests much shorter. One ASP that I know does daily production releases. It’s possible, and it’s probably the pareto optimal point. Customers should ideally have lots of ways to get service, from a thriving community.

A Bonus Pack of ISV Strategies for Growth

andy — Fri, 23 Sep 2005 13:50:00 +0000

I have recently spoken with a number of enterprise software companies about a raft of strategies for growing their businesses. The market for enterprise software (including hosted apps) is improving after a tough half-decade, but it still isn’t comfortable for vendors. Buyers still don’t like buying big systems because adoption …

I have recently spoken with a number of enterprise software companies about a raft of strategies for growing their businesses.

The market for enterprise software (including hosted apps) is improving after a tough half-decade, but it still isn’t comfortable for vendors. Buyers still don’t like buying big systems because adoption is difficult and expensive. Budgets for new licensing continue to shrink. Sales cycles are long and expensive for vendors. Innovation by competitors continues, often involving powerful disruptors like open source.

Now let’s look at some good news and growth strategies

On-demand (hosted subscription) apps
Customers are finally moving to on-demand (that is, hosted subscription) applications in droves. They like the lower adoption costs and hassles, the starter packages, and they can pay for these deals out of operating budgets, which are much healthier than capital budgets. On-demand is also great news for a company that can afford to give up the initial license check. It’s good news for the CFO because the revenue stream and revenue realization is smoother and more predictable. It’s good news for the sales guys because customers can get started quickly. It’s great news for the product team too. They can move to agile development, because they control the release cycle and don’t need to fit closely to the long upgrade cycles required by installed corporate clients. And, on-demand products are strongly associated with open source infrastructure. Most of the leading on-demand vendors use open source components because they save money and increase flexibility in both development and datacenter operations. One big win (cost saving and development acceleration) comes from not having to test and support the various types of proprietary software that clients insist on (eg Oracle versus DB2). An emerging innovation is the custom ASP.

User innovation
Most vendors of any kind of product fall into a (profitable) rut. When they go to make a new version of their product, they survey existing customers to figure out what to do. That leads them to build a better version of their existing product. However, it doesn’t lead to market growth through products for people who aren’t already customers. Users, however, are a diverse group, and some of them will do amazing, market-expanding things with the product if they are given the opportunity. The key is to pay attention to the right customers (the ones that are “leading” as opposed to just eccentric) and give them the opportunity to innovate. You can read my blog entry on this effect here.

Platform strategy (with VARs or customers)
The platform strategy is a way to work with customers, consulting firms, and VAR’s that know more than you do about a particular market. You give them the tools to modify your product, and they make more specialized products. Salesforce.com has been pushing this strategy hard, and winning with it. The key challenge is making it work in the new environment where more apps are centrally hosted. Customization, sharing, and open code are relevant in the hosted case as well as the installed case.

Customer Collaboratives
The customer collaborative is a way of supporting the customers that work with your platform. Vendors have traditionally avoided supporting custom or integrated versions of their products, because upgrading those versions is a really hard task. Better to stick with the one line of official releases. Unfortunately, the customer reality is that they DO have customized and integrated software. The vendor can get extra revenue (literally, an add-on maintenance sale), raise customer satisfaction, and gain new innovations, by providing extra support for those customized and integrated versions. The customer collaborative provides shared code, build environments for customized versions, and tools for collaborating within and between customers and integrators. If this allows customers to get enhancements they want faster, they may even buy faster.

From Outsourcing to the Agile Global Team
Over the past ten years, a large amount of software development has been moved to low-cost countries through outsourcing. In the process, we gave up the agility of having teams work together on the entire process of defining and building software. Outsourcing required a considerable amount of extra work to specify software, hand it off, and accept it. Now, with “inspired by open source” techniques, we can get back the agility. We can create a single global team that is even more distributed. Any of those team members can be responsible for any part of the process. This saves money because the distributed team can handle a larger chunk of the process. And, it saves time because we can run agile processes.

Open Source licensing
Open source and shared source licenses are an essential ingredient of platform strategies (even Microsoft’s), and customer collaboratives. They are easy to adopt if the vendor is selling some core, closed-source platform code (for instance, a search engine, workflow engine, or OS) and they want to encourage people to wrap applications around it by releasing a bunch of application level code.

Selling software licenses to enterprises is a long, expensive, and often fruitless process. Only big software companies can do it comfortably. If you are a smaller company facing this sales cycle and losing money, you have options. You can try to sell yourself to a bigger company with a better channel. Another now-standard option is to release your software as open source. This creates an entirely different sales cycle, where users adopt your software first, and then call you later for service and support. It’s not a cure-all, but it’s often better than the alternative. I think it will be a financial win in cases where the first-mover can take a big chunk of an existing application market.

Buying, Selling, and Global Scans
If you aren’t big enough to survive the sales cycle, selling to a bigger company with a better channel is probably a good idea. The flip side of this is that a lot of software assets (with limited customer bases, but good embedded industry knowledge) are available to be purchased at very reasonable rates. It’s a big world. If you post a message to contract development boards, industry boards, venture capitalists, and IT users who build their own software, you will often find software that roughly meets your needs for satisfying a new market.

Custom ASP?

andy — Sun, 14 Aug 2005 14:36:00 +0000

In 1999, there was a huge surge in interest in ASP’s for enterprise software. By 2001, pundits declared the model a failure. One analysis was that ASP’s wouldn’t be able to effectively service enterprise customers, because the systems needed to be customized and integrated, and doing so would destroy the favorable economics of the ASP. It’s now obvious that the ASP model wasn’t a failure. It just didn’t quite keep up with the extreme growth forecasts. Our ASP packaging at PowerSteering continued to be the leading version of the product, and companies like Salesforce.com delivered ever-better and more configurable products. ASP sales volume, market share, and sophistication continue to grow every year.

So what about customization and integration? Is that a shortcoming of the ASP model? Is there a way to combine the favorable features of an ASP - instant startup, always on, invisible upgrades – with the customization and integration that more sophisticated customers want?

A coincidence of timing last week highlighted the questions for me. I had lunch with David Skok of Matrix Ventures on Wednesday. Matrix claims to be the most successful venture firm ever when measured by consistency of returns and ratios of winners to losers. They make a rigorous analysis of business opportunities, in the selective style of an east-coast VC firm. Skok himself is a successful software company founder and CEO with more than one IPO under his belt. So, when Skok criticizes an approach, he probably has a very good point.

In this case, he took issue with my opinions on customizations. I was claiming that the facts on the ground for enterprise software customers are that they are supporting custom configurations. Instead of avoiding the issue, vendors should take the lead in delivering code, processes, and infrastructure to support these customizations and the related upgrade cycles. Skok argued that:
1) Vendors should be “market driven, not customer driven”. They should stick with a 12 month development roadmap and not get thrown off course by inevitable customer requests.
2) Customers don’t want customizations to the core product. They want a clearly defined and separated area of customization and configuration that goes against a defined API supported by the vendor. They know this will increase quality and reduce their integration and upgrade expenses.
3) It’s just too hard to support customizations and upgrades, so vendors are smart to avoid it.

In leaving, Skok said “I’m really interested in the ASP model.”

That’s where the coincidence of timing comes in. On Thursday, I went to New York to start an advisory engagement with a company called Foothhold Technologies. They make software – delivered as application service – which is essentially a Web-based ERP system for agencies that serve the homeless.

I was amazed when I learned two facts. First, that they have more than 50 ASP customers, and that a majority of them have some level of customization. Second, that they try to address every customer bug report and UI request in one day. They do a production release every day.

This company somehow swims against all of Skok’s objections.
1) They are totally customer driven. Virtually everything in the product was added incrementally in response to some customer request or planned customization.
2) Customers ask for changes in every aspect of this type of application
3) They have been doing this for years with a high level of reliability and one day turnaround.

Even more amazing, this level of service is delivered with a software and development architecture that was not explicitly designed to suport it. They have a four-person development team supporting a 500 screen, 200 table application with dozens of variations. Their application has grown up incrementally over eight years from a set of Progress 4GL scripts, that at one point became funneled through a Web gateway to create a homemade Web application server. All of the customizations are inserted directly into the same codebase, which is riddled with statements of the type “if Customer X then do Custom thing for customer X”. It’s a small team working with what has become haphazardly designed spaghetti code, currently being re-engineered.

Yet, it works. They are succeeding. They have more than 50 customers, have reached profitability, and are gaining market share. That’s a harbinger of the future, an existence proof for custom ASP’s.