SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for November 27th, 2007

Verizon Drops the Open Bomb: Maybe The Old School Is Starting To Get It

Posted by Bob Warfield on November 27, 2007

My hat is off to whomever at Verizon decided to open up their network for “any app any device.”  To date, the industry has had a strangehold on which handsets each carrier offers and which apps are on the handsets.  Tampering with the standard offered by your carrier has been difficult and extremely risky.  The Apple iPhone triggered a storm of controversy when they started “bricking” phones that users tampered with to unlock.  Verizon has done a complete about face relative to the rest of the industry in announcing their new open approach.  Opinions vary on what it means, but it certainly is dramatic.  There is a short list of standards the devices must adhere to, some a little odd (CDMA versus GSM), and phones must be certified in a new lab facility Verizon is building. 

Ben Worthen at the WSJ says it means Verizon’s mobile devices are on their way to becoming as useful as PCs are today.  I don’t know about them being as useful, but an open device with a vibrant ecosystem of apps to choose from can’t help but make mobile devices a whale of a lot more useful.  Various friends in the wireless industry have lamented since they started that the biggest challenge is distribution.  You can build the software, but you can’t get it onto the device without elaborate negotiations with Luddite Carriers.  These are huge Enterprise-class deals with similarly huge and lengthy sales cycles.  One friend had a huge deal fall through with a major carrier simply because they did a reorg just before the deal was about to close.  I’ve seen that happen selling Enterprise software and it is one of the most frustrating things imaginable because you get to start the sales cycle all over again.  Quite simply these carriers were the bottleneck to innovation, and given how monolithic carriers in the US are, we had lagged the rest of the world considerable in mobile infrastructure and innovation.

There is considerable speculation over whether this was all triggered by Google’s Android announcements.  It hardly matters whether it was or it wasn’t, but it’s the sort of thing the blogosphere likes to gossip about.  After watching the round and round between Google, it’s OpenSocial partners, and Facebook, I have to say that Verizon looks brilliant from a PR perspective compared to Facebook.  ZDNet’s Larry Dignan suspects Verizon will have a fair portfolio of 3rd parties apps up in 2008 well before Google even gets their initiative off the ground.  That’s certainly what Verizon has to be aiming for, and given the pent up demand for distribution among wireless startups, there is likely no shortage of such apps ready to go today.

The point is that an open ecosystem can drive growth and opportunity far beyond what a walled garden can in today’s edge economics.  The world has been exploited by too many walled gardens and so it’s leery of granting to much power to perceived gardens, particularly when credible open alternatives are available.  This trend has moved in fits and starts.  The recent web world would like to think they invented the idea, but the truth is that it’s been going on a long time where those later to the party are dropping the Open Bomb to trump earlier arrivals.  It sure worked great for Sun against Apollo, for example in the 80’s and 90’s.  Unix crunched Apollo’s Domain, but has itself been overshadowed by Linux in recent years.

The question now is, when will the next carrier sign up?  There must be considerable gnashing and moaning about the risks.  Most people don’t understand the warped economics of most of these telcos.  In many cases, they offer services to get attention, but they hope against hope that the service won’t be popular because it chews up too many costs to support it.  Some of my in-the-know friends indicate video on phones is more or less in this category for many vendors.  There is some thought that these offerings were intentionally crippled to keep the cost down.  At the same time, text messaging is something of a cash cow, while other areas have been commoditized.  None of this is common across countries, or necessarily even across carriers, and it’s all a moving target.  Opening up to run any device any app is a gutsy play.  What if the devices and apps that turn out to be popular tank profitability?  In fact, there are a lot of unknowns and risks.  It seems likely Verizon is going to pass a lot of costs it used to eat back to customers, for example.  This is all part of the unbundling, but if the economics don’t work out well, it will severely limit the value of the open capability.  Hopefully we can count on competitive dynamics to make such pricing issues short lived.  Om Malik predicts it will open the market up to cheap Chinese handsets, for example.  Details of the exact business model are hazy.  There may be surcharges for apps or bandwidth may be limited or too expensive.

