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.
- 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