By Michael Woloszynowicz

By Michael Woloszynowicz

Thursday, December 9, 2010

Resource Based View of the Web 2.0 Firm

In an industry characterized by rapid change, traditional strategic planning falls flat on its head. It's a waste to develop long-term strategies for an agile web startup when its competitive landscape and consumer preferences will look completely different in a matter of months. The strategic imperative should therefore be to look at competitive advantage, and more specifically, looking at the company's resources and determining how to best leverage those resources and further develop them.

There is a great deal of misunderstanding as to what constitutes a resource that confers competitive advantage. For example, many companies advertise that their employees are their greatest resource, and while it's true that employees are paramount to the success of a firm, they are not a resource from a competitive advantage standpoint as will soon become clear. Since there are many great articles on the Resource Based View of the Firm (see Competing on Resources by David Collis), I intend to focus on resources in the context of a Web 2.0 company.

Before we delve into specific resources let's recap what constitutes a resource from a competitive advantage standpoint. First off, in order to establish a competitive advantage the resource must be scarce and relevant to your company's key success factors. Clearly if the resource is something that everyone else has, or it doesn't matter in your industry or market, you won't gain any advantage with it. While establishing competitive advantage is important, what we are really looking for is a resource that sustains that advantage. In order to achieve this the resource must possess the following characteristics:
  • Durability, the resource doesn't depreciate rapidly
  • Appropriability, you capture the value from the resource
  • Substitutability, there are no readily available substitutes for the resource
  • Superiority, is it really better?
  • Non-transferable, it cannot easily be bought by a competitor
  • Inimitable, can't easily be copied by your competitors
Based on the above characteristics it is clear that employees are not a resource since they can be bought by competitors. We've seen a great deal of this recently with Facebook poaching Google employees at a rapid rate. An exception to this could be someone like Steve Jobs as he's not likely to move to another firm; however, his durability is still questionable.

Now that we've defined the characteristics let's apply them to Web 2.0 companies and look at examples of resources that can provide you with a sustainable competitive advantage. The below list is meant to serve as a starting point and you will have to look closely at your business to determine your own resources.

A patent or complex algorithm
Since a patent is owned by you and is protected from competitive use, it meets the majority of the above characteristics provided the patent covers a truly important technology. As we know, patent trolls have created entire businesses around holding patents and suing those that infringe on them. The one point of failure is durability as patents do expire, albeit over a long period of time. More worrisome however is the rapid rate of innovation that may render the underlying technology obsolete. A complex algorithm is similar to a patent, with the best example being Google's PageRank algorithm which others are unable to copy due to its size and evolution over time, resulting in what is known as path dependency.

A large user base or market share
If your application exhibits a high degree of network effects and you have a large base of users (e.g. Twitter or Facebook), competitors would be hard pressed to duplicate this easily and recreate the value of your system. Of course we know that this doesn't guarantee perpetual success as MySpace and Digg both had large user bases but are now struggling, so it is still necessary to provide a product that people like to use. 

A high degree of third-party integration
If your application offers an API that is utilized by a large number of established third-parties the value of your product drastically increases and it makes it more difficult for competitors to match your value proposition. Of course users must be using your product via the third-party applications for this to be valuable. With this resource you do however have to evaluate appropriability to see who really captures the value of the API, you or the third-party. If the third-party is the primary beneficiary or is the one with the majority of the power, then the API doesn't serve as a sustainable resource. The Facebook like button is an excellent example of this, as is the Apple App Store. 

A superior path to market
If you have a large number of users across a variety of services, it allows you to easily promote or roll out additional offerings to a large user base in a low cost and rapid manner. Once again Google is quite good at this with the obvious exception of the Google Buzz launch which took this resource a step too far. It is critical that you control this channel so that your new offerings stand out and are differentiated, otherwise you coulld reproduce the resource simply by using the Facebook platform or the Apple App Store. Facebook has also demonstrated this internally as their introduction of Places and Deals has been extremely successful by allowing them to rapidly surpassed the user base of Foursquare. 

Data
Similar to algorithms and patents, data is the new currency. Although Google and Facebook don't charge their users, the users pay them by submitting information which they in turn convert into revenue. Amassing huge quantities of valuable data on user habits, preferences and social circle is something that a competitor cannot easily copy as it is acquired over time. Once again durability is a strong factor as old data is typically less valuable than new data so a company must continually provide value to end users so they may collecting fresh information. The nature of the data will of course dictate its value as a resource.

A strong brand name
This is one of the most universal resources that companies have. A strong brand such as Oracle, IBM, or Salesforce provide a tremendous amount of value that others cannot easily copy, regardless of their marketing budget. The bulk of Salesforce's success is due to the fact that their name is synonymous with CRM's and that they have become the go to source for small and medium sizes firms. This however is also one of the hardest resources to acquire as it takes time to develop brand recognition and a positive reputation. 

To identify the resources in your own business begin with the key success factors for your market and compare them with your strengths and weaknesses. You should appraise these strengths and weaknesses based on their importance to your market, how they compare to your competitors (benchmarking), and finally putting your strengths through the above qualification test. If your weaknesses prove important to your market then you must manage those weaknesses by converting them into strengths. An example of this is explaining that a lack of functionality is intentional as it keeps the product user friendly, think 37 Signals. It is also crucial to nurture your resource and keep them up to date so you must have a system in place that continually upgrades existing resources as well as developing new ones.
Although the above resources result in a competitive advantage, the rate of innovation seen over the last decade is unprecedented. Executives and strategist must therefore continually survey their environment and see how they can utilize their valuable resources to offer new and innovative solutions. After all, a resource only has value if you utilize it to its fullest. 

If you liked this post please follow me on Twitter for more.

Saturday, November 27, 2010

3 Groups You Must Design Your Application For... or Else

I recently completed the task of redesigning and implementing a large component in our web-based application. In doing so I have learned that you have to design your application for three groups of users and have an intimate knowledge of what creates value to each one. Before I go into detail about these three groups I'd like to give you a little bit of background on how I got to this point without going into the details of the implementation.

My goal was to create a more flexible, portable, modern, and full featured tool than the clunky third-party Java Applet we were using to date. After 6 months of back-end and front-end coding (see Dojo Lessons for some front-end programming tips I learned in the process) I produced what I and my co-workers saw as a tremendous advancement from what we had. The new tool had all the things I set out to achieve but the end-user response was lukewarm at best. How could this be I wondered, can't people see that this tool vastly better than what they had before? The navigation was improved, the amount of useful options was expanded, it was more reliable, and most importantly it allowed us to implement some of the functionality that these very customers have been asking us for, but we were unable to add due to the restrictions imposed by the existing tool. After some feedback from our Beta version we discovered that most of the issues arose from one aspect of the tool which users found more cumbersome and time-consuming than what they had grown accustomed to. While 95% of the functionality was improved, to the end-user the remaining 5% superseded all of this and rendered our new tool a dud. Our end users didn't care about the added functionality, the fact that it was AJAX based vs. Java based, or the fact that we could now implement their other desired features. The reason is that this small component consumed 95% of their use and time, so no matter how great everything else was, if it wasn't as easy as before we couldn't convince users to use it. In the interest of keeping our customers happy I proposed a second alternative which would save time but still maintain portability. We were sure this new version would resolve any objections. Sure enough it wasn't, it was still a bit more time consuming than what was offered by the basic existing applet so users still complained. Finally I accepted the fact that we had to add a third option using a new Java Applet that would restore the previous functionality while still giving us all of the advantages of our new tool. We now have three options for completing the users crucial task, each with varying levels of portability but without sacrificing our initial goals.

Now on to the primary point of this post. When I set out in designing this tool I had considered the existence of the three groups but underestimated the importance of each one. First off we wanted to design for the end-users' managers as they are the ones we sell the software to. These managers wanted reliability and improved performance that would result in a better consumer facing experience. We then designed for the end-user by trying to design an interface that was similar to tools they use on a daily basis and provide some much needed functionality enhancements in an easy to use package. Finally, we designed for ourselves by keeping future expansion and value enhancing features in mind. We knew from the start that the one element of the new tool was slightly less efficient than it was before but we also knew that this was the way most companies did it, and that the other improvements would surely convince people to overlook this. This thinking was correct in the context of new clients who loved the new tool, but as we know, people are not amenable to change and existing end-users complained furiously. What we did right in this process was slowly roll out the new tool, all while providing access to the old one, while actively soliciting feedback. Although the response we got was not what we wanted to hear, it prevented us from loosing a good chunk of our clients and allowed us to improve the user experience.

