Trends: VC Funding Models Favor Even Simpler Sales Cycles

I've been meeting a number of VC firms this past month to see if anything new had emerged in terms of enterprise software and tech service provider trends. Standard topics ranged from Web 2.0, future of SaaS, would Larry continue to be the exit strategy, and whether or not IBM would publicly come out and enter the enterprise apps space to the depreciating dollar, state of the economy and the downfall of Billary. But a few things kept sticking out in conversations on what type of software and service companies were receiving funding. Here are some must have characteristics that bubbled out:

• Payable with a credit card and not require board approval. VC's like sales models that have a fairly regular and low barrier to entry. Some examples include subscription pricing because it targets operational expense instead of capital expense (i.e. no need to go to the board).
  

As one VC put it, "If they can't buy it on their AMEX and run it through as an expense, it's not worth investing"

• Easy to consume and work like what's on the web. These new offerings, service or products, must follow more consumer user experience models. Because most of the power in the cloud beats what an enterprise has, users are now more accustomed to paradigms on the web and not the legacy apps they replace. More importantly, they must mitigate IT dependencies in not only decision making, but also support.

A serial entrepreneur stated, "We stopped pitching to the IT user 24 months ago. They remain irrelevant because we target the decision makers who want something working now and have the budget and authority to create change. They then go back and tell IT to go figure it out"

• Drive a sense of community and free user generated content. Content remains king but not if you have to pay for it. The drive towards UGC continues and the more successful offerings have a community component. This also applies to ancillary technology services and related knowledge based companies where the users and their communities create a self service ecosystem.

An Entrepreneur In Residence (EIR) confided with me and said, "These social networks create so much user generated content that we then monetize. Why pay or invest in content when the knowledge is in the community? We just need to put the tools in there and make it easy"

The bottom line.
While we may be in the midst of an economic slowdown and even headed towards a recession, VC's continue to have faith in models that put more power to an individual user or a small team of users. Lower price points, captivating and easy to use functionality, and thriving ecosystems remain the critical success factors in receiving funding. The era of funding on-premise start ups and large consulting firms may be over. This could explain the great interest in SaaS and of course the tremendous explosion of growth in the upcoming SaaS Con event.