And what other ripples does this create in the pond?  What does it do for Apple, whose iPhone is pretty darned closed, thank you very much?  What of the Google Open Handset (aka Android) initiative?  Will Verizon join up?  Some say it was already rumored before this latest.  Beyond all that, what if everyone’s playbacks are finally updated with the conclusion that it’s good to drop the Open Bomb early in this much more connected world of New Millenium?  Wouldn’t that be a gas.  Much more disruption in many industries followed by new bursts of innovation and lots of entrepreneurial opportunity.  Now that’s what I’m talking about!

Related Articles

Erik Schonfeld discusses Verizon’s “Two Tiered” strategy, which he characterizes as one tier for Verizon’s valued installed base (you can’t sell them your apps) and the new customers who pay for an “open” phone.  I’m not surprised.  This is all part and parcel of the business model issues that surround these devices, as I discuss above.  Verizon can’t very well offer everyone the capability who has an existing contract because they might select an app that causes Verizon to start losing money under that contract.  I still think Verizon has made a positive move and more should follow.

So many see Verizon’s move as being a result of some other company’s strategic genius.  Scott Karp says it’s all a result of a brilliant Apple conspiracy plan.  Every big company I’ve ever seen is the world’s worst conspirator, but maybe.  Just because I’m paranoid does not mean the whole world isn’t out to get me.

Woodrow gets it right by saying:

Whether you question VZ’s motives or not is largely irrelevant. This IS a revolutionary move. And, while I think Verizon is reacting to market conditions; they are doing so far more aggressively and proactively than most have come to expect of BIG TELCO.

Precisely my point.

Daniel Berninger over on GigaOm muses about the impacts on Verizon’s business model of “any app, any device.”  For example, he says that SMS messaging is hugely profitable, but doesn’t that go away in an open world?  Yes it does, and Verizon or others will have to rethink their pricing.  This is precisely why they can’t offer it to existing contracts as I explain above.

Posted in business, strategy, wireless | 7 Comments »

Why Small Software Teams Grow Large And Other Software Development Conundrums

Posted by Bob Warfield on November 27, 2007

Ever since I can remember there is a background noise in the software development community around a relatively small set of topics:

– Are small teams better than big teams?

– Does language matter?

– What’s the best language?

– How do we achieve quality?

– Is software art and talent driven, or is it engineering and process driven?

The list is probably longer, but you get the idea.  Lately I’ve been involved in some back and forth over team sizes.  For the record, I think small talented teams crush big teams with tons of process in terms of productivity and final results.  They build better software in less time.  It’s been a good discussion, but commenters on various threads bring up issues that are important to address.  Let’s see if we can’t tackle a few here.

Chris Winters’ post is a good place to start, as Chris delivers a lot of meat in a very few lines.

Don’t these small team pundits completely ingore the timeframe?

As Carmack said, “a team of 3 focused and creative people can accomplish almost anything” — given sufficient time. But time is the knob that many (most?) projects have little control over. Everybody has competitors, and everything needs to get out yesterday.

This is truly Mythical Man Month territory.  You can deliver a project sooner with more than 3 developers, but I have serious doubts about delivering a core module with more than 10.  The question is whether what you are building is amenable to being broken down into what are essentially very separate projects.  Sometimes this is possible, more often it isn’t.  To make it possible will require some architectural investment to keep the modules separate, and that investment is serialized into the schedule.

A much more effective knob to twiddle when it comes to time to market is scope.  Cut scope.  Cut it early and cut it again if the project is drifting off schedule.  It is amazing how much scope can really be done away with and still have a release that completely satisfies commercial needs and makes customers happy.  It is a mistake to go for the many-year feature abundanzas that result in products like our friends in Redmond like to ship once every 5 years.

