What’s great about daily deals is that everyone has an opinion on them. The Groupon S-1 certainly has something to do with that. So too does friends and colleagues using deal vouchers when out eating or doing activities around the city. Not to mention those emails in the inbox every morning!
From Groupon to LivingSocial, from Facebook Deals to Google Offers, here are five things that could change the game in daily deals and drive profitable growth.
1. Make merchants successful. Use data to make them successful. We’ve all read the stories about how bad daily deals are for merchants. But Daily Deal companies are bringing local merchants online in an unprecedented way. As a result, they have the opportunity not just to bring in customers, but to help these merchants manage their businesses by leveraging data, the Internet, and payments. Every business struggles with engagement and retention; local businesses are no different. Instead of becoming known for bringing in cheap or existing customers, become the merchants’ trusted business partner.
2. Reward loyal users. Drive engagement. Implement a loyalty/rewards program. To borrow a phrase from American Express, Membership Has It Rewards. Deals companies can deliver on that promise by providing non-deal related benefits to their members. More frequent buyer? Get sneak previews of hot deals and longer expiration dates. Become the user’s trusted home. Introduce features that will drive engagement and loyalty, like a DealBox, so that no matter where you buy your deals, they’re always available in your DealBox.
3. In mobile, combine virtual and real-world check-ins and rewards. I love the new FourSquare + Deals offerings! One deal company could lead the pack in mobile by introducing its own badges and rewards, tied in with a real world loyalty program. And make offers on mobile truly immediate. Don’t just throw hundreds of instant offers at a user – provide a deal stream or make the mobile app more fun and aspirational, not just a proxy for the existing consumer sites.
4. Make key acquisitions and hires. Many great tech are in San Francisco. One company could corner the market on SF talent by acquiring a handful of startups in the city. Lots of talented engineers and product people in SF are interested in deals, ecommerce, local, and payments.A number of small startups in the city that have worked in and around the deals space – from deals themselves to deal related analytics. These companies would provide a great basis for an SF office. Ditch the 101 vanity board and acquire a handful of companies instead. Long term, these companies will need product diversity to drive revenue diversity. Talented engineers and product people will come up with the best ideas.
5. Diversify the revenue base to deliver EPS. All kidding in the S-1 aside, Groupon’s filing provides some sobering reading. The company will get out, get liquid, and make lots of people lots of money. The challenge is how to build a sustainable, profitable business in the space long term. Now is the time to prove that deals can be profitable. Making merchants successful, rewarding loyal users, and having talented engineers creating new products in support of revenue diversity are the keys to EPS.
Daily deals have come from nowhere to become a multi-billion dollar market in just a few years. Social, mobile, and the need for local merchants to get online have been huge waves to help make this happen.
Tech companies are incredibly smart when it comes to analytics about their own businesses – they use data to optimize at every turn. Now Daily Deals companies have the opportunity to put that data to work for their users and merchants. Daily Deals may provide one of the richest “big data” problems of all. Couple that with greater user engagement, loyalty rewards, and becoming merchants’ trusted business partner, and EPS will follow.
You might be wondering what I’m doing building a game called BabySitter on Facebook. We all have our hobbies and one of mine is building apps for fun.
Sometimes the best ideas come from what’s right in front of your eyes. Friends, relatives, and colleagues were all having babies. I would go over to friends’ houses and they would be talking about their kids, about all the ups and downs. They would talk about baby food and potty training, babysitters and birthday parties. Of course there were also the big milestones: learning to walk, switching from soft food to solid, learning to read. And the difficult times like getting sick and having to go to the doctor.
I wanted to build a game where I could try out a bunch of interesting viral approaches. I thought about building a cool social car racing game where you started with an old beater you inherited from your Uncle, but it seemed complex for a first game. And I wanted something where I would have no shortage of new ideas, no limits to what I could add. Thus… BabySitter. When I needed a new idea I would go over to a friend’s house, listen to them talk, play with their kids, and yes, look at a few parenting magazines.
Was a little piece of me trying to get on the good side of the woman I was dating? I won’t deny it. And was my Stanford MBA schooled brain subconsciously optimizing for a highly desirable demographic and gap in the social gaming market? It’s entirely possible.
Game development is incredibly fun because it’s so creative. It involves three very interesting aspects: game design itself, which includes human psychology, incentives, and rewards; the artwork, which while I make a terrible artist myself I have very strong opinions on; and monetization. What’s really great about building social games is that they’re social (duh!) and they are relatively inexpensive to build.
One challenge is finding or putting together a team that can build games. Game development is a lot different than web site design or mobile app development. A game requires artwork creation, animation, and back-end development. That’s not a particularly easy mix to find.
When I started out, I found a developer who did great graphics work. The babies he designed were cute. He added in music without my asking him… it looked great. But tortoises crawl faster than my app was being developed. I tried another development shop but disliked the babies that came out. I don’t have the images anymore, but they looked sickly and not cute at all. I sent them some samples and told them to plump up the babies, make them cute. They did, and the babies of BabySitter were born. The developers have been ultra-responsive and great to work with ever since.
A Conversation Piece
The other thing I love about working on BabySitter is people always have opinions on it. “You should add doctor’s visits…. You should add a school… What about doing something for Halloween?” Amusingly, I started enjoying all the conversations with my friends about their kids, because I was mentally making a huge list of exciting new features to add to the game. The list never ends, which is the beautiful thing about creating a game like this.
Plus people have a lot of fun with it. The looks of incredulity when I say I’m working on a baby game are worth every penny I’ve spent building it, and my friends get a great laugh and enjoy giving me no end of grief.
What really takes the cake, however, is the user feedback. Users are not shy about posting critical feedback on features that need improvement and bugs that need fixing, but there are also comments like, “I love this game.” That’s priceless. I’ve gone from nothing to something to something that more than a few people love playing. If you don’t get why that’s so cool, I won’t try to explain it, but having started companies and built software since the age of 12, there’s just nothing like creating something from scratch and then having people love it and pay money for it.
Learning The Facebook Platform
I did have a few other goals in starting this project. One was to learn about Facebook as a platform. How easy or hard was it to build apps? I wanted hands on experience with MAU’s and DAU’s so I could really internalize what those meant. When entrepreneurs talked about their MAU and DAU growth, it was very abstract. I needed to make it applied and real by experiencing it myself.
I also wanted to learn about monetization. People would tell me about the required shift to Facebook Credits, but what did it really mean? What was the impact on the applications and the user experience? Where the revenue went was obvious. But what about the product experience and monetization?
When it comes to startups, user acquisition and customer LTV are everything. How was Facebook as an advertising platform? A lot of people told me that social didn’t monetize well, that it was hard to convert. During business school, I started and ran a $750K run-rate consumer lead generation business. That meant I moved a lot of traffic. I wanted to understand and get a feel for this new traffic platform.
It turns out that spending money on Facebook ads and Sponsored stories is an excellent way to drive traffic. And equally as interesting are the implications for Facebook (and Apple for iPhone apps): not only do I spend money with the company to drive traffic, I also give them a portion of the revenue generated from that traffic! With the right game dynamics (like Birthday Parties, which involve lots of friends), users will invite their friends and provide significant organic traffic growth.
Just as growing up isn’t a cakewalk, neither is building BabySitter. Take for instance the day that the Facebook ads I was running wildly exceeded my expectations for new user acquisition, plus a database that was sorely in need of an overhaul. Dozens of users complained and the game screeched to a halt. It took two weeks to switch to Amazon RDS and revamp the database. But now BabySitter is back and growing. Yesterday users sent out more than 1,250 invites to their friends.
No startup grows as fast as it wants to. When it comes to BabySitter, I can’t build artwork and new game features as fast as I want. To do this, I need to expand the development and art teams. But sprints are now running smoothly.
Converting to Facebook credits also took some time. I liked the old gWallet offers because it meant that babysitters could do “work” in exchange for currency. The “work” was watching advertising videos or completing offers. I loved this because sometimes they could pay with their wallets, other times they could pay with their time. I haven’t yet found a replacement for gWallet and users are pushing for more ways to earn BabyCash. (Did I tell you about BabyCash? More on that next time.)
Then there was the day that Facebook shut down wall posting for my app (and others). I wasn’t feeling any “Developer Love” on that day. Suddenly, users were getting popups saying things like: Unable to publish stream. Most of the invite functionality stopped working. It was painful.
Yet my ads were still running. So I had lots of new users showing up getting a bad experience. I was brutally reminded of online marketing rule #3: turn off the ads if the site’s not working! Fortunately, after fixing some holes in the app, my request to re-instantiate wall publishing was approved. I recently turned ads and Sponsored Stories back on and users are joining in droves once again.
The End Game
Friends keep telling me how crowded the social gaming space is. That may be true, but it’s still a ton of fun building a social game. Did I tell you about the new Add-A-Dad feature? And yes, we do support multiple Dads.
The monetization opportunities are endless and the demographic is ordinarily a tough one to reach. Plus, there’s the sequel: Teenagers, where you have to shuttle your kids around to school…
Several posts ago I talked about using offshore development resources to build an entire product. Recently, a good friend and entrepreneur contacted me about doing something narrower: using a service like Odesk to get an iPhone application developed to go with his company’s existing web site.
He asked me to guide him through the process. I thought that would be useful to others, so I’m summarizing the guidelines here.
1. Draft a brief post to be used on Odesk, RentACoder, or elsewhere. This is not a project description or a product specification, but rather a specification or mini RFP for the developer you want. For example:
This project is to develop an iPhone application to accompany our existing web site. When applying, please describe the following:
a. Your experience with iPhone application development (number of years, examples of apps developed).
b. A description of your team (are you an independent developer, small team, or large company).
c. Your availability and work schedule (when can you start, what hours do you work).
d. An explanation of how you test your code.
e. A list of project management tools with which you have experience.
2. Evaluate the responses for completeness. In looking at responses, you are as interested in the completeness of a response as you are in the text itself. These are simple questions but a developer who does not respond to these basic questions is likely going to lack similar attention to detail in working on your project.
3. Draft a very simple specification for your application. This is not the complete application as you want to ship it in V1. Rather, think of it as an internal V1. Something that will show you what the developer is capable of, what they are like to work with, their code quality, and responsiveness, but will also provide you with an app you can try out internally.
The specification should be complete with screen mockups or detailed wireframes, and a description of all functional actions and user interactions in the application.
Many people start out by spec’ing out the complete V1 application they have in mind – this is a great starting point. But slim that down to the bare minimum – say, login and upload files, or login and view something, for your internal V1. Obviously, drafting the specification should be done before or in parallel with the developer recruitment process.
4. Select developers. In theory, it would be nice to conduct a complete technical interview and have a developer solve a coding problem or build a sample app. In practice, the internal V1 frequently serves as the real technical interview. That’s why it’s critical that it be well contained.
I often suggest that during the development of the internal V1, companies select two developers or development teams. After working with them both for a week or two you will get a very good sense of what you like and don’t like and you’ll have a point of comparison and greater context for making decisions about future work.
There is no reason to choose low-rated developers, developers who have no work experience on Odesk, Rentacoder, etc., or huge development shops that employ hundreds of developers. It is better to wait a few more days than to rush — it will only cost you more time later. Often the best developers are those that are independent or have a small group of colleagues, a team of, say, five or six. With smaller shops, the developers are more likely to care about their individual reputations and invest more in your code and project.
Pricing varies but based on the proposals made by people who responded to your job, you’ll have a good sense for the range.
On Odesk, employers typically pay by the hour; on RentACoder, by the project. Both services support the other format, however. Another reason to start with a small “internal” V1 is that that way you won’t be out a lot of money if you don’t like what you get. Plus, you can have the same product built twice by two different development shops, pay for both, and then decide on one for the go-forward project.
5. Manage the project. Crowdsourced /offshore development requires significant project management. A hosted ticketing (bug tracking), source code repository, and wiki system that you and the developers can access is essential. For apps that require server interaction (e.g. for login, upload, download, notification, etc.), post well-documented API’s on the wiki. Make sure your developers check in code regularly (that means every day, even if the project is just getting started). Schedule regular IM meetings to discuss questions and issues.
Skype works too, of course, but I’ve gotten feedback from developers that IM is often easier since it gives non-native English speakers a chance to compose their thoughts and read what you’re saying rather than trying to listen to it. Whatever medium you use, the key is regular communication. Test builds immediately when they are available so that there is little to no feedback loop delay. Set a good example – make sure the developer is never waiting on you.
If it doesn’t seem like progress is being made, cancel the project and start over with a new developer. It’s better to cut and run early rather than keep holding out hope that things will change. They rarely do.
Tell the developer up front your expectations on coding practice: well documented code, good variable names, and well-tested applications on delivery to you.
6. TestFlight your app. TestFlight is a dream tool for testing out iPhone apps. Instead of having to email out builds and then have people on your team connect their iPhone or iPad to their computer and sync the app, the developer uploads the app to TestFlight and the app can be installed over the air. It’s easy to track versions, and when you’re testing out a new iPhone or iPad build every day or two, TestFlight is a must have.
Regarding testing, test your API before the iPhone development starts. Provide the developer with sample code if possible; it will shorten development time and avoid confusion
Perform code reviews. Even if you’re not particularly technical, if you’re familiar with code at all, you can look for things like comments and good variable names. You are looking for highly maintainable code.
7. Prepare for V1!
It’s quite likely you’ll have to switch developers at least once if not twice before finding one you want to work with long-term. Issues that arise include developers that don’t deliver what they say they will, write bad/buggy code, or don’t have sufficient time to work on your project.
Once you find a developer or group of developers you like working with, talk about the long-term project. Developers on Odesk, RentACoder and other services move from project to project, but many will want to work with you if they know you can be a long-term source of reliable and steady income.
Of course, get feedback from your internal users on what they liked and what they didn’t and factor that into the “real” V1.
Start with a mini version of your app, until you find a developer or group of developers you want to work with long-term. Frequent communication and project management tools are critical. Spec out your design completely, down to wireframes or screens and complete functionality. Of course, ask developers for their input and ideas, but don’t expect them to define the feature set or design the user interface of your application for you. Good luck – and feel free to contact me with questions!
I just finished one of the most compelling books on pitching I’ve read in a long time. It’s called Pitch Anything. I heard about it through Andrew Warner’s interview of author Oren Klaff on Mixergy.com.
If you’ve ever needed or need to pitch a customer, investor, or potential employee on you or your company, this book is a must read. Oren presents a unique approach to pitching called “framing.”
When I advise entrepreneurs on their pitches I often tell them “own the clock,” “don’t get lost in the weeds,” “give as much thought to your pitch as you do to your product,” and “make an emotional connection with your audience.”
Oren goes much further. He talks through a complete model for pitching, from the first interaction, to walking into the lobby, to closing the deal. He backs up his approach with details on why people respond the way they do. And although he doesn’t say it this way, he ensures that if you use his techniques, you will be respected by colleagues, potential investors, and customers alike.
For a preview, check out the interview on Mixergy.com. Then, get the book. I highly recommend it.
I recently met with an investor who bemoaned the fact that consumer tech companies get higher valuations than business tech companies. Many business tech companies have fantastic revenue growth, experienced management teams, and excellent execution, yet the market values consumer companies more. Here’s why.
Mass Market x Monetization x Main Street
1. Mass market.
From a business model perspective, mass market means mass reach and consumption. Everyone can be a user. The potential scale is as large as the number of people on the planet.
All those users can consume ads, pay directly, or do both.
That results in a very simple to understand (and in theory, simple to execute) revenue model:
Many users x Small amounts money = Lots of money.
3. Main Street.
From a market and investment perspective:
Many people have experienced or know of the company and are therefore more likely to buy the stock and drive up the price (many people prefer to buy the things they know).
People want to say they’re in it. I invested in “It’s really profitable but you’ve never heard of it corporation” versus “I invested in Google/Facebook/etc.” In later stage investing, investors can make a lot of money investing in less well known or undervalued/mis-priced assets, but many want to be in the “hot” companies.
There’s good reason for that: hotness by association. Plus, being hot begets more hotness. What is the value of being hot? Though it might seem irrational to some, the market certainly does its best to quantify it with multi-billion dollar valuations.
In addition to the three M’s, there are a few other important aspects that drive consumer company valuations:
4. Network, winner take all, and platform effects.
Consumer companies benefit from low user adoption costs and the network becomes more valuable the more people join. Social proof is obvious. In contrast, the enterprise equivalent is much less visible; social proof must be heavily and expensively marketed. Think ad campaigns like Oracle’s “10 of the top 10 IT service firms use Oracle.”
Users customize the product rather than the product developer. Users do this through preferences or their own content rather than customized “pro serve” content and development for individual customers.
This results in perceived (and sometimes real) lower operating costs. That is, the perception that a consumer company doesn’t have to hire lots of sales and service people, because the money comes from all those users. No long RFPs and sales cycles.
Winners tend to take the whole category; or there’s #1 and #2 followed by a long and not very valuable tail.
Consumer winners frequently become platforms because they leverage their consumer base, infrastructure, or both, to drive the development of third party applications on their platform. Developers are drawn to these platforms because of their broad adoption and the promise of accelerated adoption for their own applications (in exchange for paying a tax on anything they monetize, of course).
Mass consumer successes are very rare. By definition, that makes them valuable.
Few products appeal to the mass market. When they do, it’s such a rare event that it’s inherently valuable. A mass consumer success is a Black Swan event.
Many business offerings turn out to be niche offerings or a large number of niches bundled together to create a “large” market. Successful consumer companies create one product. It may come in different forms (Apple) or skins (Zynga) but it follows one theme that appeals to all.
What about business companies?
All of this begs the question, is there upside in building business companies, when the market values consumer companies more? As just one data point, if the rumored $5B valuation for the impending Dropbox round has merit to it, then absolutely, yes – when it comes to building companies at the intersection of consumers and business, that is, Consumer IT. These companies benefit from network effects and the resulting customer adoption leverage (that is, lower costs of adoption), in much the same way that consumer companies do, and the market values that.
For companies that have very limited adoption leverage (and correspondingly higher costs of adoption), however, the potential market valuations are lower. Valuations hinge in large part on adoption, adoption leverage, and associated costs, and these companies don’t have a way to access that. Their exits are most likely to existing players that have the distribution channels (e.g. adoption leverage) tied up.
From a professional investor perspective, these companies are often mis-priced since they lack the Main Street appeal and valuation drivers of Consumer and Consumer IT companies. That, however, presents an opportunity to generate return multiples in this area with lower risk. Eventually the gorillas buy these companies; and while they may not pay Main Street prices, they do pay. Such exits require patience, consistent revenue growth, and proven operating margins – that is, strong business fundamentals.
Mass consumer successes are Black Swan events. Together, the 3 M’s, network effects, and scarcity cause the market to give them 10, 11, and, yes, 12 digit valuations. Building a Consumer IT company? Focus on adoption leverage and reap the resulting valuation benefits.
The advantages of category leadership are obvious. Investors (private and later, public) want in and are willing to pay for the privilege. As a result, category leaders can raise more capital on better terms than any other player in the market.
They have pricing power. Because they’re #1, customers and users want to go with them, so they can charge a premium, even if their products are not as good as others on the market. And of course, their brands are the most well-known, so user and customer acquisition costs are lower.
But what if you’re not the category leader? With the market white-hot, time is quickly running out for companies to move from #2 to #1 in the current cycle. It’s the elephant in the board room, the difficult question no one really wants to ask. We’re #2: how do we become #1? If you don’t answer the question, #1 will answer it for you.
Here then are six proven ways to move from #2 to #1.
1. Sell. Many think of this answer as a cop-out or giving up. It seems like sacrilege even to put it on the list. But from the point of view of delivering shareholder value (not shareholder ego), it’s quite conceivable this represents a high value strategy. Hypothetically, if #1 is worth $100B and #2 is worth $10B, #2 “only” has to sell for 10% of #1’s value to be worth the same amount.
When thinking about this option, it’s important to consider market timing:
A) Is #1 still on the rise in a growing market? Have they out-executed, out-capitalized, or out-captured network effects to such an extent that they’ve clearly pulled away from the other players, making a pivot necessary?
B) Is it still jump ball? #1 is in the lead, but the category is still early and it’s therefore still anyone’s game?
C) #1 has held that position for a while, is stagnating, and is therefore ripe for attack.
D) None of the above. “We’re in it to win it!” In that case, read on.
2. Shatter the myth. In some cases, #1 by all measurable accounts (revenue, market position, number of users, capital raised, etc.) is #1. But in less developed markets, it’s often more marketing than reality. This happens to “all steak no sizzle companies” who get outmaneuvered by companies whose products aren’t as compelling yet get all the buzz.
Up your profile, get visible, and market like crazy. Every time #1 is mentioned, you want to be mentioned. Shatter the myth through marketing, PR, and customer acquisition. Implement a partner strategy to make yourself bigger than you are alone. Make your reality the market perception.
3. Turn the #2 position into an asset (until you’re #1). This is the Avis “we try harder” strategy. Deliver a better product at lower cost with better service. Organizations with existing products simply cannot move as quickly. They have to consider their existing user, product, and cost investments when making changes. This is the quintessential startup strategy: be more nimble than #1.
4. Make it easy to switch. A trail first blazed by Excel/Notes and Word/Wordperfect, these products made it easy to switch by implementing the same keyboard shortcuts as existing products. With little to no behavior change, users were able to do everything they’d always been able to do and take advantage of a host of new features as well. More recently we’ve seen this in the form of email and contact importers, which make it nearly friction-free for users to take their contacts with them. Features like importers and migration tools may seem unglamorous to build but they’re pivotal in getting users to switch.
5. Be open when others are closed. This is the Android strategy. You can’t out Apple-Apple. Their products are elegant, easy to use, and supported by the incredible marketing power of Steve Jobs and the Apple brand. They are also closed. Provide the other players (that is the other phone manufacturers and wireless carriers) in the market with a viable alternative, and you can quickly establish yourself as an alternative. This works especially well in markets where the existing ecosystem very badly wants there not to be a single-source winner.
6. Team up with numbers three through 10. With the right capitalization strategy, you can go on the offensive, acquire some subset of numbers three through 10, and voila, you’re #1! Proper investor backing and valuation are critical to this approach, along with an organization that can execute on it. But acquiring your next largest competitor is a time-proven way to accelerate customer adoption, revenue, and growth. Just make sure your organization doesn’t get indigestion!
Category leadership has proven time and time again to deliver the most value for investors and entrepreneurs alike. Being #2 can certainly be a lucrative (if perhaps not emotionally fulfilling) strategy, but all too often startups that could become #1 miss their window of opportunity. They let the market move faster than them. Don’t let it happen to you: use the approaches above to move faster than the market.
Spending time on various projects, from social games to B2B services, I work with a lot of offshore developers. Many people have heard about services like ODesk and Rent A Coder and ask me how to get started. The short answer is: carefully. The long answer is below.
Bad engineering is a mess that can take forever to clean up, if it can ever be cleaned up. Bad development practices mean everything from bad naming in database tables and code variables, to lack of scalability, to, generally speaking, code that can’t be read or maintained.
Conversely, a world-class developer can practically read your mind, seems to be always one step ahead of you, and has suggestions for both design and architecture. When it comes to offshore development, great developers treat the code and your project overall as if it were their own. They think about maintainability, scalability, and design.
Are You Technical?
This is the first and key question for many people thinking about using Odesk, Rent A Coder, or other services. If you are, you can write detailed technical specs, review code that gets written, and provide detailed feedback to developers. If you’re not, you must find someone technical you can trust to fill that role. That trusted technical peer can be an engineer you hire, or a local colleague or friend.
Have you managed a software development project? It is one thing to have someone knock out a prototype. It is another to build something scalable and maintainable.
A Clear Vision
If you have already done market or user research to confirm people want what you intend to build (see: Lean Startup!) – that is a big if – you need a clear vision of what you want to build. By clear, I mean you can write down in a sentence or two what the goal of your product is and why people will want it.
Design First, Implement Second
A clear vision also means you can draw, in pictures, the screens for your product. If you’re building a game, for example, you have clear views on the game elements, goals for the players to achieve, and specific graphics. For a web site, you have a view on everything from the overall goal, to the messages that will appear on the home page, to the flow of the site, to the individual pages and the look and feel of the buttons. Yes – all the way from the big vision down to the size, shape, and color of the Pay button. When you think product design, channel your inner Steve Jobs.
Odds are, you will not have good success with the first developer you choose. Don’t hang on. Don’t hope it will get better. Look at the data, then act on it.
Ratings matter. Rarely should you expect to have success with an engineer who has multiple failed projects, negative reviews, or arbitrations. When choosing developers, look for those who have clocked multiple successful projects on Rent A Coder or hundreds if not thousands of positive hours on oDesk. Tempting as it may be to hire the first developer or development team that responds to your project, it’s better to wait and find greatness than settle and ultimately have to restart the project.
If you send a message to a developer and don’t hear back for days, don’t hope it’s going to get better. It’s not. If the UI of the prototype you get looks terrible, don’t assume the developer knows that and is going to tune it up. If your developer fails to pay attention to details, despite your enumerating what those details are, that developer is clearly not into the details. Again, look at the data.
If you have specific ideas – and you should – on what the UI should look like, mock up the individual screens down to the very last detail. If you don’t do this, don’t be surprised when the design you get back is not anything like what you had in mind!
Of course, the best place to find great engineers is other great engineers. Don’t settle until you find a great engineer. You will know the developer is great because the work you get back shines. It puts a smile on your face. The developer clearly takes pride in his or her work. It’s obvious. Now, ask that developer if they have friends or colleagues who are looking for work. Hire them. Some will work out, some will not. Hold onto the good ones.
A note on large development shops: although people do have success with these, you really have to get lucky. What’s more, these developers are much more likely to work a fixed schedule and not have the flexibility you need to make a project successful when you go from prototype to product. Likely you will have better success with individual developers, smaller shops, or loosely associated smaller groups of developers.
Managing The Project
To manage a real project, large or small, you must have tools: tools for communicating, collaborating, tracking, and reporting. Assembla, Basecamp, Unfuddle… there are many tools to choose from. Upload mockups to your wiki. As items are completed, test and ticket. Stay on top of completed work, don’t let it linger. Spec out big features, but break them down into smaller pieces to get them done.
No matter what you do, you are sure to encounter The Case of The Missing Developer! No – this is not some modern day Sherlock Holmes story. This is when a developer that seems to have been making great progress disappears. No email, no code check-in, simply poof. This is because many developers on Odesk and Rent A Coder are working multiple jobs, are in school, simply lose interest, or have things happen that get in the way.
A significant challenge for developers is that they don’t know if your project is going to be around long-term so it’s hard to commit to your project full time. Once they’ve spent time working with you, and you’ve proven to be a reliable and consistent source of income and someone they enjoy working with, they’re more likely to dedicate themselves to your project 100%.
This leads to the other key aspect of project management – it’s a two-way street. Treat developers well, take the time to explain the rationale for your designs or approach, and you’re far more likely to get great results in return.
There are multiple approaches to resource management. You can do the whole project offshore. This is very hard to do unless you have worked with the team before. An excellent approach is to build the core with a local engineering team, with modules built by offshore resources. It depends on the size and scale of what you’re trying to accomplish. All that said, be clear with your expectations and then look and act on the data. If the project is not going well, it’s time to reevaluate the team, the project, or both. If it is, then scale, scale, scale!
One of the biggest challenges every startup faces is switching from startup phase to scale phase. In the true startup phase, you’re throwing a ton of stuff at the wall all the time and seeing what sticks. Before you have users or customers in volume, you have to think about repeatability and scalability.
To think about and implement things like test and production environments, scaling, redundancy and the like, you need multiple engineers and engineers with different primary skillsets. You cannot scale on one outsourced developer and probably not even on one outsourced development team. The challenge with relying on a single outsourced team is much like the challenge of relying on a single outsourced developer: you have a single point of failure.
This is where many people who start out with ODesk, Rent A Coder, or other services run into challenges. Simply put, more scale requires more resources. It is by no means linear (Facebook: 2,000 people, 600M users), but scale requires people.
If things seem to be taking too long, you need different engineers, more engineers, or, it’s time to face the reality that your project is too complex. Go back to the KISS rule, that is: Keep It Simple, Stupid!
Complex projects stay “in the garage” for a long time. They don’t see the light of day and they fail to get user feedback. Then, when they’re put out on the market, they flop. What’s more, they’re hard to maintain and iterate. Focus on core features. Get users. Get feedback. Repeat.
Great projects, like great entrepreneurs, get feedback early and often. There is significant feature failure as they iterate and determine what works and what doesn’t.
The Timezone Challenge
Many people ask how they can communicate with engineers who are twelve hours off from them. The answer is get up early, stay up late, or do both. Document what you want done. Schedule a regular Skype call or IM catch up one to two times every week. Reliability and consistency on your end will produce the same in the developers with whom you work.
One tradeoff with offshore development is that it is that much harder to whiteboard out an idea or make a quick change. It requires more management overhead. You are dealing with different timezones and must have clarity on what you have in mind in significant detail. That does not mean writing age-old 100 page specs. It does mean, however, that a quick spec – a brief writeup in a wiki page plus a drawing, by hand or on the computer – goes a very long way.
Much has been written about the pro’s and con’s of using offshore development resources. Whether to use these development resources is up to you, but should you decide to, you now have one more resource to help you get started.
Services like Rent-A-Coder, eLance, and oDesk have long held the promise of distributed and efficient work resources. With communication and collaboration tools easily accessible and hosted, just like the products they’re helping to build, such promise is fast becoming a reality. Of course, building a product is only half the battle. Getting people to use it is another story!
A great pitch is all about telling a great story well. Recently, a number of entrepreneurs have asked me to help them with their pitch, business strategy, and market positioning. An avid short story writer since a young age, there are few things I enjoy more than helping technology entrepreneurs tell their stories. It’s even more fun when that coincides with a financing or liquidity event.
As an investor, I’ve seen hundreds of pitches. As an entrepreneur, I’ve put together more than a few myself. I never thought that might be an avocation, however, until I was reminded by an entrepreneur friend of mine, “You basically wrote our Series B pitch in 15 minutes on the whiteboard.” He raised eight figures the next week. Then, I was meeting with the founder of a highly in-demand company several weeks ago. “Help me build my pitch. It’s what you do.”
Tech, as I wrote in response to a WSJ article in January, is hot again, and it’s likely that we have about three more good years ahead of us. What happens after that is anyone’s guess. That means raise big now with the implied goal of getting public, position to get bought, or plan on digging in for seven to 10 years through another cycle.
Raise big. To raise big dollars on a big valuation, you have to be hot. In a momentum market like the one we’re in, hot comes down to massive reach, massive revenue, or massive disruption.
You can also, of course, raise money on the promise of massive disruption. If you’re doing that, you need a catalyst. Something that wasn’t here a few years ago, that enables you to disrupt massively and quickly. iPads, location-aware smart phones, and pervasive social graphs are all good examples.
Get bought. To get bought, you have to be visible. As Steve Blank said, in the new bubble, “you need to be everywhere and look larger than life.” Of course, you also need to be in an area buyers care about. Corp dev execs flush with cash or high valuations are making two kinds of buys right now: talent and traction.
It’s not enough to have a great story alone or to be a great story teller. You have to have a great story and tell it well. Do that, and whether you want to raise big or get bought, you’ll accomplish your goal.
Startups spend a lot of their hard-earned venture dollars on customer acquisition. A few years ago it was enough to be smart about search engine marketing and optimization. Buy keywords, put landing pages up on your site, integrate with Salesforce, do a little PR and if there was interest in your product, you were off to the races. That is no longer the case.
In a noisy environment, it’s not enough to be well ranked and buying keywords. The most successful marketing strategies today have seven key components:
Product. The number one factor in marketing success is great product. Deliver a bad product and people will write about it and talk about it. Today, there is no hiding from bad product. Customers won’t just call customer service to complain, they’ll post, tweet, and even create YouTube videos like the well-known United Breaks Guitars.
A great product is one that is easy to use, self-explanatory, and delights your customers and users. Apple has a great brand not only because of brilliant marketing, but because fundamentally, the company’s products are intuitive, incredibly well designed, and pleasing to the user from start to finish. From purchasing to unwrapping to using, and then doing more purchasing, Apple delivers a best of breed experience.
What’s more, Apple’s products grow with you. A new iPad user might not realize that swiping left brings up search, but over time will figure that out. Seemingly small things like making more advanced features discoverable not only provide a great experience but also provide users with a reward, that “ah hah” moment when they discover a new feature themselves.
Viral. To make your product viral, make viral your product. Just imagine Facebook or YouTube without user uploaded photos and videos and the ability to share them easily. Unlike other marketing techniques, viral is built-in and free. With viral acquisition, your users acquire you more users just by using your product.
Not all products are truly viral from the ground up, but by giving your users the ability to invite their friends, make money, get a discount, or get free capabilities such as free storage for every user they refer, your site or app can take advantage of viral marketing. You can go one step further by adding in special features only available to those who get their friends to sign up. Viral executed well delivers near zero-cost user acquisition.
One compelling form of viral is media sharing. If you have a product that requires users to share what they’re doing (documents, images, or links, for example) with others, that drives adoption. Every time an existing user shares a piece of media with a friend or colleague, you’ve added a new potential user.
Social. While viral and social are often lumped together, they’re different. Social can certainly help get the viral flywheel spinning, but at its core, social is about presence, credibility, and visibility.
Social is Pages, Likes, Tweets, Posts, Blogs, Answers, Comments, and Word of Mouth. You can bring social directly into your application by combining viral and social, social and mobile. More on that later.
Fortunately, it’s easy to be social these days. Post regularly on your site’s blog. Tweet about new features, customers, and users multiple times per day. Don’t just do it yourself, enlist your customers, fans, and friends to leave comments, write, and tweet about you and your products.
Buzz. Closely related to social is buzz. Buzz means your company is visible – highly visible. To get buzz, you need to take advantage of that other four-letter word, hype. To generate buzz, it’s not enough just to tweet, post, and blog. You have to be visible: on Internet TV shows, in blogs, at big events. You have to be seen as a leader in your space, often slightly controversial or edgy. Get people talking about your company, your product, or you. Today, success begets visibility, and visibility begets success.
I grew up in the school of thought best articulated by Steve Jobs in 2003, “Our belief was that if we kept putting great products in front of customers, they would continue to open their wallets.” And I still agree with that statement. But don’t forget the 1984 Apple Superbowl commercial: not only did it create buzz, it also created an emotional connection. Fortunately, these days, you don’t need to spend millions of dollars on a Superbowl ad to generate buzz.
You can do it by being unique, social, and personally visible. Not only will that help sell product and drive user awareness, it will also help with financing activities and, ultimately, liquidity.
Search. With Facebook accounting for some 25% of US Internet traffic, it might be tempting to disregard search. But search, in the form of SEO and SEM, generates a lot of users. The challenge is making it cost-effective. With some patience, SEO work, and the right analytics tools, it’s possible to improve your rankings. In crowded spaces, spending time and effort on SEO may yield a lot more benefit than spending money on SEM.
Test, measure, and repeat. Nothing is too small to be tested, from pricing plans and ad copy to layouts, colors and animated buttons. Ask every customer to link back to you from their web site. Not all of them will do it, but enough will to help drive up your rankings and traffic. Plus, the referral traffic alone will boost sales. Add in an affiliate program to reward your customers and partners for sending people your way.
Tuning conversion before spending too much money is critical. The right product-market fit, a product and pricepoint that a very large number of people want is paramount.
Mobile. According to the New York Times, the average smartphone user spends 667 minutes a month using apps. That’s more time than those users spend talking on the phone. To reach your potential users where they are, you have to have a strong mobile presence.
Plus, there are many compelling features that are only enabled on mobile: photos and video on the go, and of course, location. A mobile app may be as much about driving awareness as about gaining actual usage and revenue.
Of course, some applications are mobile in and of themselves. The primary use cases for photo apps, video apps, and many games is a mobile one. Other applications are not inherently mobile or were not originally designed to be mobile but have added compelling mobile apps: reviews and travel reservations, for example. Not only may users want to access your offering on the go but a mobile app can also be a great promotional vehicle for you. As users search and browse through app stores, it’s just as important to be there as it is to be highly ranked in Google search results.
Brand: Bringing It All Together
In addition to great product, brand comes down to name, logo, icon, and even a single letter. F for Facebook. P for Pandora. Easiest and most powerful is to have the same company and product name. In a crowded world, there is little benefit to trying to market two brands – it’s challenging enough to market one.
Where things get exciting is when you bring it all together. Delivered an order or a product? Ask your users to help spread the word by typing in a one sentence description of why they loved your service and post that to your web site and on their wall (since you’ve integrated Facebook login). More content for the search engines, more visibility for you, all driving more potential users to your site.
When one user invites another to use your application, support the integrated ability for both users to post that to their wall or tweet it. “I just started using…” might sound corny and some users may opt out, but many will participate. That will drive up your visibility. Integrate the Like button directly into your product experience, don’t just think of it as a piece of marketing.
Take a page out of today’s social games. Surprise your users with free gifts like free storage, discounts, and more, then ask for them to reciprocate by spreading the word about your product. Instead of relegating that to the marketing section of your web site, build it directly into the product experience at the time of upload or purchase.
Ultimately, great marketing means a incredible product combined with a clear, memorable message. What’s so powerful about marketing today is that you can enlist your users in your success by making it easy for them. To paraphrase Jerry Maguire, help your users help you.
My blog, which is hosted on Amazon EC2, was down for about 18 hours due to an infrastructure issue at Amazon. I wasn’t alone. Quora, Reddit, and others were down as well.
When I started my blog, it was hosted on a server at Godaddy.com where I had registered my domain name. When I decided I was going to switch, I could have moved to a hosted platform. But I wanted to try out EC2 for a variety of reasons – not because I needed to run on EC2 but because I wanted the first-hand experience with what I consider a fundamental building block of today’s startups – Amazon’s cloud infrastructure. Plus, it was fast, inexpensive, and easy to get started.
There is, however, no button for “make this reliable,” aka, take this application (database, pages, IP address, logins, etc.) that I put on this instance, and make it work no matter what, regardless of whether my instance, storage, or network goes down. And if something bad happens, like a virus, database corruption, or security attack, get me back to where I was before things went bad, and without the bad stuff.
The real issue is that building scalable applications is difficult. People go to EBS because it is supposed to be more reliable, but one thing the Amazon outage showed is that it isn’t. And that means that applications themselves have to be built in a reliable way, or infrastructure vendors have to make it easier and cheaper to obtain reliability through failover and redundancy. The problem is, that’s a hard problem.
The problem is, when did things go bad and what was the cause? Was what looked like a little spike in database and CPU usage actually a bad bug infecting the system? Was it someone who got ahold of the admin password and hacked their way in? Or was it something lower level, like a disk error?
As with the Amazon failure, what should I do? Should I try rebooting? Should I restore a snapshot (whoops… the snapshot is in the same zone as my instance and primary storage and until some changes were made, I couldn’t restore across zones). If I take any of those actions will it improve things or just make them worse?
The Ideal Scenario
What I’d really like is to put my application (in this case, WordPress) out on my instance and know that somehow, magically, it is being deployed reliably, and if anything does go seriously wrong at the application level, I can get back to the point a little while before things went bad, perhaps even changing usernames and passwords before it comes online. In theory, that’s what the cloud is supposed to deliver: highly reliable, on-demand compute and storage capacity. That’s easier said than done. The ideal scenario simply isn’t possible today.
In fact, I really don’t want to have to deal with instances, storage, and networks at all. On Amazon, I have to choose between small, medium, and large instances. But what I really want is to be able to say, give me another unit of compute, another unit of storage. If CPU usage is high, give me another few units on demand and also notify me that something’s going on so I can take a look. And I want all that with the security that separate instances provide: one instance doesn’t corrupt another, apps can be separated from each other, databases can be separated from each other; and my points of failure are reduced.
That in fact, is what EBS is supposed to provide, when it comes to storage. The problem is when the underlying infrastructure has a problem it affects everything running on top of it. What is supposed to be more reliable becomes less so – a single point of failure.
What I need is a hybrid architecture that delivers the reliability of isolation and geographic, network, and hardware diversification, but with the ease of use of true scalability; when I want more units, I get them. But if a piece of underlying infrastructure goes down, it doesn’t impact me. All at the same price I currently pay (or perhaps at a very slight premium).
Throw in easy backup and restore, and a button I can push that will put up a “this site is temporarily down for maintenance” page (hosted elsewhere but without me having to pay for a whole other instance), plus the ability to bring up my new stuff while leaving the old stuff intact until I’ve verified that the new stuff works, and a built-in “scalability” simulator that takes a copy of my entire site, back-end, and infrastructure, right down to the hardware, and tests it at all the different points of failure, and you have a winner.
Sure you can pull a number of pieces together to do all this, but a one-click solution available to web sites large and small? Like I said, easier said than done.
What the Amazon Outage Taught Us
What the Amazon outage really taught us is that being down for more than few hours of late night scheduled maintenance is simply unacceptable for today’s real-time startups. Users don’t care that your infrastructure provider had an issue: they blame you. With users and customers spread all around the world, there is no window longer than a couple hours when it’s acceptable to be down. And even that is pushing the limit. Frustrated, users write permanent posts and tweets, while your numbers suffer. The impact lasts far longer than the time your site was down.
Would those startups that were impacted by the outage be better off running their own hardware and data centers? Not necessarily, for all the reasons they didn’t do that to begin with. It’s expensive, it’s a lot of fixed cost, and it requires significant up front capital expenditure. It also requires not only software but hardware expertise as well – actual data centers and servers, a near constant turnover of old hardware for new, and long-term data center contracts.
No doubt startups that were impacted will be revisiting their architectures, changing their redundancy approaches, and accelerating those long-planned yet oft put-off re-architecting projects that will make them truly scalable and redundant. They may even put in more simulation tools to help them test usage spikes, infrastructure failures, security attacks, and data corruption.
But what they’ll really be hoping for is a solution that gives them the flexibility to scale with the reliability that comes from being isolated from other users of the same infrastructure, down to the physical level, at a price they can afford.
Perhaps after the finger-pointing is over and the black-eyes are done being iced, the greatest outcome will be innovative new technologies, which will eventually trickle all the way down to today’s single instance, single application user, whether it be one of millions of small business owners hosting web sites, or a blogger like me.
- July 2015
- June 2015
- January 2015
- October 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- April 2013
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- November 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- September 2010
- August 2010
- July 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- March 2009
- December 2008
- November 2008
- October 2008
- August 2008
- July 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- March 2006
- December 2005
- October 2005
- July 2005
- May 2005
- April 2005
- February 2005
- November 2004
- October 2004
- September 2004
- August 2004