(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2008 by R Wang. All rights reserved

Software Licensing and Pricing: Push for value from maintenance agreements, not discounts

I would like to provide an alternative view to Ray's most recent post, Software Licensing and Pricing: Stop the Anti-Competitive Maintenance Fee Madness. As head of research for the SSPA, whose members rely on maintenance revenues for their livelihood, I'm not ready to say maintenance contracts are overpriced. In fact, the SSPA view of this is the continued push back on maintenance pricing is having some major impacts on how (and how well) products are being supported.

According to our benchmark database, 81% of maintenance contracts for hardware and software are renewed annually, but over 1/3 require concesssions or discounts to renew. Enterprise hardware companies discount an average of 15% on renewals; for enterprise software companies the average is 9%.

What do you get for your maintenance? Bug fixes, new releases of software, access to community features to share best practices, and of course access to technical support. If the vendor did a good job of fulfilling these deliverables all year long, why are you balking at the maintenance renewal?

And, things are getting trickier for support organizations, whose push into proactive service means that more technical issues are identified and fixed remotely, before the customer is ever impacted. As Chip Gliedman always says, you don't call your doctor and thank them when you haven't been sick in a year. Similarly, support managers tell me that they are increasingly charged with "What have you done for me lately?" upon renewal, because so many problems were intercepted and eliminated that customers rarely interacted with support. In other words, when innovative support teams do a great job, they are invisible. And under appreciated.

If a contract is up for renewal, before you trot out your handbook on 'Negotiating with Terrorists,' be sure to get an account review for the past year and understand how many service issues may have been proactively resolved with little or no involvement from your staff. Review what support and maintenance options you were entitled to under last year's agreement and determine if the vendor delivered on these commitments. If they fell short (no timely releases, missed SLAs, etc.), give 'em hell.

This may be a radical suggestion, but instead of asking the vendor to continue giving you good service for less money, the renewal discussion should be "How can your support team help me get better value and more quickly achieve my business goals for your product over the next year?" If the vendor has not embraced this view of Value-Added Support and can't articulate how they are going to partner with you to help better leverage their products, then you are dealing with a support group in continual 'breakfix' mode that is unlikely to meet your needs for a strategic implementation. And that is a maintenenace contract worthy of hard negotiation.

If the vendor, and their support organization, has a shared interest in helping you succeed with their products, and you are getting as much (or more) value from your purchase as anticipated, then the maintenance agreement is a good investment.

Just my 2 cents. Thanks for reading!

(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2008 by John Ragsdale and R Wang. All rights reserved

Software Licensing and Pricing: Stop the Anti-Competitive Maintenance Fee Madness

Recent maintenance fee increases by several large vendors lack any logical rationale other than pure greed. Customers and prospects should demand lower maintenance fees in their contracts because:

• Maintenance fees represent the biggest cost items in the software ownership lifeycle. Every percent reduction in a $1M deal equates to an annual savings of $10,000. Controlling the base line costs and future increases results in long term cost savings. Keep in mind most deals focus on the net license cost.
  
• Maintenance and support remains highly profitable. Support and maintenance profit margins often hover between 60 to 85% after the third year of a product’s introduction. If a vendor invests 50% of that revenue into R&D, then the customer benefits. However, if the vendor pockets the profits, then the customer loses.
  

The bottom line
The lack of third party maintenance offerings and the anti-competitive behavior among the large software vendors has led to a de facto increase in maintenance fees without any subsequent value to the enterprise. On top of this, vendors come back and charge for new modules and functionality paid for from the maintenance and support profits. Market place consolidation has ultimately resulted in a less competitive market for consumers. Customers should revolt en masse by protesting any maintenance fee increases that do not come with additional value. Expect a potential class action lawsuit some time in the future where customers will claim collusion among vendors in charging exorbitant maintenance fees while keeping third party maintenance providers from delivering cost effective alternatives.

(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2008 by R Wang. All rights reserved

Trends: I would blog more often if I wasn't rewriting off-shored code

Back in December I was invited to visit a Silicon Valley start-up to review their software architecture and website design. I'll just refer to them as Startup. We spent two days walking through their prototype reviewing usability and performance.

One of the more interesting aspects of their software was that Startup had used off-shore staff augementation to develop the initial prototype. I recognize off-shoring software development is an emerging trend, and wanted to learn more about their experiences for better or worse. I've successfully coordinated virtual teams in the U.S. and was looking forward to an opportunity to see if the same strategies could be successfully applied to off-shore projects.

Startup had used the prototyping process to test out three different development teams, two in India and one in Russia. Having divergent teams work on the prototype was evident in the end result, functionality was duplicated and the architecture was inconsistent. For example, three different search mechanisms had been implemented.

Performance was poor. One page used AJAX for a partial page refresh of 500K worth of data.

Of course, these are the same types of results I would expect if you put three on-shore teams from different companies together on a project with little cross-team communication. Startup had been successful in finding which of the three companies they thought would be best suited for on going work.

Now we embarked on the rigorous process of revamping the prototype for usability and a scalable architecture. We agreed that I would provide architectural guidance, a member of Startup would do database design, and Team Off-Shore would do the grunt work of wiring things up. This sounded great to me, since I prefer the architectural work to writing lots of boring if-then clauses.

However, there are some big caveats to working with any remote team.

1) Experience Matters

Everyone has to make sure they check-in working and complete code. When this doesn't happen in an office, it's fairly easy to go over to the junior programmer desk, kick their chair and say, "You forgot to check-in the database change scripts!".

When the person you are coordinating with has a 12-hour time difference, and they are asleep, it means the rest of the team needs to reverse engineer and rewrite the missing database scripts. This pretty-much blows the cost savings of the off-shoring. The larger the timezone difference, the harder to recover from this type of error without duplicating hours or days worth of effort.

2) Design for Success

Developers work best when then understand the product vision or corporate mission. Specifications have to be very detailed. Its far easier to cooridinate enhancements on an existing well-defined product than on something which is literally in Startup-mode.

Startups by their nature need to be flexible and able to create features very quickly. Having a centralized team for this is faster, and improves the creative exchange. If we fail to communicate anything about design changes to the off-shore team at the end-of the day, they could be going in the wrong direction for a day before we woke up to communicate with them in the morning.

3) Communication

Teams still need to discuss things. Here again, the time barrier is a huge inconvenience. The U.S. team winds up calling India late at night. 8:30 AM in India = 8PM Pacific time = 11PM Eastern time. Having 3 coordinating calls a week to discuss progress, is a lot of overhead when they all happen fairly late in the evening.

While I am still a fan of virtual teams, I have learned that experience, design, and communication escalate non-linearly as the time differences between locations grows. This means managers need to put in even more effort before projects start to mitigate these risks.

Now, I have to go see if my database scripts have turned up yet...

Please post your comments on strategies for managing remote teams.

(The personal contents in this blog do not reflect the opinions, ideas, thoughts, points of view, and any other potential attribution of my current, past, or future employers.)
Copyrighted 2008 by R Wang & Michael Byrne. All rights reserved