Does “small team” include QA?  People to gather requirements?  People to write documentation?

Great question!  First, on the issue of QA, I have never found a point of diminishing returns, and I have had the luxury of spending a LOT of money on QA during my Borland days.  Simply put, it is extremely difficult to find all the bugs.  No matter how many we could find in a week with a huge team of testers, a small core team of developers was able to keep up.  We started with a ratio of 1 QA per developer and added more QA on top of that as we moved towards shipment.  Those days are probably gone, but boy did it ever help. 

We got a lot of mileage over mobilizing the company and customers to assist.  We paid bug bounties to these folks based on severity of bug, and I know of at least one case where a very talented SE paid for a kitchen remodel with the funds.  OTOH, I had friends working on Microsoft Windows XP where much larger developer teams were involved, and even more humongous QA teams.  According to one friend, they completely deleted the entire bug database and started over again multiple times during the project because the developers simply couldn’t keep up.

As a final thought on this, the number of resources you can bring to bear outside the core developers is a function of the communication load they put on the developers.  Communicating via a bug tracking system is pretty efficient, hence lots of QA didn’t bring down the team.  Having a doc or QA person want to camp out so the developer can educate them is not going to scale.

Isn’t there a huge distinction between creating something and maintaining/improving it?

No, not necessarily.  If your view of improving something is to canvas the user base for every possible feature, build a giant laundry list, and build all of that, you’re going to find it’s very daunting.  But you’re also going to find you quickly defocus the conceptual integrity of your product and wind up with bloatware that does not make your customers happy.  The art of great software is in understanding what’s important to the user experience versus what is merely urgent.  A small team can keep a product fresh and current for years if they’re good at this because they don’t waste time on a load of features that clog things up.

Exceptions?  Beware the things that require tons of code yet qualify as only 1 more feature on the checklist.  Platforms are the arch example of that.  Supporting many printers and display adapters was the old school.  Supporting many databases or app servers is more recent.  It’s not worth it and it is a huge sink on resources.

Aren’t all the great small team examples tools?

Linux, Delphi, and Quattro Pro are described by Chris as “generic tools built without regard for any specific business logic.”  There are two ways to think about this.  Chris takes the path that says the example is irrelevant because most software isn’t that way.  I take the path of saying that the example is spot on because all software should become a language if done right.  The benefit?  Your small team is enormously more productive as are your customers if you can actually make the language something they can grasp and use.  There is a reason these small teams built languages (though I’m not sure I view Linux as a tool/language).  In fact, Quattro Pro had no less than 18 interpreters buried in the guts.  Very few of them were surfaced for end users, most were there to make the code simpler and the product more powerful.

Do we know what we’re building?

Chris hints on another big problem when he says:

And doing all that for non-trivial businesses, with a small team, no matter what language, is a tough job. (Not even mentioning figuring out what it is you’re supposed to build.) In a short amount of time? Approaching impossible.

The one thing that will sink a project faster than too many cooks with not enough talent is poor requirements at the outset.  If you truly don’t know what you’re building, you’re doomed.  You need to see pretty clearly what it is before the first line of code is written.  If you must build a prototype to get there, consider it time and money well spent.

By the way, creating a DSL for your domain is a way of creating a formal specification.  It takes rigor to create a language.  Hand waving won’t get you very far.  Also note that a giant laundry list of use cases and feature requests is not a specification.  It’s a wish list.  You need to understand the commercial dynamics of what really matters to customers, why it matters, and have a pretty good sketch of how you’ll solve their problem.

Don’t kid yourself that a giant team running around gathering requirements and hacking out use cases in monolithic modules is building software, business or otherwise.  It’s creating an unmaintainable mess that makes nobody but the IT guys that assembled that laundry list happy.  Certainly the business uses who it lands on are going to find it isn’t what they thought they were getting and it is almost impossible to change it into what they wanted.