The lesson therefore is not to underestimate the power of the end-user and always find out what the most crucial aspects of your application are. Remember that what is seen as a value driver to you or to a purchasing manager or exec, is not always the case for an end-user. The biggest source of value for the end-user is having your software help them accomplish their task quickly and easily, and if it fails to do so they will complain to their managers, complain to their co-workers, and go from advocates to saboteurs in an instant. One exception to this is enterprise software where initiatives are often assigned in a top down manner with end-users having little say, hence the dismal usability of many ERP systems. Those however that target small to medium size businesses with a subscription based service must remember to identify the sources of value for every class of user and incorporate them into your designs. Design for the buyer, the user, and yourself, be proactive in soliciting continuous feedback, and remember that little changes can make a world of difference.

If you liked this post please follow me on Twitter for more.

Sunday, November 21, 2010

Web 2.0 Businesses, a Bubble, a Boom, or Just Crazy?

In the recent conversation between John Doerr and Fred Wilson at the Web 2.0 Summit, the discussion of whether we are on the verge of a new bubble in the internet company investment environment came up. The argument is that time tested standards on valuations no longer apply and even small firms with little more than an idea are getting massive valuations. This conversation has prompted me to think about whether we are in a bubble or boom, what the effects of the rising valuations are, and whether we will see a repeat of the dot com bubble a decade ago?

The Tech Crunch page that featured a video of this discussion had an astute comment from one of the readers who noted the one of the key differences between today and a decade ago is that today we are dealing with private companies whereas in 2000 we were dealing with public firms. Let's begin by carrying on this argument and discussing the differences between these two firm types:
  • Since the firms are private, any damage is contained to a smaller group of investors such as the VC firms and fund participants, angel investors, founders, and employees holding shares or options
  • Private companies do not disclose financials so we can't tell just how inflated the valuations really are
  • Valuations are determined through negotiations with a small group of players whereas public share prices are determined by a large pool of investors in an open market
  • The liquidity of private shares is much lower (although increasing for popular companies) than it is for public shares so we won't see any rapid trading
  • Because of a number of reasons, including high costs, signaling, etc. public firms tend not to issue equity frequently, while private firms often undergo several series of funding so valuation has a profound impact at every financing round
With the above differences it is clear that a bubble would develop in a somewhat different manner than it did a decade ago. The origins of the bubble lie within the VC firms which are seeing the popularity of their funds rising as a result of low interest rates and an improving economy. After the significant reduction in VC investment in 2008 and 2009, they are looking to increase the size of their portfolios and searching for runaway hits in hot sectors like mobile, geolocation, cloud computing, etc. Over the last two years we've seen many announce the death of venture capital as IPO exits were more or less nonexistent. Although IPO activity is still fairly stagnant for a multitude of reasons, VC's are now driven by the prospect of private sale exits. With large players such as Google, Apple and Microsoft looking to expand horizontally beyond their core business, and with an unprecedented amount of cash on hand, VC's are hoping that acquisitions will provide a way out. We're already seeing quite a bit of buyout offers with a potential Google-Gowalla deal looking to be one of the bigger ones this year. Another worry is that we're seeing the liquidity of private shares increasing in the secondary markets which further increases valuations on a wider level. In addition to rising competition between top-tier VC firms, they are also facing competition from a growing number of "super angels" that have become popular thanks to their smaller ownership requirements and lower appetite for go big or go home strategies. Due to their resource dependence, venture capital firms target high potential businesses that can offer 10x and above returns, and as a result they tend to invest large sums of money to ramp up development and increase growth rates. This is not necessarily healthy as firms that service unknown markets should operate in a lean manner and focus on learning the market and what a winning model is rather than questing for rapid growth on an unproven business model. This is precisely the approach that Y Combinator favors as they prefer investing a small amount of capital in startups and providing advice and guidance to help firms hone in on a viable model. The Y Combinator strategy is inline with the tenants of the lean startup, and makes sense now more than ever as startup costs have been driven down drastically thanks to a multitude of open source technologies and cloud computing services. The other problem with the increased flow of VC money is that it reduces the motivation for firms to turn cash-flow positive by monetizing their efforts quickly, and instead encourages them to focus on growing their user bases. 

This leads to one of the parallels to the dot com bubble and that is that we're valuing companies that are in most cases not profitable. The valuations are therefore based on expected payoff from a large and rapidly growing user base. Further increasing risk is the fact that in many cases the markets that these firms operate in are unproven and only developing. Fourquare is a perfect example of this, as it doesn't have a revenue model and operates in a market that is being flooded with competitors, all of whom are trying to find a sustainable business model in that market. Given a lack of cash flows and huge risks to those cash flows, financial models are discarded and replaced with euphoria and optimism. That's not to say that all large investments in businesses with unproven business models are silly. In some cases they are justifiable. In fact, if we didn't have aggressive VC's looking for the next big thing, we wouldn't have many of the free services we love today. What I am suggesting is that we simply ask ourselves whether a company like Twitter really needs to have 300 employees at its current stage, and whether a small early stage startup really needs a cash infusion of several million? Can we accomplish the same result with a little more restraint and a greater focus on fundamentals? 

The problem is that there is no easy way to cool the market down. Even if VC's were to collude in an effort to drive down the prices of new deals, the negative signal this sends would also reduce the value of their existing holdings. Whether we're dealing with a bubble or a boom, the access to capital is great for startups and things will continue to operate well, provided the flow of capital continues. If however we find ourselves in the midst of a double dip recession, those firms that have learned to run lean and generate positive cash flows will emerge unscathed, while the exuberant bunch may find themselves starved for capital. A positive note is that the public markets are far less frothy. Public tech companies are trading at far more reasonable levels than we saw at the peak of the market near the end of 2007. Companies like Google and Yahoo were trading at trailing PE's of 53 and 49 respectively at the end of 2007 and now trade at more reasonable levels of 24 and 22 respectively. Regardless of the outcome, the greater population can take solace in the fact that any fallout will be contained to a small group of players, and thanks to the growing tide of super angels, we'll be left with lots of tech startups that chose control over optimism. 

If you liked this post please follow me on Twitter for more

Saturday, November 13, 2010

The Dojo Toolkit - Lessons from the Trenches

Having spent the last few months working heavily with the Dojo toolkit to develop a large RIA document management tool I thought I'd share some of the lessons that I learned along the way. For those who haven't heard of Dojo, it is a JavaScript based RIA toolkit similar in nature to JQuery and Open Laszlo.

To get started let's discuss why I chose to use Dojo instead of the more popular JQuery toolkit. The primary motivators for me were as follows:
  • Dojo's syntax is very easy to read, write, and understand
  • Dojo has a fantastic collection of widgets that cover 90% of your needs
  • Dojo's class system turns JavaScript into a real programming language (more on this later)
  • Dojo does pretty much everything that JQuery does
  • On demand package loading means you can load what you need, when you need it
  • Comes with built in developer tools
To make this an objective post, there are a few downsides to Dojo that I've come accross:
  • It's not as popular as JQuery so it's harder to find new hires that already know it
  • Dojo is not as mature JQuery so documentation and code samples are not as easy to come by
  • Dojo is significantly larger than JQuery so it's easy to learn but hard to master
  • Dojo can become slow when writing a large application with lots of widgets or consuming a great deal of data (more on this later)
If you've made it to this point you're either already a Dojo coder or you're intrigued by its possibilities. If you are considering trying Dojo, my personal opinion is that you should. Having used both JQuery and Dojo, Dojo wins hands down as the better toolkit, a sentiment that is shared by many of co-workers. This post is not intended to be a rigorous tutorial on Dojo - there are many great books on this such as Dojo: The Definitive Guide - what I intend to do is give you some high level tips that books typically omit.

