I just posted a new idea to Cambrian House... Regional Domain Name Sublet. It is a way for an owner of a domain name to "share" the domain, without giving up total control of it, potentially making some money off of it, and helping others around the world that might benefit from the domain name.
There are a lot of technical and legal issues with it, but that is why it is just an idea...
I have received and amazing amount of feedback on the Enterprise SaaS series; just about everyone who read it has contacted me. One person said he had a problem adding a comment on the site. I have not been able to reproduce the problem he encountered; if you are having problems commenting, too, please contact me via email (lincoln [at] lincolnmurphy [dot] com). Other than that one technical glitch, I have received mostly positive comments, but usually someone has at least one concern. I am going to try to address all of their concerns at one time.
Hybrid SaaS != Hybrid Licensing Model
A couple of people have mentioned that trying to support a hybrid licensing (or business) model would be difficult at best. I couldn't agree more. I never intended to support or even condone multiple licensing models.
I re-read what I wrote, and while it makes sense to me, you really have to follow it closely otherwise you could think I am supporting multiple licensing models. In fact, my "Hybrid SaaS" model is a hybrid technology model that is supported by only one licensing model, utility pricing. What I condone is pretty much technology agnostic and relies on the system being able to "call home" to handle the pricing. I think that is the future of the software industry more so than any actual technology.
That said, I think the SaaS delivery model is the future of software. I am definitely pro-SaaS, including Pureplay SaaS. This series was just to let people know that while we as technologists, entrepreneurs, and evangelists have adopted SaaS as the de facto standard for software delivery, Corporate America, as I have seen it, is not onboard with that. Are they changing? Yes. Will it get better? Absolutely. SaaS is just not ubiquitous yet and you must be prepared for that as a new SaaS start-up. In one or two years, these objections may go away completely; you still need to know your customer though.
A problem with many SaaS vendors is they come in and say "we're a SaaS vendor" like the customer cares. Do on-premises software companies come in and say "our software is written in Java" or "we distribute our software on CDs"? No. And they shouldn't because no one cares. The caveat with SaaS is that it is actually more difficult (hence the creation of my articles), because you actually need to make sure they can support that type of delivery mechanism.
But what about selling the benefits of the SaaS model? Yes, you need to do this. But it has been my experience that you must do this after you talk about solving the problems of your customers; "Not only can we solve your problems, bring you these value-adds, but also our unique delivery model can save you money...". If your only differentiation point is the delivery method of your software, that seems rather weak.
Source Code Escrow Questions
I got this response from one reader:
I liked the idea of setting up an escrow for the source code as an insurance policy for the customer. I suspect many will scoff at that idea since the IP can be sold at bankruptcy auction but perhaps with an expiration date on the escrow agreement it would be a good tool for start-ups to use.
I'm not sure how widely used software escrow is, but it is certainly not a new thing. I ran into it when I was looking for a hosted supply chain solution a few years ago. I asked them what would happen if they go away and they introduced me to the concept of software escrow.
Source code escrow is a very detailed process and has strict controls over the IP. It is totally up to the parties involved, but you can always specify that the beneficiary is not allowed to use the IP outside of the scope of its intended purpose, i.e. they can't take it and commercialize it on its own or use it in their own products.
Source code escrow is really only used to facilitate business continuity, not to turn over rights to use the IP as you wish. Those rights are maintained by the owners, probably the investors (or creditors) in the venture, to do with as they wish.
I have also been told that SaaS is in use in just about every Enterprise in one form or another. I would take it one step further and say that both Pureplay SaaS and Hybrid SaaS applications are both in use heavily. Pureplay SaaS in the form of HRM, CRM, SCM and Hybrid in the form of vendor-provided desktop applications such as benefits management, shipping carrier systems from UPS and FedEx, etc.
If SaaS is already in Corporate America, why do I say the barrier is still there? Three reasons. 1) you are a start-up, not an existing vendor with a new (often free) product to improve the relationship (such as UPS or FedEx) or 2) you are requiring payment in excess of the unit managers expensing abilities or have requirements outside of that of a standard PC (thus drawing the attention of the IT and Finance departments) and/or 3) you are trying to differentiate your product and must sell to multiple levels, thus bringing it to the attention of the IT department and other conservative levels of management.
I have been inside of multiple companies where I am getting resistance due to the nature of our product architecture, while simultaneously talking about how we are going to integrate with other systems in use that are SaaS themselves. Again, your experience may vary, and this is all based on my experiences. In my experience it is still a challenge for a vendor to sell a SaaS-delivered product in Fortune 1000 companies. Times are changing, it is getting better, and soon, SaaS will be ubiquitous. Until then, please be prepared. You *can* sell SaaS-delivered solutions to Fortune 1000 companies; it is just easier if you know what to expect when you go in there. Good luck!
This series is to help Enterprise SaaS vendors with two potentially business-stopping problems; scalability and sustainability. I am attempting to address both the real-life objections seen in Fortune 1000 enterprises when selling a SaaS solution and some ways to work around them.
This series is also meant to get SaaS vendors to really look at their delivery model and make sure they are not taking on more of the support costs than they actually need to. By knowing your target customers, you can save yourself (and your investors) a lot of money and improve your margins; you could even save your company in the long run.
This series is my opinion and is based on my experience. Your experience may differ, and this is not meant to be the definitive text on the subject. I just thought I would share it. Below are links to all three parts of the series, abstracts of each part, and a fourth part addressing Economies of Scale and SaaS.
Part 1 Who needs Pureplay SaaS? Why do you want to be a Pureplay SaaS vendor if you are not targeting those market segments? One of the biggest "selling points" of SaaS as a software delivery model is reduced support costs for the user. This is great, but if you are selling to a company that already has the infrastructure to support On-Premises enterprise software, why would you take on those support costs yourself? With SaaS delivered software, who supports it? More than likely it is the SaaS vendor handling all support, from first level up. Can you as the SaaS vendor really handle these support costs long-term?
Part 2 Starting a software company from scratch, On-Premises or SaaS, is no small task. There are five major objections witnessed when a start-up is selling SaaS solutions to Fortune 1000-sized companies: existence, reliability, support, and scalability. These are objections faced by almost every start-up in one form or another whether they sell software or not. The list of "legacy controls" are objections witnessed that are specific to selling Pureplay SaaS in a Fortune 1000 Enterprise: Internet access blocking, locked down PCs (no ActiveX controls or Flash animations), disk space quotas, etc.
Part 3 The SaaS industry obviously agrees that SaaS is the future of software delivery, but while they still have a substantial amount of value in their existing systems left on the books, the Pureplay version of SaaS may not be needed in Fortune 1000-sized Enterprises.
SaaS is often a combination of an On-Demand delivery mechanism (SaaS), and an On-Demand licensing model (Utility). First, don't be a Pureplay SaaS vendor if your market will not accept it. Be a solution provider first, a software company second and a SaaS company third. Mention solutions to their problems. Do not get stuck on a technical solution that doesn't fit with your customers needs. Meet the immediate needs of your customer by building in Utility Pricing to your application and/or architecting a Hybrid SaaS system.
The Elusive Part 4 - Economies of Scale and SaaS
A big selling point for SaaS is the economies of scale the hosted solution provides. This is true, especially at the data center level. I seem to have missed the boat on the economies of scale argument, or so I have been told. However, when working with Enterprise customers who do not need their software vendors taking over their infrastructure support costs, why would the SaaS vendor take on this burden? Perhaps you would be happy with 35% margins when handling all of the support costs. Your investors would throw the Economies of Scale book at you when they find out you could have been working with 60% margins by not taking on the additional support burden.
After overcoming all of the objections in your control: existence, reliability, support, and scalability, you must now overcome the objections that are not in your control. These are the real show stoppers and come from not understanding your target market. The SaaS industry obviously agrees that SaaS is the future of software delivery, but while they still have a substantial amount of value in their existing systems left on the books, the Pureplay version of SaaS may not be needed in Fortune 1000-sized Enterprises.
SaaS is often a combination of an On-Demand delivery mechanism (SaaS), and an On-Demand licensing model (Utility). This is a very powerful combination. The real power for Enterprise clients, at least in the near future, might be found more in the licensing model more than the software delivery model.
When developing a SaaS product for the Enterprise market and faced with the "legacy controls" objections detailed in Part 2, there are three rules that should be adhered to. First, don't be a Pureplay SaaS vendor if your market will not accept it. Be a solution provider first, a software company second and a SaaS company third. When talking to investors or other people that know about SaaS, then you should be specific. When talking to the clients, it is best not to mention technology at all. Mention solutions to their problems. Do not get stuck on a technical solution that doesn't fit with your customers needs.
Focusing on the solutions of your clients is one thing, but you also do not want to try to be all things to everybody. You need to find out what one or two solutions you need to penetrate your market, and go for it. Those customers that require something else will have to be left out. Doing one off deals at first is a great way to kill your scalability as a company and is often what keeps software companies small. They may have big clients, but might only have a handful. This is the difference between the birth of a lifestyle business and a high-growth enterprise.
The second two rules focus on implementing the first rule of not being a Pureplay SaaS provider. There are two ways to work around being a Pureplay SaaS vendor, but still remain in the On-Demand market; Focus on On-Demand licensing/pricing and/or build a Hybrid SaaS system. From the business side of SaaS, the most exciting thing is the next generation licensing model.
The legacy model of paying a large up front license fee for the software (or paying over time on a lease), plus annual renewals and ongoing support fees is definitely ready to be put to rest. Billing companies for their actual usage of the system is very exciting. In fact, using a company like LeCayla with their Metering and Billing Infrastructure, you can do this today with your existing On-Premises software. This is a way to leverage your existing software, but bring a different pricing model to the table.
For a start-up, and that is the target of this series, a service such as LeCayla allows you to offload the processing, storage, and infrastructure support to your Enterprise customer through an On-Premises or Hybrid SaaS solution (defined below), while still offering Utility Pricing to your customer. This provides a "best of both worlds" approach, and helps you sell your product with the always popular "low sunk cost".
Coming back full-circle to "knowing your customer", another detail in your customer intelligence gathering should be their economic focus; are they a capital or expense oriented company? (a great discussion of this if found at 35:42 of this podcast from SaaScon) In other words, do they care that they can pay over time for what they use or would they rather pay one large, up front fee? If you've done your homework, this won't be a surprise. In this case you just avoid On-Demand pricing as a selling point.
On the technology side, the best solution outside of simply plugging in billing software to an On-Premises application (not ideal) would be to build a Hybrid SaaS system that can support both Pureplay SaaS and On-Premises clients. To do this, the system must be architected from the ground up to support this model. The hosted system would be a single-instance, multi-tenant system. The On-Premises system acts as a remote-tenant, "calling home" and sending billing data and other "network effect" data to the single-instance data layer. If you have "network effect" features, this is a great way to tie On-Premises installations into that shared data layer.
The technical implementation of this is so dependent upon the problem you are solving, the target vertical (if any), the On-Premises requirements and needs, etc. that trying to suggest an actual "remote tenant" solution would be impossible. Remember, the technology used is not important to the customer, just to you and maybe your investors. Whether it is a legacy server-based product that uses SOA to move data to the hosted system, an On-Premises "lite" version of the hosted system, or even a desktop application, the technology does not matter.
What works as a SaaS vendor very much depends on your target market. Involving customers early on will save a great deal of pain down the road. This involvement must be at multiple levels as well. The line manager will give you great functional feedback, the Controller will give you reporting requirements, and the IT group will tell you what you can do, what you can't do, and what they are willing to do.
This might sound obvious, but this is mostly geared toward start-ups who might not think to pull in all of those resources. The key lesson is whether you are a SaaS or On-Premises vendor, know your customer and involve them from the beginning. You cannot develop a solution to their problem without knowing not only their problem, but the acceptable ways to solve it.
Starting a software company from scratch, on-premises or SaaS, is no small task. The barriers to entry into the Enterprise software market are significant to say the least. To top it off, there are a number of things that can hinder adoption of your solution in large corporations, putting a stop to your venture before it ever starts. Below is a list of five "issues" witnessed when selling SaaS solutions to Fortune 1000-sized companies. Assuming you have everything else in order, be prepared to address these objections..
Oh, you're a "start-up".
Of all the issues that have come up, this is the one that you simply cannot avoid or steer around. I have always addressed it openly and to the point. "Yes, we are a start-up", I then tell them that this is something we have thought a lot about; how do we convince our client that we are the ones they should take a chance on? I always tell them that "I can't go back in time five years and start then, I wish I could".
As much as SaaS vendors like to talk about "low sunk cost" in selling SaaS solutions or the flexibility of on-demand pricing and being able to drop the service at any time, the reality is the company who says "yes" to you isn't just making a monetary investment in you; they are investing their time and resources in your product. They are not looking to "just switch" if they aren't happy. Regardless of licensing or contracts, they do not want to have to find another solution.
The biggest issues with a start-up is that of sheer existence. Will the vendor be around beyond next week? This is a real concern to customers and, frankly, it is warranted. There is little that can be done to alleviate the chances of existing for a long time. The first is to show the customer the $20M in fresh VC money that was just deposited. That should release some of the pressure, although in reality it probably shouldn't. Barring that kind of funding to show off, the only solution that makes sense is to take out an insurance policy for your customer. Put your source code into escrow with the beneficiary listed as your customer. This way, if your company goes away, at least the customer can take the software and continue to support, and develop it, internally. The software escrow process is actually quite extensive, as it requires both source code and binaries, installation manuals, checklists, and the developers personal contact information.
After the existence hurdle comes reliability concerns. With everything running on "your network", how can the customer be sure of 24/7 access to the system? The best bet is to partner with a reliable hosting company, preferably one that understands your business model and can provide more than just hosting space. There are companies out there called SaaS Enablers, such as OpSource, which combine everything from server hosting, on-site DBAs (who learn your schema and can offer performance improvement tips) to first level tech support for your application. OpSource also offers 100% uptime guarantees and you can have your customer's IT staff talk to someone there if they have questions about the data center itself. This is my preferred method for launching a start-up SaaS business, but there are other ways. You could build your own data center, and if you have a great deal of VC funding, perhaps that is the way to go. But being able to show 100% uptime guarantee, and back it up with referenceable accounts, is the key to overcoming this objection.
Using a company like OpSource also addresses the scalability and support questions your clients will have. If you architect your product correctly, OpSource can monitor your application and scale it where needed on-demand. If you need more application server horsepower or more database storage, those resources can be allocated on-the-fly, ensuring your system maintains stability and integrity. (note... I am not a pitch man for OpSource; they just happen to be great people with a great service and they have been very helpful to me).
Those objections, existence, reliability, support, and scalability, are really the most difficult to address, the first one being the hardest. Never try to skirt the issue of being a start-up; explain what you are doing to alleviate the potential problems and get through it. While I have seen those as objections, I have not seen them as show stoppers. The following I have seen as show stoppers.
In Part 1, the Myth of SaaS Ubiquity was addressed and dispelled. It is simply not the case, and the following objections to your SaaS offering will make you scratch your head and ask if you are still in 1994. The first stumbling block in getting your SaaS offering in the door is going to be the antiquated corporate policies in place. These will include Internet access blocking, locked down PCs (no activeX controls or Flash animations), disk space quotas (severely limited local disk space), and more. The best bet as a SaaS vendor is to include someone from their IT department from the beginning. In fact, if you provide a line-of-business application rather than an Enterprise support product, you may be able to get the IT department to champion your product and do a SaaS pilot. If their IT personnel are exploring the blogosphere, perhaps they believe SaaS is ubiquitous and feel left out!
Outside of the legacy controls still present in many large companies, there are some other factors that are present in just about every company, big or small; an internal need to justify infrastructure expenditures. If the CIO six months ago signed off on $2M worth of new server hardware, the last thing they are going to be looking for is software that does not run on it! Whether recent or not, the internal investments must see a return, and SaaS does not fit the bill. Remember, if they can't justify that expenditure, they might not get more money down the road, and that is simply not going to happen.
Finally, and perhaps the most difficult hurdle to overcome when pitching SaaS delivered software, is the job protection angle that the leader of the IT group might take. Why would the IT Manager want to give up control when that would mean less headcount, which leads to smaller budgets, which leads to smaller salary and smaller bonuses? If you are selling to the C-level, talking about reducing FTEs can be a great thing. If you are selling to line managers and Directors, this is the slippery slope theory in action. They do not want to give up control and will hold on for dear life and at all costs.
What those objections have to do with Vendor Sustainability in the SaaS space is elementary. Focus on the needs of your target market. If you are set on being a Pureplay SaaS vendor in a market that does not like Pureplay SaaS vendors, you will fail. At the same time, if you are in a market that does not need Pureplay SaaS vendors, you might not fail, but you will certainly spend more money than you have to; why take on any more of the support costs than you absolutely have to? Part 3 will focus on a couple of ways to appease those Enterprise clients who aren't keen on your SaaSy ways.
Apparently someone leaked the internal slides detailing how Wal*Mart developed their "Shopper Segmentation Plan". It is an interesting read and makes perfect sense. If you look at the comments section of the Consumerist there seems to be a lot of negative reaction to these slides. I think it is more of the "whatever Wal*Mart does is bad" reaction than a true reaction to the study.
The slides are here, and remember this was "leaked" so it may not be real.
The definition of Pureplay SaaS is where the SaaS vendor offers a completely hosted system with the customer needing nothing more than a standard PC with normal input devices to take full advantage of the offering. If you live in the blogosphere, you might think that SaaS is ubiquitous in the Enterprise by now and that on-premises software is a thing of the past. In fact, SaaS is so ubiquitous and it is almost old news, and you are seeing more of the XaaS variants rearing their ugly heads. That is simply not true. While SaaS is certainly growing, it is not the norm yet as many pundits would have you believe.
This series is to help Enterprise SaaS vendors with two potentially business-stopping problems; scalability and sustainability. I'm not sure many people are looking at these problems when planning their SaaS offerings. By examining who actually needs SaaS versus who might just want it, a bad scenario for the Enterprise SaaS vendor may be avoided.
Who needs Pureplay SaaS? If you look at the major benefit that SaaS brings it makes sense that the low-hanging fruit will be in the consumer and lower-end SME markets. I'm not going to address the consumer market because it is not one that I understand well. I understand business, so I tend to only play in that arena. The market that I do understand are the SMEs. Rarely do SMEs have a well-defined technology infrastructure (and even more rarely do they want one), so a SaaS offering in the CRM, Supply Chain Management, or vertical-specific space makes sense for them. They can offload the support costs onto the SaaS vendor and allow them to focus on their core competency and just use the software. This is the way it should be.
Why do you want to be a Pureplay SaaS vendor if you are not targeting those market segments? Perhaps you are caught up in the hype. If that is the reason, you need to examine a couple of things that you might not have thought of. One of the biggest "selling points" of SaaS as a software delivery model is reduced support costs for the user. This is great, but if you are selling to a company that already has the infrastructure to support on-premises enterprise software, why would you take on those support costs yourself? The fact is, as you add customers and users to your system, your support costs go up. Whether it is storage or bandwidth, you will end up paying for your success.
Aside from the hard support costs of taking on all of the burden yourself, you also take on all of the tech support issues. It is the norm that on-premises software will be supported in house as much as possible. If the problem cannot be resolved internally, someone on the technical team of the organization will call the vendor and work through the problem. The technical team has a vested interest in making sure that the problem is resolved in a timely manner since they "own" it. With SaaS delivered software, who supports it? More than likely it is the SaaS vendor handling all support, from first level up. Even if you have worked out an agreement with the customer's technical team, how do they actually support the product, even first level? Can you as the SaaS vendor really handle these support costs long-term? What is more, large-scale on-premises software is almost always accompanied by a support contract. It is much more difficult, though not impossible, to sell one of those when you have a Pureplay SaaS product?
While it may be a long-term company killer to take on all of the support costs yourself, it may in fact be a company starter-killer. In some large enterprises you may find being a Pureplay SaaS vendor to actually hinder the adoption of your product. That will be addressed in Part 2.
I decided to post these to Cambrian House because I figured if they do get picked up and taken to market, at least I would get a little something out of it rather than just posting it on my site for the world to take. Sure, the world could take it from Cambrian House, too... but there are at least a couple of people there who might be motivated to work on this
But what is very interesting is the title of my post; Ideas Are a Dime-a-Dozen. That couldn't be more true. Everyone has at least one good idea in their life, but few act on them. Even when they have a good idea and act on them, often the result is failure. Why? Its not the idea, but the execution that matters. And execution is much, much more difficult than you might imagine.
Can Entrepreneurship be learned? Can it be taught? Those are two different questions. In fact, I would say that even if it could be taught, a true entrepreneur would be unable to teach the class and a true entrepreneur would be unable to learn from it! Most of the entrepreneurship classes offered by universities are more along the lines of "how to run a small business" mixed with some management and/or finance classes. If you are lucky, you get a few marketing classes thrown in. Is this information valuable to an entrepreneur? Absolutely. Is it entrepreneurship? No.
Is it a Sickness?
Yes. And it is terminal. I'm sorry to have to break this to you. If you have it, you will always have it and it might actually kill you. If you don't have it, do not fear; it is rarely, if ever, contagious. In fact, as a carrier, if you try to infect others, you will fail miserably. It is best to mix with those who already have it. I am talking about entrepreneurship here, right?
Is it a Blessing?
It is great to be optimistic, to see opportunity every time you turn around. Oooh, I just had an idea, what if... Wouldn't it be cool if... Dude, how awesome would it be if we could... Yes, it is a blessing. When an entrepreneur walks down the street, they can see a million ways to make a million dollars. This is *not* something most people can do, and probably something "mere mortals" should not try at home.
Is it a Curse?
It is great to be optimistic, to see opportunity every time you turn around... but sometimes it would be nice to not. To turn it off. Stop thinking about all the different ways you could develop a new business model for that widget. In fact, even if you aren't one of the entrepreneurs who doesn't sleep at night because their brain won't turn off, you still might be so full of ideas that you never execute. There are lots of people who "execute" on business ventures, but are not entrepreneurs. Think real estate investors and small-time franchisees who keep their "day jobs". Those aren't entrepreneurs, those are investors. Reid Hoffman, Chairman of LinkedIn, said it best in this podcast from the Stanford Entrepreneurial Thought Leaders series:
I'm going to jump off a cliff and assemble the plane on the way down
That does not sound like the words of a sane individual... I'm going with "yes", it is a curse.
On Friday, March 4, 2007 the New York Times published an article detailing Wal*Mart's new way of looking at customers' buying styles. The fact that a search of the blogosphere has only produced only a couple of results (TracyPlaces, Ponder Marketing) is troubling; perhaps we'll see more on Monday. As we should all know by now, the Wal*Mart Effect affects us no matter where we shop, even if we boycott Wal*Mart.
To all of the manufacturers and wholesalers out there that sell to retail merchandisers, this should have a huge impact on how you look at your future sales; even if you do not sell to Wal*Mart. If you don't sell to Wal*Mart, but have a high-end brand, perhaps this news would make you consider Wal*Mart as a merchandiser who could carry your product and not tarnish your brand.
In fact, if what Wal*Mart says is true, there are people with lots of money shopping there, and if your product is there too, they might pick it up. Even if it is for no other reason than to save a buck, but still appear in front of their friends with name-brand items. This could really change a lot of things in the retail merchandising business. Don't be surprised when those three categories ("brand aspirationals", "price-sensitive affluents", "value-price shoppers") begin to circulate as the defacto standard in the discount retail segment (Target, K-mart, etc.).
Of course, my standard warning to any manufacturer or wholesaler considering selling to Wal-Mart applies here. Just because you can, doesn't mean you should. Are you adequately prepared operationally to deal with their supply chain efficiency requirements? Can you handle the pressures of working with their strict pricing models? Do you have the support infrastructure to handle the rapid increase in sales volume? Often companies see a contract for Wal-Mart as a blessing, but that is not always the way it plays out. Sometimes it is best to say "no" to Wal-Mart and lose a large volume of sales than to say "yes" and lose your entire business.
Is competition bad? This is always a hotly debated topic. How many entrepreneurs, when asked about competition for their new venture, respond "there is none?"
Not only does that response make the entrepreneur look foolish by saying that there is no competition, but that lack of competition does two things:
It shows that the entrepreneur did not do his homework (going back to "foolish")
It un-validates the market
First of all, it really does make the entrepreneur look foolish. There is no other product or service, anywhere, that does what you are trying to do? Really? At all? Okay, so they may not be doing exactly what you are, down to the last detail, but are there other products or services that come close? How about substitutes? Even the status quo is the competition. An entrepreneur must think of every potential competitor, even if the only competition is "no action".
Assuming that there is not even a substitute product (other than doing nothing), by stating that no one is playing in your field could be a turn off to investors. Why is no one playing in this field? Could it be that there is no economic reason to enter the market? Is there no money to be made? Like selling ice to Eskimos? (With global warming, this might just be a viable market now!) Perhaps the niche is simply to tight. What if you expand a bit, do you now see competition?
But what if... just what if you did find that one thing that no one has ever thought of before and there really is no competition (except there always is the status quo), then you better be able to prove that no person has thought of it before and you really are the first. This is not impossible, and I hope that you do find that needle in a haystack, but it is a bit improbable these days. If it is true though, you must be able to prove that there really is an economic model behind it.
The bottom line is, if you enter a market with no competition, you have your work cut out for you, both in finding investors and customers. The investors won't believe you have a market and the customers don't know there is a pain you have a solution for. Competition is good; a fragmented market with lots of small competitors is even better. Look, everyone is jumping in, but no one has significant market share! Whoo Hoo!
In case you wish to keep track of your competitors, my buddy Andrew Holt started a site last year, which I use extensively, called Competitious. It is a great competitive intelligence site, especially for web companies. It aggregates data from around the web on both you and your competitors, keeps up with your buzz on the blogosphere, etc. Go read their front page and learn all about what they do. Fantastic site, and free!
Most people in technology these days are familiar with, or have at least heard of, SaaS, or Software-as-a-Service. I have recently seen Integration-as-a-Service or IaaS, and witnessed a proposal for BPOaaS, or Business Process Outsourcing-as-a-Service. The latter was more of a tongue-in-cheek sort of comment. This means it may be time to revisit the x+ variable acronym system, the x+VAS.
I decided to post about the creation of the term XaaS (pronounced Zaas), meaning whatever (the variable "x")-as-a-Service. I then decided to Google this little gem and found... duh duh duh... someone already coined the term. And they made a video to:
After we come up with enough XaaS acronyms, as more and more "things" move the "as-a-service" model, hopefully we can drop the "aaS" and just call it, once again, Software or Integration or BPO. Hopefully this will come as part of the understanding that we have dropped the silly legacy pricing / licensing model in favor of the more liberal, and in my opinion more profitable, utility pricing model.
I don't generally lay claim to much, but one thing I came up with recently was "Mail Center Accountability™". It is such a powerful term in the world of Mail Center Management because it hits on something that has been missing in that field. It is so spot-on, that I have noticed others in the industry starting to use it, including a competitor to the product I was going to bring to market. That is just more justification that the idea was sound, but the circumstances were not. I must, however, say that I own "Mail Center Accountability™, which is why I put that little ™ by it. It isn't registered yet, but I certainly used it first (you can Google to verify) and will register it someday if I need to. Precedence has been set, so just be aware.
I help companies bring their Software-as-a-Service (SaaS) and Web applications to market by leveraging the Morph Application Platform and Morph AppSpaces, the first Platform-as-a-Service (PaaS) for Ruby on Rails.
I am located in Dallas, Texas. Contact me via email.
| »