So then why do small teams grow large?

This is my own editorial, but I’m surprised it isn’t talked about more.  We’ve all seen teams start small and grow large as a product succeeds.  Why does this happen?  The prevailing wisdom seems to be that as you gain customers, their demands for new functionality outstrip what the small team could provide.  I don’t believe it.  I’ve looked at a lot of software releases, and by release 3 or 4, it’s all too easy to get caught up delivering much sound and fury signifying nothing.  Did that release 3 or 4 really turn out that much more functionality than 1 or 2?  Was it really revolutionary?  Were the features all of the same caliber as the original?

No, I don’t think so.

Another source is failed negotiations between VP’s of Engineering and CEO’s.  Most CEO’s do not understand creating software.  They come from fields like Sales and Marketing where throwing dollars and bodies at problems can make a difference.  So they want their VP of Engineering to do the same.  They don’t want to hear the team is running flat out and can’t produce more.  They want what they want when they want it, and they’ll write the check to make it happen.  I have not personally run afoul of this (I am stubborn about agreeing to do something I know will fail), but I have heard of it.  This is not the big issue, though.

In my experience managing multiple release cycles for something like 50 products, team growth almost always boils down to aspirations and career growth.  People get tired of working on the same code base.  They get tired of working on the boring parts of the code base.  They want new challenges.  They want career growth.  They want to be architects and managers.  Who can blame them?  It’s human to want these things.

Pretty soon, a person who was a senior developer is an architect or a manager.  We carve some subsystem off and hand it over to them.  Or, we hire someone incredibly junior to be in charge of some unimportant code that the senior guys want nothing more to do with.  A fiefdom is born and the big team is on it’s way.  This is a mistake!

We are better off to create entirely new products as a path for career development.  If we can’t justify a product, or worse, can’t justify giving a person a product, then we need to be honest about that.  You may lose the person as they seek opportunity elsewhere, but you may also need to get some new blood into your small team.

This points up something to look for in your hiring practices.  Beware too much naked ambition among developers.  The guys that push for promotion every year can be awesome, but they will be high maintenance, and they will try to push you into doing something that’s bad for the team and perhaps even bad for themselves.  Beware especially the talented developer who wants to move into management because they want to make the decisions on architecture.  The developers who are in love with the act of creation and who have great chemistry with their coworkers are the gems.  They will not push you for much more than clear and exciting direction on where to take the product next.  Don’t exploit these guys either.  Reward the heck out of them.  After all, it doesn’t take too many to work miracles.  Make sure they’re happy, whatever it takes.

Give me a few guys like that who are really good and there isn’t any piece of software I can’t get built faster and better than the big team.  We’ll also keep that software vigorous and cutting edge for years too, and we’ll run circles around the competition.

Posted in software development, strategy | 7 Comments »

Interview With Lucid Era’s Ken Rudin, Part 2

Posted by Bob Warfield on November 27, 2007

This is part 2 of my interview with LucidEra CEO Ken Rudin.  If you missed Part 1, be sure to go back and check it out!  As always in these interviews, my remarks are parenthetical, any good ideas are those of Ken Rudin, and any foolishness is my responsibility alone.

What was the fundraising like?  What do VC’s look for in a SaaS business plan?

Ken:  It’s been interesting.  I feel very fortunate about what we raised, the valuations, and the great Board Team.  The A round went quickly: 7 weeks from first meeting to close.  It went quickly not because of the idea and team.  Deals go slowly because VC’ s want to think and talk.  Nobody needed to think about our deal.  The majority hated it.  A few loved it and went for it. 

When we presented it was 3 guys and 19 PowerPoint slides.  No demo.  Most people said BI is complex, it involves integration which is bad for on-demand, and it’s heavily customized.  But I knew better.  As a consultant at Emergence, I could see people kept reinventing the wheel.  They didn’t all need completely unique solutions.  The phrasing was different, but the essence was the same.   The world really was smaller than people thought.  And it worked.  We weren’t out to meet the needs of 100%, but we can do it for 80%.