Tip 1: Use the Dojo class system
Dojo's class system is fantastic. It allows you to write proper Object Oriented code that you can nicely organize in a package structure. No matter how small a component you may be writing you should always encapsulate it in a Dojo class so that you can later extend it and load it on demand using Dojo's package loader. For those here that are back-end programmers I don't think I have to preach about the benefits of OO programming. Dojo provides it so just use it, it will only take you 30 seconds longer to wrap your code in a class. Dojo does allow for multiple inheritance and I encourage you to use it, but for the sake of your co-workers, document method uses of methods that are defined in parent classes. Unlike back-end languages it's difficult to trace the source of methods that originate up a complex inheritance chain.

Tip 2: Internationalize from the start
Dojo provides a great set of tools for internationalization (i18n). Even if you have no near term plan of supporting multiple languages, it's wise to house all of your copy into one or more master documents should the need for i18n arise. Although i18n is usually tedious, the tools provided by Dojo make it as easy as it gets. Doing this will only add a extra hour or two for each month of work.

Tip 3: REST
Dojo's AJAX package and widgets are heavily geared towards RESTful web-services which is both good and bad. The downside is that if you are trying to reuse non-REST back-end code, you may have to modify the behavior of some of the widget data stores (this is neither fun nor easy). The upside is that the support provided for RESTful web-services is outstanding right out of the box. If you're starting out with a new application I highly recommend you write your application as a RESTful API and build your front-end on top of that API (e.g. Twitter) using Dojo. This will not only make your front-end code clean but you'll simultaneously be developing a platform, not just an application.

Tip 4: Events, events, and more events
Dojo's architecture is heavily event driven, both with standard events and pub/sub style syndication. While event handling used to be tedious affair, it can now be handled with ease using built in tools such as dojo.connect [connect to an event] and dojo.hitch [bind a method call to a specific context]. I therefore highly recommend designing your objects and applications around an events based architecture. If you're tying multiple classes together, rather than passing object or method pointers across these classes, simply trigger events and have sibling or consuming classes connect to them. This allows your components to maintain a loose coupling resulting in a more robust application. Carefully decide when to use standard events vs. pub/sub as there are noticeable differences in performance between these two. If you really do need to broadcast an event to a wide audience where establishing individual connections would be too onerous, go for pub/sub, otherwise stick with standard events.

Tip 5: Go to the source
As I've mentioned, the documentation for Dojo is good but not great. The Dojo team does their best to maintain an up-to-date API and Reference Guide, also Dojocampus provides lots of examples but often times you just can't find what you're looking for. I've found that the best reference guide for Dojo is the source code itself. It is well documented but can be tricky to read. As described above, Dojo is heavily events based so when going over the source it's important to understand what events are being are being thrown and which objects are attached to those events. Debugging Dojo is not easy from the outset but once you learn its structure, it's quite consistent across its various components (with a few exceptions). Spend a day or two going through the source as this will pay off greatly in the long run. As an added bonus, Dojo was written by lots of great programmers, reading their code just might make you a better programmer. Another great tool for discovering the capabilities of an object is dojo.debug(). Simply pass your dojo object into the debug function and inspect it using Firebug's DOM inspector. This will give you lots of details about the objects contents in a runtime environment.

Tip 6: Don't settle
Dojo is designed to have its components extended to suit your specific needs. It will not cover 100% of your use cases so extending functionality will quickly become a reality. Whatever you do, don't change the Dojo source, extending a class may take a bit longer but it ensures that when you migrate to a new version your application doesn't break down completely. When extending a Dojo class, try to use this.inherited(arguments) [call the parent classes method with all the arguments] whenever possible so as to minimize the amount of code you have to copy and paste from the Dojo method you are overwriting. As mentioned Dojo can become slow if your application becomes large and you are using a number of widgets. To overcome this you will have to extend certain Dojo widgets and create optimized versions of methods so that they don't fire any unneeded events, especially if you are performing bulk operations. If you are not using any widgets on your page then you will not encounter any performance issues.

Tip 7: Don't rush it
As programmers we have a tendency to read the first 20 pages of a technical book then hit the ground running, learning as we go. Dojo is no different than any other language, you have to use it to become good at it but I would highly recommend at least skimming an entire book on Dojo before taking on a larger project. I made the mistake of getting half way through the book, then finishing the rest two months down the road only to realize that Dojo has already provided solutions to problems I was running into.

Tip 8: Think like a real programmer
For the longest time, JavaScript was seen as a lousy language and if you were a JS programmer you weren't a real programmer. Dojo changes all this by bringing in a wide array of tools that back-end programmers have utilized for years. The chaos is gone so take the time to design your class and event structures and take pride in your code, just as you would with any other language.

If you have any other Dojo tips that you've discovered while using it, please share them in the comments.

If you liked this post please follow me on Twitter for more.

Sunday, November 7, 2010

Startups, Where is your Story?

While attending the Web 2.0 Expo in New York near the end of September I had the pleasure of visiting the startup showcase. The showcase was an exhibition of various startups that were then judged by Tim O'Reilly and Fred Wilson. Overall there were some interesting ideas, my gripe however was with the delivery of those ideas. The three companies that were invited to present in front of a wide audience had ideas with mass market potential and an ideal opportunity to promote their business to a room full of bloggers, media, and tech enthusiasts. When faced with such an opportunity I expected a well refined and compelling presentation, but instead they felt relatively flat and uninspiring.

Although delivery in two of the three cases could use a little improvement, it was the content that was lacking. Rather than giving a dry and clinical rundown of your product, tell me a story, let my imagination wander and relate to your product on a more personal level. Put me in the shoes of a person faced with the problem you are trying to solve, make their problem my problem. Now that I see the situation that your target consumer is in, pitch your solution for that specific context. With a rich and compelling story you've told me two key components of any good startup pitch, the problem and the solution, and you've done so in a way that makes me believe the problem exists. With this in the bag you can proceed to two other components which are traction and market size. Whose problems have you solved so far, how many customers do you have, and how many others have this problem. This is a great opportunity for a testimonial or interesting example of your product being used in the real world (ideally the story you just told was a true story and you can tie it back).

Let's go through a concrete example using one of the companies at the startup showcase. I will use hour.ly as their concept is straightforward and easy to understand. The premise behind the startup is a job board for part-time and temp employees. The actual details of my example are fabricated but what I intend to do is offer a quick presentation on the company's concept.

"Good evening, my name is so and so and this is my partner so and so, [in an actual vc pitch you would give some background on yourselves here], and we'd like to talk to you about a product that we're very excited about called hour.ly. Let's start off by talking about Jane (show a picture of Jane). Until two years ago Jane was making a good living as an administrative assistant at a large marketing firm. Shortly thereafter she found herself in the same place as millions of other Americans, struggling to find work in an economy plagued by high unemployment. On the other hand we have John (show a picture of John), a business executive at a mid-sized software company. John is seeing demand picking up slightly but sales of his product are still variable and fear of a double-dip recession are preventing him from hiring anymore full-time staff. He's tried to meet the sporadic demand for administrative personnel through posts on Craigslist but has found it too time consuming and difficult to gauge the quality of candidates. He's also tried staffing and temp placement companies but hates spending the high fees attached to these services. Hour.ly aims to bridge this gap by providing an online marketplace for highly qualified people just like Jane. We ensure quality by providing a sophisticated recommendation and matching system that allows John to easily find reputable candidates with the skills he's looking for at fees well bellow those of traditional staffing companies. Today Jane works 20-30 hours a week providing part-time administrative help to John and other companies like his thanks to hour.ly. We currently have 3000 candidates and 500 employers using hour.ly and have personally facilitated the placement of over 4000 part-time and temp positions. Given the permanent change in the business landscape, flexible staffing will become an ever more popular alternative and hour.ly is well positioned to service this growing market."

With this example we've covered the problem, the solution, the market size, and the traction with a compelling story. The audience is placed in the shoes of the people experiencing the problem and seeing first hand how the product solves their problem. Startup presentations needn't be dry feature demonstrations. Remember that your product services real people, people with a story and real emotions.

If you liked this post please follow me on Twitter for more.

Thursday, November 4, 2010

A Startup's Guide to Application Scaling

