We are a B2B startup that has been started based on great technology (MIT PhD/Spin-off for developer tools/uml). We want to get around some of the inefficiencies in our industry by allowing for incremental adoption of our product, i.e. by distributing the product as a SaaS.
I have heard of bootstrapping tips when it comes to typical B2B plays - such as not discounting the product in th beginning when the features are limited but instead spending more time in building out the parts of the product that the customer needs (i.e. many one-off sales while moving IP into the core product).
Are there any similar tricks for SaaS companies? Or do we need to just get a basic product out of the door to a large user group and wait for enough adoption before investing in the higher end capabilities?
The fact that it's SaaS doesn't really change the fact that it's a B2B product, so you'd better pre-sell it to a select group of early customers. Ideally, you want to start by visiting your first 10 potential customers and telling them: "we are experts at doing X and we are going to launch Y very soon. We'd love to have you as an early user so you can influence the features to fit your needs."
Then develop the product.
Then broadcast your success (early adopters) to the rest of the world.
We had success by starting with consulting, then building a product in parallel to help serve the same types of customers our consulting services helped with. If you're good at it, the demand for consulting always exists - and it can also help you to build the relationships that you can later leverage to make sales on the SaaS model.
Looking for projects that will advance the core architecture while satisfying the requirements is a great way to boot strap the service. The trick is finding an RFI that you can partially comply with.
When you are answering those RFI's you can make a distinction between a feature that is "implemented" or "deployed" and a feature that is "supported" by the underlying architecture but hasn't actually been implemented yet.
Usually you can partially comply with a requirement and stipulate that the architecture supports the quick implementation of said requirement.
Also, doing free pilots is another way to move the architecture into a position to satisfy the final project and solidify your solution as a front runner for the project vendor selection.
Get the basic product out the door and iterate. Do not customize for customers. Target small businesses: there are more of them, they are easier to work with and fewer business go after them (because everyone thinks all the money is in large businesses).
Since this is a B2B situation, you may want to consider a revenue-sharing model with your customers (if applicable to what you're doing). Basically, when your customers make their own revenue by using your product, you get a piece of that action yourself. So if your product enables them to bring on X new customers or make Y new sales to existing customers, then they might be willing to pay you in turn using some formula based on X or Y -- for example, $100 per new customer, or .5% of new revenue, or whatever.
There are many other models you could imagine, but the idea is that if they really think your product is helpful to them, they'll be willing to pay based on real customer sales. I've seen this model used before, anyway; whether it works for you or not depends on your particular industry, product, and situation, of course.