Traditional BI is a tool that says we can do anything, but that’s a disadvantage.  It’s like managing a nuclear reactor because all the code is custom.  But we can keep identical schemas and use metadata to make it custom enough.

Bob:  (You never know how VC’s will react to a deal.  It only takes a couple to bite.  My last VC funded deal involved talking to 15 VC’s and the last 2 funded the deal.  The other 13 passed.  These days, there’s a lot of talk as well about going to VC’s later in the cycle, after a version 1.0 product has been built and a few customers are using it in Beta.  Angels often fund the first stage.  I’ve had a couple of VC’s indicate that they no longer fund a  slide show.  Lucid Era is proof that you can buck that trend if you get your idea in front of the right audience.)

What were your biggest fears about LucidEra, and how did they turn out?

Ken:  One of my biggest fears was that we had to sell over the phone.  We couldn’t afford travel and 6 month sales cycles.  This was unproven for me.  A lot of the VC’s wouldn’t believe it either.  They thought we’d need a consultative sale.  But we had a prebuilt solution, not a tool.  It’s finished.  I can show it and they can take or leave it very cheaply and quickly.  Even our 2 largest customers we saw at a trade show at our booth, but otherwise we never met face to face.

What really surprised you as you got more into Lucid Era that you hadn’t anticipated?

Ken:  The biggest surprise we’ve seen just in the last 6 weeks is how fast the big companies have jumped in.  Our plan was mid-market focused.  We didn’t even try to market to our bigger customers, they came to us at a trade show and we closed them within 30 days.

Another surprise was channels.  We’re working with partners.  It took a while for us to figure out what type would work for us.  Traditional SI’s have no interest, which was a negative surprise.  Traditional SI’s want to bill a lot of hours for custom work.  We stumbled across some SI’s who are purely SaaS focused and discovered that SaaS has been disruptive to SI’s just as it has software vendors.  Pure plays are coming on strong and have figured out how to create high margin business around SaaS.  They may teach or use the tool for you, but they don’t have to set it up.  They help do it faster by making it multiple choice and prescriptive.  More importantly they help with best practices.  Which choices should I take for my business?  This has a lot more IP, and isn’t just competing with commodity offshore rates for code slinging.  It also generates repeat business.  More management consulting.  Sales Effectiveness optimization.  Now it becomes an annual service and not just a project.

Bob: (This sentiment has been echoed by every SaaS company I’ve talked to.  The traditional SI’s largely haven’t found their footing yet in the SaaS world.  They will often speak positively about it so as not to be perceived as critical of a major trend, but they don’t know how to actually engage their businesses with it.)

Do you think SaaS is an inevitable bridge that every ISV has to cross in some form or fashion?

Ken:  No.  Even if it was, that would be a real challenge for them.  There are some that will do just fine staying where they are.   Not many, but there are some.  The majority will have to deal with it.  Just because cars came doesn’t mean there are no horses, they are still around.  There’s just a lot less need.  On-demand dramatically reduces the need for conventional on-premises software. 

Bob:  Where are the likely survivors?

Ken:  There are some government mandated things involving military or top secret.

Bob:  It’s pretty hard for companies to embrace both models.

Ken:  Mixed companies have a civil war inside.  This is true for SI’s too.  But the mixed company may not really be behind SaaS.  They just think it is the thing to do.  It’s fashionable.

Any other advice for those who would start a SaaS business?

Ken:  I think for me, don’t just think, rethink.  What I mean is SaaS is not taking an existing enterprise software application and delivering it as SaaS.  All you’ve done is change delivery.  Rethink the whole purpose of the application.  We redesigned what BI means.  It’s not a tool, it’s a solution.  People don’t want drills, they want holes.

Who are the SaaS companies you look up to?