A common concern among startup founders and application architects is "when do I start worrying about scalability?". Is it something that you need to start worrying about right away, or can you put it off for a bit? It's surely a question that every VC will ask you during a pitch presentation so you better have a good answer right? The fact is that writing a highly scalable application takes considerably longer than one that runs off a single application server, otherwise there would be no debate, just make it scalable from the outset. The greatest problem is that as a startup you don't how successful your product will be so why spend your precious time and money with scalability when you could be releasing a product quickly and testing for market acceptance. After all, scalability only has value if someone is actually using your product. The lean startup methodology suggests that we build a minimum viable product (MVP) to test for problem-solution and product-market fit and since we include the term "minimum" it is certainly implied that we not dedicate too much time to scalability. As I've noted in my previous post, the MVP doesn't even have to be a functioning product so let's look specifically at a working prototype. Once again it would be presumptuous to assume a need for scalability at the prototype stage, but is there a middle ground that we can take? What if your MVP's validate your hypothesis and confirm a strong market need for your offering, should you spend longer developing a scalable initial product or should you get it to market ASAP? I will return to these question in a moment, but first a brief digression.

The first thing to consider is the type of application your are building, or more spacifically the revenue model for your application. Will it be a viral application where revenue is generated by ad sales from a growth in your user base, or do you follow a traditional paid subscription model? Regardless of the model your application will still need to scale at some point, but if it is of the viral sort then you may have a lot less time to react. As we know, viral applications follow a hockey stick curve and once the user base starts growing it will do so at a rapid rate. When this happens you better be able to scale quickly or at least have a very endearing fail whale to placate your users. On the flip side, since viral applications are typically free, users are a little more tolerant of downtime (unless you provide a critical service like GMAIL), while paid subscription users expect a good degree of stability for their monthly fee.

So how do you handle scalability when you don't know if you'll ever need it. The answer lies in the fundamental principles of application programming. You needn't build a distributed system from the outset but what you should do is make it as easy as possible to implement scalability when the time comes. To achieve this your programmers should adhere to the following:
  • A Model-View-Controller (MVC) architecture
  • A well defined service level (this is one of the most important elements)
  • Object oriented design patterns such as Facades, Adapters, Factories, Abstraction, and Proxies
  • Loose coupling of application components (e.g. a Mediator design pattern)
Although these principles should be followed across your entire application, they are particularly crucial for services that are resource intensive, or those that access a shared resource. Resource intensive operations become excellent candidates for distributed computing as they can be offloaded to a separate web or cloud server quite easily to regain precious computing resources needed to host the remainder of your application. Shared resources on the other hand pose a problem once you decide to scale horizontally and load balance your web servers as the resource may have to be duplicated on each server if it is not decoupled. The best example of this is user file storage in a web application. If your application stores files on the same server that hosts your application, you would have to replicate these files in real-time if you wanted to run your application off two or more servers. By using the above rules you ensure that you can easily offload file storage to another server or a cloud service such as Amazon S3. At this point all that is needed is for your factory method to return a new IO class that communicates with a web service rather than the native file system. 

Once you have a strong application architecture you have to make metrics your religion. Monitor as much as you can and plot these metrics against your user growth. Estimate how many users your current architecture can support and combine it with your growth rate to see how much time you have. As you gain more traction your proposition to investors will become that much more appealing. If they ask you how your application scales you can at least tell them that it's been designed with scalability in mind and that the funding they provide will in part go towards handling your rapidly expanding user base. Your short term solution is always a faster server, a separate database server (if you don't already have one), or clustered DB servers which are easy to setup and generally don't require many application code changes (provided you have a good data access layer).

Regardless of the steps you take in scalability, an important thing to keep in mind is that application scaling cannot happen in a silo. It should be a holistic process that involves cross-functional teams throughout your organization. You may be able to scale your application but if your support or IT staff cannot then you still have a point of failure. If marketing decides to make a major sales initiative and your application isn't ready to handle the impending inflow of customers then you've not only wasted your advertising dollars but also risk loosing existing clients. The Flipboard launch was a classic example of technical and business units being completely out of sync. If you expect Ashton Kutcher to champion your product, you had better be able to scale from the outset. For those of us who aren't so lucky, a middle ground is usually enough. It's generally best to get your product into your customers hands as quickly as possible, but don't leave scalability as a complete afterthought. Invest a bit of extra time and make provisions for it from the outset so that when it is needed you can respond quickly without having to rewrite your entire application. If nothing else you'll have a well designed and robust application that you can maintain for years to come.

If you liked this post please follow me on Twitter for more

Saturday, October 30, 2010

Freemium, Panacea or Parasite?

Based on my observations there is a huge dichotomy in the freemium camp, there are those that swear by it, and those that swear at it. Given this level of divisiveness, how do you decide if it is right for your business? I've been wrestling with this notion for some time now and would like to share some thoughts on the subject.

The evangelists will argue as follows:
  • By taking a freemium approach you can rapidly build up your user base which increases awareness of your product thus further driving growth
  • It allows people to get familiar with your product over a long period of time and as they get more entrenched they will need more features, thus compelling them to upgrade
  • You are less likely to loose customers to other companies as paying users will at worst downgrade to your free service
  • It makes life easy for sales as they have a large pool of users that they can upsell to