Ken:  Salesforce.com is the poster child, and I have personal background there as well.  I also have a lot of connections with NetSuite.  I spent a lot of time on their advisory board.  I remember discussing churn rates and hardware and so on that they won’t talk about outside.  I look up to them.  They have done a phenomenal job.  NetSuite is SAP On-demand.  Salaesforce is best of breed CRM on demand.

What are your thoughts about Salesforce’s Force?

Ken:  We’re big fans of it.  We believe in opening the platform and you’ll see us do it with our own platform.  They have great buzz and some successes, but they have a lot of work ahead.  It is still early stage. 

One of the things I think they’ll run into is that as it becomes more flexible with Apex code, they open a Pandora’s Box.  No-software is no longer true.  Someone can write code that doesn’t work, and it isn’t Salesforce’s fault.  The brand delivers a certain promise, but 3rd party apps can be challenging.  It’s not simple anymore.

Are they encouraging too much customization?  Is it Siebel again?  If so, there will be lawsuits between customers, SI’s and Salesforce when customization fails.  It’s a risk, not a prediction.  I’m not saying this is bound to happen, just that it could if the situation isn’t managed very carefully.

What are your thoughts on being in the BI market where all the significant traditional players have been bought?

Ken:  It creates a great opportunity for us.  The last big independent got bought.  All the tall trees in the forest are cut down, so the undergrowth has a chance.  Those guys will not innovate for years, they’ll be integrating not innovating.  All the new innovation will come from smaller players like us.

We also said, wow, if major companies are buying these guys for such high prices, there is probably some real value in BI.  Makes customers start thinking about what their BI strategy should be.

Bob:  (It’s an interesting situation, where the big pure plays all got bought by even bigger companies.  Oracle got Hyperion, SAP got Business Objects, and recently IBM got Cognos.  Having watched these sorts of acquisitions for years, I don’t have any problem believing Ken’s view that we won’t see much innovation in BI from them for a long long time.  Integration is a difficult process, and often the best people choose to move on, or at least become very distracted.)

Do you think we’ll see something similar in all the other perpetual markets?  What does it mean for SaaS in general?

Ken:  For any segment that has large independents, we will see something similar.  Any time there are too many small players there will be consolidation.  Eventually, I think we’ll see that in the SaaS SI world to get critical mass.

It’s the end of the current cycle.  The next generation steps up.  It happened with CRM.  SFDC took over and the rest were acquired.  It’s happening with BI.  These shifts don’t take away the need from customers, the just change the players.

Bob:  (I agree wholeheartedly that we’re at the end of the cycle for on-premises software.  It’s very hard to get a new on-premises enterprise company funded no matter what the idea may be.  I just had lunch with someone with a small private on-premises company and they’re having a tough time.  They know they have to get a SaaS offering going.)

Can the big guys get into SaaS successfully?  SAP with ByDesign?  Oracle now talking more about it?

Ken:  It’s like changing your DNA.  I wouldn’t say it’s impossible, but it is as close as you can imagine.  I call it the “battle within” or the “civil war.”  All the divisions are involved, not just sales.  Marketing, Engineering, Finance, everybody hates it.  Marketing hates it because you’re marketing against your own products.  SaaS sells on simpler.  Simpler than what?  You’re slamming your cash cow.  You can’t say anything interesting without damaging one product or the other.

Bob:  (Again, this is a sentiment echoed almost everywhere I’ve visited. The best approach to transition is to try to isolate some areas that can be pure SaaS with no in-house on-premises competitor.  New products and verticals work well.  I call this the “protected game preserve” strategy and I’ve written about it before.)

Next Installment

In our next installment, we’ll get Ken’s perspectives on the sales process as well as the scoop on Lucid Era’s innovative database architecture.  Stay tuned by getting on the data feed or e-mailing list for the blog.  Just check out the options in the little box below my picture at top of page.
 

Posted in business, saas, strategy | 2 Comments »