Sounds great, but what about the bad:
  • Your free customers may never convert (and most don't)
  • You have to support a large user base that pay's nothing and uses up the bulk of your computing resources
  • Conversion rates can be dismal, less than 1% for many companies and up to 5% if you're lucky, that means your 1% has to pay for the remaining 99%'s usage
  • You have no real gauge as to how valuable your service is since the bulk of your users have not attached a monetary figure to it
  • It can be easier for your customers to switch to another provider since they have no financial buy-in and are not locked into a multi-period contract
  • You could be leaving a ton of money on the table
First off, freemium is not a fad or new concept, it's been around quite some time. In fact it's not even unique to web based businesses. The best example of a freemium model outside of tech is a bookstore, let's pick on Barnes and Noble. Bookstores have a number of users that frequently come into the store, read the magazines, and never purchase anything. Those that wish to read the magazine in the comfort of their home pay the premium price, while those that don't care pay nothing. Nearly a decade ago, in an effort to bring in lots of foot traffic, Barnes and Noble tried to make the experience of reading in-store as pleasant as possible by providing ample comfortable seating. Over the years we've seen the amount of seats diminish to zero and it is clear that the company is trying to make in-store reading as uncomfortable as possible. The reason I bring up this example is because this is where many web companies are going with freemium as well. Many are either eliminating freemium outright (e.g. CrazyEgg) or they are burying their free plans in hard to find places with fewer and fewer features (e.g. 37 signals). That's not to say that freemium is wrong for all companies, there are many that have been extremely successful and happy using it (e.g. Box.net). The important point however is that it's not for everyone and you need to determine which camp your product/business fall into. So let's begin looking at some critical considerations.

One of the most fundamental reasons for considering a freemium model is the presence of network effects. If the value of your product increases exponentially with the number of users (see Metcalfe's law) on the system  then freemium can be a good way to go. Similarly, if your product is a platform supporting a two-sided network, a freemium model can be applied on the subsidy side to generate added revenue through premium features. You can think of freemium on the subsidy side as a sort of bonus as these users typically pay nothing in an effort to grow the size and value of the network. If network effects are not a factor in your product you are almost always better off with a traditional pricing model and free trial. An exception to this is if your product has multiple revenue streams whereby non-paying users can engage in individual transactions. For example having a photo sharing site that also offers a printing and framing service, so although a user may not pay for a premium account, they may place periodic orders for prints. In this case it is clear that having a large user base is also beneficial. In the same vein we can think of multiple revenue streams as non-monetery currencies. Your free users can effectively pay you by submitting data and increasing the value of your offering. For example, free users tagging photos on Flickr creates value for the entire site. Ideally this value can be converted into a monetary figure to see if it justifies the cost of supporting your free users.

If you are considering switching from a paid model to a freemium model it is crucial to ensure that your websites architecture and infrastructure are scalable so they can support the rapid increase in users that will hopefully ensue. If it isn't you risk loosing your paying customers as well as the free ones that come in. You also have to ensure that you have enough cash on hand to support your freemium model. For example, if you're currently breaking even, or are only slightly cash flow positive and you introduce a freemium model, you will immediately go cash flow negative. Freemium not only increases your expenses (if you don't have excess computing capacity or are you're using cloud service such as Amazon S3) but also decreases revenue as certain paid clients may drop to a free plan. If you don't have enough cash on hand to ride out the dip then you may end up in flow-based insolvency. The important thing to note is that it may take a year or more to convert a free user so the cash-flow negative state may persist for some time. The same lessons applies to a new venture, if you are hoping to bootstrap your startup then freemium is not a good starting point. Due to the long conversion times it is also important to assess your retention rates. If users only use your product for a short period of time the it's unlikely to work under a freemium model. Simililary if your users are casual and only use the product on a sporatic basis, they are unlikely to become a paying customer.

Below is a table summarizing the factors that should weigh on your decision:


As a general rule of thumb, unless your product demonstrates a tremendous degree of network effects, you should charge for the product from day one and experiment with different price points, subscription levels, and free trial periods. Diligently track customer conversions with metrics, and monitor these metrics over a longer period of time to gauge the price sensitivity of your users. This will give you a good measure of the value of your product and how attractive your proposition is to your clients. Now that you have some financial information to work with you can use the above criteria to determine if freemium will increase the value of your product, or have long-term strategic effects that justify the added costs. Finally I will re-iterate that the decision to use freemium should be made very carefully as it can have a significant and lasting impact on your business. 

If you liked this post please follow me on Twitter for more

Wednesday, October 27, 2010

The Minimum Viable Product Dissected

One of the fundamental and most misunderstood tenants of the lean startup is the minimum viable product (MVP). The misunderstanding breaks down into three key areas which are described below. I've decided to address these three issues in one consolidated post as I've arrived at the solutions through various sources, including asking the lean startups founder himself, Eric Ries.

The first misunderstanding relates to the MVP concept itself. Many people are unclear how an MVP can be created for their particular product and what components they need to integrate into it. For starters you must look at the MVP not as a product but as an experiment. The prerequisite for any MVP is a hypothesis that you want to test as this drives the scope, nature, and content of the MVP. Once you have decided what it is that you are trying to learn or validate from the MVP you can then begin constructing it. This is generally the stage where confusion sets in. What exactly do you put into the MVP and how far do you go with it? Again the answer is driven by the hypothesis you are testing, but the important thing is to be creative. Many people think that if they have a very complex and extensive product, an MVP that tests whether clients will buy it would still require a great deal of functionality, even if it is the minimum. The fact is that the actual product does not have to exist at all. Don't lock yourself into the mindset that your MVP is some early version of your final product, in fact it is likely that you will throw the MVP away completely. With the expectation that you'll discard most or all of your MVP, you should be motivated to make it as basic as possible, this is where the creativity comes into play. Rather than build a whole system, build a simple landing page with some screenshots from your graphic designer (think of about.me), a value proposition, and a call to action. This call to action can be something as simple as "register for our beta launch". This will give you an idea as to whether anyone is interested in the concept. If this is the route you take then you'd be wise to A/B test the landing page as your value proposition can be strong but your message or delivery may be flawed. If you want to go further you can create a functional html prototype driven by static content that terminates at a form that tells the user "our product is currently in a beta stage, submit your email for an exclusive invitation to preview the system". At this point you may be thinking, "but what if my product is not done for a year, this person will be very disappointed, we've effectively lied to them". The fact is that the number of people that will arrive at your demo site is quite small relative to your target market which is hopefully big, so even if you do disappoint a few people, there will be many others to pursue. Besides, thanks to their interest the product may indeed one day come to fruition, and if it solves an important problem they will return once it’s done. Other options for your MVP include a PowerPoint prototype that you demo in person, a video of screenshots that you've pieced together, etc. Generally the more concrete your MVP the more accurate your feedback will be as you leave less to the imagination, hence you should continually test your MVP at each stage of development. The key takeaway is to be creative and remember that it's OK to fake it and fib a bit.

Similar to the above issue, I've often wrestled with the question of how the user experience (UX) plays into the MVP. How far should we go with UI design and creating an engaging UX in an MVP prototype? The answer here is to once again focus on your specific hypothesis and do as little as is necessary to validate it. Eric Ries has aptly pointed out that at the customer discovery stage you really can't create a good UX since you don't know who the user is yet, you simply don't have enough information. I would therefore lean towards a clean but minimalist UI in your MVP. Once you have moved on to the customer validation stage you can focus on perfecting the UX through more in depth research and tools such as A/B testing.

The final misconception lies with intellectual property. Most people feel that by throwing an MVP on the web they're giving away their idea and others will be tempted to steal it. There are several rebuttals to this claim. First off, Sean Ellis will tell you that most of the people that have the capability to copy your idea are way too busy with their own ideas and tasks to bother with yours. Secondly, Eric Ries will tell you that in practice it is very difficult to copy someone else's idea, go ahead and try it yourself. Finally, David Cancel will tell you that nobody gives a f*** about your stupid idea. The fact is that nobody knows if your idea is any good at this point, not even you do. If you'd heard something about a site called Twitter several years ago would you have been compelled to copy it? You'd have probably though "that will never catch on, who needs that?". The reason you would think that is because you are interpreting the idea from your perspective rather than the vision of the creator. In fact if two people pursued Twitter simultaneously it is unlikely that both would be successful or end up with the same result, as it is the execution of the idea and the pivots throughout its inception that define the outcome. The important thing to keep in mind is that the learning you gain from the MVP far outweighs the chance of someone stealing your idea. After all there is about a 10% chance (and that is generous) that your startup will be successful and less than 1% chance that someone will steal it so you decide which number it's best to dwell over.

If you liked this post please follow me on Twitter for more

Saturday, October 23, 2010

Lean Office Design for the Bootstrapped Startup

So you've launched your self-funded web-based startup and can no longer keep working in your basement. You need to setup a working space for your employees but don't have a fortune to spend on furniting it. I've recently been tasked with this very challenge and here are my suggestions to anyone in this situation.

First off, why is your office setup and design important? Well, for starters if your not a terribly well known startup and can't afford to pay extravagant salaries, attracting talent will be one of your greatest challenges. If a prospective employee comes to your office and see's a poorly furnished space, their immediate instict is that the company is cheap and doesn't care about providing its employees with a comfortable work envorinment. One of your key differetiators from a large corporation can be a fun office that people love to come into every day. Secondly, since you're a startup, it is likely that the people working for you will be there for 10+ hours a day so why not make it enjoyable for them and keep them as productive as possible.Fortunately all this can be accomplished at a fairly reasonable cost.

Let's begin by considering what elements your office space should have. Ideally the office layout will be fairly open to promote collaboration and offer an ample amount of natural light. If light is scarce, invest in some good quality bulbs as this can make a huge difference when one is staring at a computer screen for 12 hours.

Once you've found the ideal space, the challenge of furnishing it begins. As you begin your search for office furniture you begin to realize how expensive it is. Since you are dealing with an open space, the electrical is likely to be provided by a ceiling drop so you'll need a workstation to feed the power into. New workstations range from $1500 to $5000 each, which certainly adds up when you are buying 5-10 workstations. Workstations can be found used for $600-$1200 each, but I don't recommend going this route. The second hand market is littered with mismatched, damaged, and out of style units that are never quite what you want. What I therefore recommend is the route I have chosen, purchase a set of 4 six foot panels and arrange them to form a cross configuration. Then purchase 4 free standing 6 foot x 6 foot wooden L shaped workstations to arrange in each corner of your panel setup. The panels will feed power and you are free to choose whichever desks you want. Surprisingly this turns out to be much cheaper as one panel with power will cost around $350-$450 (depending on height) and a wooden workstation will run about $500-$600 bringing your total cost to around $900 per workstation. You will end up with a modern looking setup at almost the same cost as a used one. As an added bonus, installation of this setup will cost about $100 per workstation vs. $200 if you buy a standard panel based workstation. So besides the obligatory workstations, what else should you get for your space? I suggest the following items:

  • A couch/lounge area, sitting in one place is never fun and if your team works with laptops why not let them move around, plus a lounge area gives them a place to sit, think, and brainstorm
  • An espresso machine, programmers work late into the night, we drink a lot of coffee and really appreciate having an espresso machine in the office, plus it will save time as your staff won't have to drive to a nearby coffee shop
  • Tons of white-boards, this will help people brainstorm and plan, and is an absolute must for any software company
  • Comfortable chairs, although expensive at $400+ it will keep your employees happy and productive
  • Dual monitors (21" or greater), monitors are dirt cheap and will make your employees at least 10% more productive so they will pay for themselves in a week 
  • Make it fun, paint the walls a cool color, hang up some pictures, add your logo as a mural, this makes it an inviting place to come in, plus colors can stimulate different parts of the brain (blue makes you creative, red makes you more careful)
As a budget, if you are setting up your office for 5 programmers I would expect to pay around $15k. It may seem pricey but a nice office can be a strong tool in your arsenal for attracting and retaining top talent.

If you liked this post please follow me on Twitter for more 

Wednesday, October 13, 2010

Porter's Five Forces, Web 2.0 Style

Michael Porter’s Five Forces framework has become the de-facto tool for performing a strategic analysis of your industry or business and determining its overall attractiveness/profitablity. While it is quite universal, its application varies across industries, particularly for a web 2.0 business. This post is intended to be a brief primer on the strategic elements to consider when applying the framework to your web business. It is by no means all-encompassing as many of the standard measures in the framework still apply and are already well documented.

Degree of Rivalry
Typical considerations such as excess capacity and exit barriers can be ignored here so the only factors are: is the market you are service particularly popular and thus saturated with lots of new entrants, how similar are the offerings provided by them, and how similar are their strategies or target markets (e.g. demographics, location, etc.).

Supplier Power:
Since web businesses revolve around virtual goods or services there are very few suppliers involved, thus this category can largely be ignored. The one exception is if your application built on top of a 3rd party API (e.g. Twitter or Facebook). If this is the case then you have to be aware of the possibility of your supplier forward integrating and encroaching on your business. We’ve seen this happen a great deal recently as Twitter has increasingly added functionality that is currently being provided by third-parties (e.g. link shortening, photos, and multiple clients).

Barriers to Entry:
This is the largest category to consider as there are numerous elements in the Web 2.0 space that increase barriers to entry. Simultaneously there are also many elements that disguise themselves as barriers, but aren’t necessarily so.

What applies?
First off, does your application require a great deal of time and money to build? More specifically, does the minimum viable product version of your offering require a significant amount effort to bring to life, and there are no pieces of your product that can be separated from the whole. If this is the case then any competitor would have to dedicate a great deal of time to match your offering, at which point you are moving forward with more functionality, improving your offering, and learning about your market, thus creating a moderate barrier. A similar but more powerful barrier is created if your product’s technology is difficult to replicate (e.g. Google’s search), or if you hold patents on key aspects of your offering. Marketing can also become a barrier if your brand name becomes synonymous with a particular market or product type as you become the logical choice to service a clients needs. This is especially true in enterprise software for as the old adage goes, “nobody ever got fired for buying IBM”. If your product exhibits a high degree of network effects (e.g. Twitter, Facebook), namely the value of your offering grows exponentially with the number of people using it, and you have established a sizable user base, a very strong barrier is formed. While we have shown that building on top of an API can be risky, being the API provider has a number of advantages. If a number of businesses are based on your platform then value of your product is greater than its core functionality, the third parties are indirectly promoting your product on an ongoing basis, and user switching costs increase drastically.
Some other quick barriers include:

  • Does the value of your product rely on a great deal of data that is acquired over time?
  • Is the market that you serve highly complex and takes years to learn? If so then you have a path dependency (learning curve advantages) that others would have to go through in order to match your value proposition.
  • Owning a key distribution channel (e.g. being first in the organic search results of Google)

What doesn't apply?
Infrastructure requirements are no longer a barrier to entry as cloud computing services have removed high upfront costs and turned them into variable costs that grow along with the success of ones product. Similarly, economies of scale don't apply as cloud services scale and reduce automatically. While it’s natural to think that having a highly viral application is a barrier as it helps you to grow your user base rapidly, it also helps your competitors grow. Therefore it is more logical to think of a lack of virility as a barrier as organic user base growth is much more difficult and time consuming to replicate. Another non-existent factor is high marketing/promotion costs. Although it may have cost you a great deal of money to market your business, social networking tools have drastically driven down the cost of promotion, allowing bootstrapped startups to effectively advertise their product with only a bit of patience and creativity. This may not apply as much to enterprise software providers as social media is not as powerful in this space and sales are made largely on reputation. In case you haven't noticed, enterprise software is a difficult market to service.

Buyer Power
Buyer power boils down to more traditional considerations such as the number of substitutes available for your product. When thinking about this it is important to look beyond your way of servicing the user’s need, perhaps there is a completely different way of achieving the end goal. In addition, if you are in the enterprise SaaS space, is your business reliant on a small number of large buyers? The final consideration is the switching cost of your product. These don’t necessarily need to be monetary costs, as the “cost” of switching can be a loss in value such as having less people to connect to, no longer being part of a community, or having to build up your persona or position/ranking from scratch. For example, if a user has a high standing on a site like stack overflow, he/she is unlikely to switch to a new and similar offering as they would have to build this position up from scratch.

Threat of Substitutes
Largely similar to what has already been discussed, threat of substitutes effectively reduces to the switching cost of your product as well as it’s price and performance compared to other offerings that solve the same problem.

Keep in mind that most Web 2.0 firms do not benefit from any of the above barriers but still remain successful so don’t fret if you score poorly on these measures. A low barrier to entry is simply a characteristic of the web based software industry, as open source tools and cheap outsourcing allow nearly any entrepreneur with a great idea to bring it into fruition. Your main defense against competition is to stay ahead, create a product that your clients love to use, and most importantly know your customer and market. Always bear in mind that when performing the above analysis, you have to correctly identify the market your are analyzing. Look at all firms that help service a customers “job” in any way possible, not just your way of doing so.

If you liked this post please follow me on Twitter for more

Tuesday, October 12, 2010

The Technical Co-Founder Search

I was recently asked for advice on finding technical co-founders for a startup, so I thought it best to share my response with a wider audience. 

In order to keep this post generic I'll break it up into two stages as the advice varies depending on where you are in your startup.

The Early Stage
By early stage I am referring to the point in your business before product-market-fit is established and a verified business model has been put in place. To be more specific, you have tested one or more minimum viable products, found the element of your product that people love, and chosen a route to focus on. If your startup is not yet at this point then I suggest reading an excellent article by Charlie O'Donnell, Need a Technical Co-Founder which will help you determine if it is the right hire in the first place. Charlie suggests looking for a Product Manager at this stage, and it is in fact a suggestion that I touch on later in this article. I would add to Charlie's post that this is a good time to learn some basic programming. Get your feet wet with HTML, CSS and back-end languages like PHP, C#, or Java. The goal is not to become a professional programmer, but to understand the lingo and technical discussions your staff is having. Many non-technical co-founders can often help with early prototypes that have limited functionality and are intended to test the hypotheses you have about your product. Also, at this point try to find a part time technical advisor to give you some early guidance. This is much easier to do than finding a full time partner as many currently employed business leads will make time to help out other startups. 
The Growth/Expansion Stage
So you have a product that people like, that addresses a market need in a market that is big enough to support your business, great! By this point you have either built or are in the process of building your working prototype, likely through a combination of in-house and outsourced resources and are beginning to think of the next stages of your business. You realize that your lack of technical abilities can only take you so far, and so the search for a technical co-founder begins.
So who are you looking for? As with programmers, a technical co-founders match is based 50% on personality and 50% on technical abilities. This presents a challenge as personality is not always easy to gauge in the short term (more on this later). From a technical standpoint your interview should focus on problem solving skills, breadth of knowledge, and vision. Is the person feature focused or more appropriately, product focused. Do they view the application as a product or an ecosystem from which new products, ideas, and sources of value can grow? Have they worked on routine engineering projects or have they encountered a good breadth of technical challenges? Your focus should not be their knowledge of your specific programming language (although this helps), but rather their ability to architect a well-functioning, highly usable, and robust application. Are they familiar with the latest computing trends and technologies such as web services (e.g. SOAP vs. RESTful), distributed computing (e.g. SOA), API's, and open source technologies (you want to keep your costs down)? Ask them to take you through their application design process, what considerations do they make? Do they use the out-dated waterfall model or the better suited agile methodologies? See if they think of the application as it is today, or as it could be in the future. Ask about their failures and struggles, how they recovered, and what they have learned. Do they give their team as much credit for their success as they do themselves? As far as eduction goes, a Bachelors degree in Computer Science/Engineering is a must and an MBA is often a benefit as they should be able to weigh technical vs. business trade-offs. 
As mentioned above, product managers make good candidates, provided they started their career as programmers. If you choose to hire a PM in your early stage, search for one with a CS background and groom them with this future position in mind. Project Managers with a CS background are also wise choices as they've been faced with many of your challenges on a smaller scale. On the personality side, look for passion and excitement about the work they've done and an interest in your product. Look for someone that is personable and inspiring but also strong willed.
So where do you start looking? As anyone will tell you, a great starting point is tapping your network and asking around for people they would recommend. If this fails it's wise to begin attending technical conferences such as the Web 2.0 Expo which offers an attendee directory. Scan the directory for people with the right skills (as described above) and engage a meeting with them. Scour LinkedIn and become an active member of technical groups, see who stands out. Another option is to contact job banks at MBA programs as a good proportion of MBA students have technical backgrounds. Find candidates that have several years of technical experience and if they fit a good chunk of the above criteria, give them a chance. Once a suitable candidate is found, bring them on as a lead developer or project manager with the prospect of becoming the companies CTO. Offer them restricted stock units with a vesting period of at least one year. An interview will never reveal if the two of you work well together so test things out before you issue equity. Your candidate should be willing to take a lower salary in exchange for ownership in the company, thus proving their dedication and belief in your product, and their drive to make it grow. 
The search for a technical co-founder is much like the search for talented programmers and designers, only more difficult. There is no magic formula and it requires you to keep your eyes and ears open, interact with lots of people, be patient, and never settle. As your product develops and your user base grows, your sales pitch to talented individuals will becomes more enticing so don't get frustrated if you can't immediately find someone. Remember that anyone you hire will heavily influence the direction of your business so ensure that they are good fit for your company and that you share similar values. 

If you liked this post please follow me on Twitter for more 

Monday, October 11, 2010

The Great Outsourcing Scare

I recently read an article on Yahoo once again claiming that software development jobs will decline in developed countries as outsourcing will become ever more prevalent. 

I for one wholeheartedly disagree with this claim for a number of reasons. First off, we've been down this road before and when I went to take my Computer Science degree more than eight years ago, the .com bust and ensuing rise of India and China as outsourcing destination led many to question me for pursuing such a degree. So where are we now? Well outsourcing certainly has changed the way many industries work, particularly IT and manufacturing, but there is also no shortage of jobs for talented developers. As the person responsible for hiring programmers at my company, I have discovered that the pool of developers with creativity and problem solving skills is getting smaller and smaller. This trend is not only evident in the top percentile of the talent pool, even mediocre developers are hard to find. The same sentiment also extends to tech hubs such as Silicon Valley as talks with several startup companies reveals a similar struggle. So why could this be you ask? First of all, students are being fed the same nonsense that I listened to prior to undertaking my degree and are pursuing different fields. This is evident in the steady decline of CS graduates over the last few years. Next, the recession has brought with it a demand to lower costs and automate processes, something that computers are great at. Similarly the rise of new hardware devices such as tablets and smartphones have created new markets for software, so while some development is being outsourced, the increase in demand has more than offset the negative effects of offshoring. 

One of the central arguments of Yahoo's post was that software development is a simple candidate for outsourcing as it is virtual in nature. By the same argument we could extend the outsourcing scare to professions such as architecture, engineering, business analysis, financial analysis, and so forth. With the North American manufacturing sector essentially dead, and the predicted outsourcing of all "virtual" industries soon to follow, can it be posited that the job market in developed nations is effectively doomed? By their argument there will only be work for doctors, top-level managers, and low level customer service representatives. Wouldn’t this also increase wages in developing nations thus reducing the benefits of offshoring? In fact this trend is already occurring as outsourcing firms are already looking towards new destinations in Eastern Europe to remain competitive. Sure the above example is a bit exaggerated but the fact is that you cannot outsource everything. As we all know, the true success of any company stems from its employees. Outsourcing has an important place in a company’s toolbox but it is not a panacea for IT companies. For a company that strives to be the best, there is no substitute to a locally present, dedicated, and energetic team.
I write this post in the hope that students will continue to view computer science as a lucrative and growing field rather than one destined for decline. 

If you liked this post please follow me on Twitter for more 

Wednesday, September 22, 2010

Business Lessons from Blockbuster's Failure

With Blockbuster's Chapter 11 filing looming, it seems a fitting time to reflect on what went wrong and what businesses can learn from it. Many would simply label Blockbuster a casualty of Schumpeter’s theory of creative destruction, and in many cases it is, but the fact remains that its current position could have been avoided.

Back in 2002 Blockbuster was thriving as the dominant source for movie rentals, enjoying a lofty market capitalization of $6B; this was also the same time that Netflix IPO'd on the Nasdaq. The Netflix IPO wasn't a complete success as its share price quickly receded from $15/share at the time of the IPO to around $6/share. At the time Netflix's business model was quite different from what it is today. Netflix serviced customers by creating a subscription based service that allowed users to rent as many movies as they wanted for a fixed price of $20/month. At the time Netflix was mailing the physical DVD discs to its customers and received returns in the same manner. Given the poor performance of the IPO Blockbuster shrugged Netflix off as another fad and proceeded with business as usual. Today the landscape is very different with Netflix’s dominance steadily growing and its stock price climbing to over $150/share. Netflix's market cap is now $6.8B while Blockbuster's was about $200M a year ago and a paltry $20M prior to the Chapter 11 announcement.

So where did Blockbuster go wrong? Their main folly was failing to see the forest from the trees. In response to Netflix's proposition of convenience, Blockbuster announced that they will let people return videos whenever they like, with no penalty for lateness. What this did is further increase their capital costs, which were already drastically higher than Netflix’s given their need for physical locations. This of course did little to improve business as customer defections continued and revenues dropped. Because of Blockbusters high capital costs, the decrease in revenue caused profits to tumble into the red, the company closed store locations which made it even more inconvenient for customers to rent movies, further driving them into the arms of Netflix. The real hit to their business came in 2007 when Netflix launched a download version of their service and soon after, iTunes began distributing movies to its portable devices and Apple TV. In this case Blockbusters mistake was that it failed to follow Clay Christensen's theory of "the job". Blockbuster continued to see itself as a provider of movie and game rentals rather than a distributor of entertainment. By locking itself into this narrow view, they ignored the innovations happening around them and believed that people wanted to come into the store and talk to their staff, get recommendations, and make their choice, but of course this was not the case. The internet provided all the recommendations they needed and the convenience of renting with a few mouse clicks became impossible to beat. To further compound their problems, the recession as well as growing concerns about the environment took hold, so people were less and less willing to spend money on gas and make two trips to rent a movie. Realizing that Netflix and iTunes were serious threats to their business, Blockbuster began opening automated kiosks in grocery stores and other locations to increase convenience, as well as creating an on demand service that would stream movies to portable devices, PVR's and computers. But all this was too little too late, and the crutch of servicing its large debt load and high capital costs proved too much in the face of their entrenched and thriving competitors.

The key lesson to take away is that no matter how successful you are today, tomorrow brings no guarantees. With the world evolving at a rapid pace, companies must look at their business from a "job" perspective and identify the trends that can threaten or disrupt their means of fulfilling the job they're being hired for. Taking a sufficiently high level view of the job, companies should perform periodic Five Forces and SWOT analyses to see what growing threats exist and where their weaknesses lie in relation to these threats. By continually comparing their value proposition to those of competitors a company can proactively rather than reactively respond to upstarts and generate a new short and long term business strategy.
So what could Blockbuster have done, well I will summarize some of my thoughts but I hope to leave this as a discussion for comments on this post.
  • Purchased Neflix in 2001, this may not have been necessary if blockbuster had simply repositioned itself and modified its strategy
  • Opened kiosks much earlier and began closing stores, this would have reduced capital costs and improved convenience
  • Emulated Neflix’s early model of subscriptions and distribution through mail
  • Entered the on demand space much earlier, before Netflix and iTunes took over the market
Although hindsight is 20/20, there were numerous points where Blockbuster should have recognized serious threats to its business model and used its then powerful brand name and market share to reposition itself. Alas, by taking an incorrect view of their business and failing to account for the disruptive innovations around them, Blockbuster has crumbled just days shy of its 25th anniversary. 

If you liked this post please follow me on Twitter for more 

Tuesday, August 31, 2010

Thoughts on Hiring Programmers (Part 1)

Having gone through the process of hiring programmers and support staff a number of times, I've developed a few insights that I'd like to share. Although the bulk of these lessons apply to any type of position, they are geared primarily towards hiring technical staff. Also, this post, as with most of my posts, applies mostly to startups or small businesses as the hiring process for large companies is quite different. 

When I first started hiring programmers, I approached the process with a rather cavalier attitude assuming it would be a simple process. After all, what is there to it, post the job, filter the resumes, interview and pick a front runner. Sure enough, after several unsuccessful hires, I learned that it's not so trivial after all.

I will begin with a suitable starting point, deciding who you are looking for. On the software side your choices essentially break down into two general groups: back-end programmers, and front-end programmers. Of course these can be broken down into more specific sub-categories, but in the interests of brevity I focus on these two. Naturally you will start with deciding what specific technologies your potential hire should be familiar with so we will gloss over this point. The real question is how much experience are you looking for? The first thing to consider is how many people are doing this (or a similar) job at your company already? If there are a number of senior individuals and you are willing to dedicate up to 3 months for training, then a junior employee may suffice. Another question is, how pressed for time are you? If time is of the essence then a junior programmer is a poor choice. Such an individual will not only take a long time to complete a task, they will also take up a lot of your senior employee’s time with questions. It is safe to expect that a seasoned programmer will be up to ten times more efficient then a novice so keep this in mind when creating your project plans. This statistic is even more palpable when hiring front-end programmers as they not only have to contend with specific technologies, but also the nuances of those technologies across various browsers. Finally, if you are hiring a contractor rather than a full timer, never go with a novice for obvious reasons (more on contractors later). Why then would you hire a junior programmer? Well there is the obvious difference in wage, but as we know, you get what you pay for. Therefore the main reason is to identify highly creative individuals with potential, that are not constrained by past experience. In addition to this compelling reason, recent graduates often qualify for government grants or subsidies such as Canada’s IRAP program which covers up to $30,000 of an employee’s first year wages. Therefore, hire an experienced programmer if the tasks to be performed are fundamentally complex, your team is small, deadlines are tight, or training resources are scant.

In part 2 of this post I will discuss what qualities you should look for in junior vs. senior developers, but first let us address the contract vs. full time question. My past experience with contract employees has been largely negative. Since they are with your company for a short period of time, they do not take ownership of the product and often produce results that are inferior to those of full time staffers. So when should you hire a contractor? If the task to be completed is highly specialized and nobody on your team has experience with it, or similar to outsourcing, if the task/project to be completed is non-core, isolated, and not expected to be modified frequently in the future. If you do chose to hire a contractor, ensure that you have enough time to perform frequent code reviews and have laid out a proper product requirements document. 

The next issue we have to address is where to source from. The obvious options are: staffing companies, online job sites (e.g. Monster.com), company website, etc. My initial foray into hiring led me to use the most obvious source, job sites. After using them for nearly five years now, I'm more and more convinced that they are decent, albeit flawed resources. I continue to use them in the off chance that a good applicant will surface - and this has happened on a handful of occasions - but for the most part, their success rate is quite low and seems to be diminishing. One of the key problems is the ease with which users can scan through a plethora of jobs and submit countless resumes. This results in a massive influx of resumes that don't fit the job description. This of course is not a problem if you have an HR department to sift through them, but if you are a startup, you're likely doing this on your own. As a quick digression, here is how you sift through them:
  • Scan to the bottom, if there is no cover letter I tend to discard them
  • Paste it into MS Word, are there spelling or grammatical errors, if so then it's gone
  • Is it long (depends on the job but 2-3 pages is usually enough), if so then it's gone
  • Does it highlight the key skills you are looking for, if not then it's obviously garbage
  • Is your company name contained anywhere in the cover letter or resume, if not then it has potential for disposal
If it passes these tests then you can begin to look at it in more detail. I've found that this typically removes up to 80% of resumes and I promise you that individuals that make the above errors are rarely a wise hire. What you are essentially looking for is whether or not the candidate took the time to apply to your position, if not then you shouldn't take the time to read their application.
Returning back to job sites, once you have whittled the resumes down to a manageable level and begin to examine them more closely, you will notice that only 10-30% are potential hires based on education, past experience etc. The key now - and this applies to any resume you receive - is to initiate a phone conversation to gauge their level of communication. A very large chunk of your applicants will originate from places like India and China and may speak very poor English. You must at this point determine how much you plan to communicate with your developer and what it is they will be working on. In 95% of cases I would say that you will communicate a lot and that good communication is the most important skill they can possess. If you expect them to work on routine engineering with a detailed written project plan, and you have a copywriter then you can sacrifice on communication slightly. Once you've completed this process you'll discover that only a small fraction (maybe 2%-4%) of the applicants are actually worth interviewing. I suspect that the reason for this, and this is purely speculative, is that the most talented employees have found jobs through networking, reputation, etc. and a large chunk of those on job sites are the ones that are struggling to find placement. Once again, this does not always apply; I have found some truly spectacular employees this way, but be prepared to prune a large number of resumes. To wrap up, you should use job sites as a secondary option. I've submitted posts where I've found a number of suitable applicants, and I've also had some where not a single candidate was acceptable. 

The next resource I've used several times is staffing companies and in general, the experience has been negative. Commissions for staffing companies go as high as 25% of the employee’s first year income, and can be negotiated as low as 8%. Despite my negative experiences, success can be achieved by applying some rules. First off, you will be approached by dozens of staffing companies as soon as your position hits a job board so be very selective. The staffing company or individual you choose must specialize and have experience in recruiting software developers. This will save you lots headaches and wasted time. Secondly, ask the staffing company where they source from and how the candidates differ from those on job boards. You are looking for a company that brings you high potential individuals that are found through years of networking. Finally, meet with the recruiter in person, explain to them what you are looking for, and ask them to re-iterate in their own words the sorts of candidates they will send you. You would be surprised how many will send you resumes that ignore certain predefined criteria. The criteria most often ignored is communication, so I suggest that you clarify what the recruiter what classifies as average vs. good vs. excellent communication. Once you've chosen a staffing company, negotiate furiously as there is often room to bring the commission rate down. 

So what are the best sources? Well, once your company has developed a bit more exposure, your company website can become a good source for collecting resumes as applicants will typically take more care in preparing their submission as they likely have a stronger desire to work for your company. Another free alternative is Craigslist which is becoming increasingly popular with job seekers, and best of all doesn't cost anything so why not give it a try. With LinkedIn's user base growing rapidly, I recently decided to post a job on their board as the price point was attractive at only $125. Although I received a smaller number of resumes then I did through other job sites, the quality of applicants seemed to be better. Most importantly I found an excellent candidate that my recruiter was unable to find for over a month. Given my sample size of 1 it is difficult for me to conclude that LinkedIn is a great resource, but once again, with the relatively low price it's certainly worth trying. The best resource however is networking. Create a referral program at your company whereby anyone that identifies a successful candidate is awarded a payment of X dollars. Since a recruiter will cost you at least 10%, you are looking at a cost of $5K-$20K so why not use this as reward money and have people you know and trust do the work for you. With the advent of social network tools such as Twitter, companies with a large number of followers can extend this reward to the public domain. A number of companies have started doing this and seen a great deal of success.
My next post will look at the specific traits and skills that you should look for and the interview process in general. 

If you liked this post please follow me on Twitter for more