Winning Attitude, Losing Attitude

I have a friend who has wanted to start a startup for years. Every time he comes up with an idea, he subsequently talks himself down: the market isn't big enough, the timing isn't right, he can't find a cofounder. The reasons are always different, and are always logical.

This is a loser's attitude, and unfortunately it is shared by millions. It is why our risk-adverse society systematically over-rewards those willing to take perceived risks. When you look for reasons not to do something, you will always find them.

I have another friend who came to the Bay Area with the dream of starting a startup. He had no college, no programming ability and no connections when he got here. He got a job serving ice cream, moved on to join a startup, then started his own company after two years. The company is now doing 2 million in annual revenue a year and a half later.

When you approach a challenge with the foundational belief that you can do it, you have a much different mindset than  when you approach it with the idea that it is impossible. In the former case you almost always figure out a way, in the latter case you almost never do.

Those with a winning attitude get started and figure out how to get things done. Those with a losing attitude worry about failure, and never get started.


If you liked this post, follow me on Twitter and Facebook for more articles.

Management Lessons the Hard Way

A lifetime ago in a galaxy far, far away my cofounder Michael came to me and gave me an intervention. We had a problem, he said, employees were unhappy. People were getting burned out and there was an increasing rate of attrition. "What do you want from me?" I replied exasperated, as our conversation became heated. But he didn't have any answer, outside of seeing the symptoms of something deeply wrong.

As our most important conversations typically go, I eventually got over my wounded ego and realized that he had a key insight here. The things he mentioned were serious and indicative of a lack of leadership that was caused as much by the things we weren't doing as were doing. We had created the startup equivalent of Lord of the Flies, complete with new employees getting thrown into a foreign environment they are completely unequipped to survive in and then getting bashed in the head with a rock. We the founders had operated the company with little direct management for years, under the pretense that we were empowering employees by letting them work on things they wanted to do. In reality, we were often stepping back just enough to been seen out of the eye's periphery, often to jump in without warning when things weren't following unsaid directions. Anyone who has experienced this before knows that it is liable to make you a bit twitchy.

In the next month, Kevin, our COO, talked to everyone in the company and gathered feedback that might not have been directly shared with a founder. Here's the typical project workflow, version 1:

  1. Vague problem definition: "Create an automated test suite for the website" 
  2. Employee defines it in some way that we didn't actually have in mind: "Create an extensible, Selenium based framework for performing every action a user can on the site" 
  3.  Employee works on that for a while, sometimes months, without feedback: "I'm making great progress!" 
  4. Manager checks on progress, has a "wtf" moment: "Wait, I just wanted something that pinged five URLs and checked for 500s"
  5.  Massive micromanagement ensues: "OK, clearly you don't understand what we're doing; I'm going to have to take over"
  6.  Massive employee disenchantment: "WTF just happened?"

With a lot of help from our new VP of Engineering, Chintan, we created a plan for addressing our most egregious issues. Many of the lessons we learned could probably have been prevented had we picked up a management or communication book or two. But as always, the lessons you hold dearest to heart are the ones you've learned yourself the hard way.


Signs you might have a problem, and that the problem might be you:

  • Employees burn out after months. Team members work increasingly less on average as they spend more time at the company.
  • Lots of people seem to be implementing projects in ways that you didn't want, or that don't meet the goals you had in mind.
  • You feel like people aren't getting anything done, even though you employ lots of people, all of whom are smarter than you and just as hard working.


    How to not fuck up:


    Empowerment doesn't mean letting everyone do whatever the fuck they want

    If you listen to words and not the meaning, a lot of startup talk seems to say that you should just get a lot of smart people together and let them do whatever they want until something sticks, and that is a recipe for success in everything (product, team happiness). This is wrong. So wrong. Creative comes from constraints and direction. For us, the hard part of this was to actually define the problems / goals we were attacking and then ruthlessly refuse projects that didn't address these. Instead, we found it so much easier to just say yes whenever someone suggested something, but then let it die later through neglect, lack of interest, on purpose, or otherwise. This is a horrible idea, because it not only communicates an utter lack of focus but it is completely and utterly opposite of honest communication, and leads to people feeling betrayed, and rightly so. Instead, you should:


    Provide a problem and framework, let employee figure out the solution

    At the end of the day, smart people mostly aren't motivated by money or titles in the long term. Motivators like those are like buying new possessions; after the newness wears off, so does the appeal. Daniel Pink does a great job outlining what motivates people in this video: mastery, self-direction, and purpose. In a product engineering organization, those things fit together if you provide employees with an area they can be an expert and make local decisions in, but that also fits into a larger purpose or problem. Many of the problems that we've experienced stemmed were because we sacrificed one at the expense of others; for example, allowing people to pick projects (self-direction) that didn't fit into our company goals (purpose).


    People want to have input. Cheer up, this is a good thing; it means they actually give a shit.

    But how do you reconcile the fact that smart knowledge workers want to have self-direction, but ultimately you have to say no to things that don't fit address the company goals? Bewilderingly enough to the average entrepreneur, it turns out that people are ok with "no." Most smart members of a team want to have input, but don't need to make every decision themselves. For us, having regular brainstorming sessions where everyone could generate ideas for a product in a given area was a good pressure valve for contributions; those ideas were then taken and curated by our product managers into a cohesive product.


    Having a hierarchy isn't a bad thing. Having no idea who has the final say is a bad thing.

    Because you need to stay on target and only do projects that address your goals, it is important that there be a limited number of people who are responsible for setting those goals and are responsible for certain decisions. This was a hard thing for us to grasp; in the early days of the company, we made decisions based on consensus (translation: through massive intracompany arguments). Team members didn't know who was responsible for various product decisions, and often times this lead to inconsistency and paralyzed the engineering process. At the end of the day, the egalitarian spirit in us had trouble saying "Person X is in charge of product decisions, Person Y is who you should tell if you need to take time off." But, in the end, it saves a lot of mental processing for everyone once you add these types of rules, and ultimately decisions get made in a much more fair and transparent way.


    Don't micromanage. You're probably not nearly as smart as you think.

    If you founded a company that's big enough to have management problems, you probably think you're a full on genius by now. Yes, to the public you might appear humble (I might as well!), but your college buddies are probably pushing paper and ticking off days to retirement while you started something that is surviving based on your sheer effort and wits alone. You've probably also been making most of the decisions yourself up until this point. Thus, while you've heard you shouldn't do it, micromanaging the team is probably tempting.

    But don't do that. In your heart, you know it is wrong. You hired smart, creative people who don't want to just color by numbers. For me, when I objectively looked back at details I had micromanaged months later it was pretty clear I hadn't been making anything better. Instead, get rid of people you don't trust enough not to micromanage. If you look around and that's everyone, then the problem is probably with your control issues.


    Instead, provide regular and expected points where others (management, peers, etc) get to have input / oversight, and DON'T SKIP THEM

    At the same time you are stepping back from micromanaging, you can make sure you get an opportunity for oversight by making it part of the process to have check ins where you (or others) get to give input. For, this meant scheduling regular spec / architecture reviews before beginning projects and code reviews at natural milestones. It is critically important that these be consistent: consistency manages employee expectations and makes your process not arbitrary.


    Meet regularly not just to talk about code.

    Since I'd never worked at a real job before starting a startup, I didn't understand the purpose of basic management processes. I thought meeting regularly with employees 1-on-1 without a purpose grounded in a decision that must be made was a massive waste of time. It's not. Meeting regularly just to discuss how things are going, what team members feel like they are getting out of the job, feel out potential issues, and gather feedback can give you a chance to discover brewing issues before they become massive problems. Also, it gives people the opportunity to share their ideas and feedback in a consistent environment, and let them know you care about hearing their ideas.


    Let the team know your motivations.

    An employee who joined the team two years into the company's history doesn't have the same motivations as the founders. Team members who are implementing one part of a strategic vision don't necessarily see the whole picture (not because they couldn't, but probably because their jobs might not afford them all the information and time needed to consider it). One simple jewel of advice given to me by one of our senior software engineers, Joseph, was that if we shared our motivations as decision makers (e.g. "We're working on this project to generate revenue in the short term, instead of infrastructure improvements because we're trying to hit a short term revenue goal of X") it helped him get understand why he was working a project, and which aspects of a project to spend time thinking about improving. In previous eras, we had asked ourselves why employees weren't coming up with ideas that were in line with things we wanted to do. Turns out it was because we weren't explaining what we wanted to do. When we started doing so, it turns out most of our best ideas started coming from people who weren't the founders.


    Communicate assertively.

    A more general version of letting your motivations be known is just generally communicating assertively. When I first started managing people I was not explicit about expectations or deadlines. This was because I was scared about imposing my demands on others. Unfortunately, this leads to you being upset because things you took for granted (product questions, timelines, etc) weren't actually explicitly communicated and thus weren't followed. You can change this pattern by taking the time to communicate effectively. This is one of my favorite books on the subject of communication.


    Your job as a manager is to provide leverage for other team members, not do work yourself. 

    For me, there is a massive temptation to program things myself. I like programming. But once you become a manager you must resist this temptation.

    There are people whom I manage who can get programming tasks done 10x as quickly as I can. Efficient allocation of resources dictates that I should not be programming; if I can provide 10% more productivity by boosting said programmers output (say, by removing communication blocking time or better defining a spec) then I have already made back 100% of my time if I were to spend it programming myself. If I do this for everyone on the team we are all better off than had I just been programming. This is the comparative advantage that comes with specialization: management bandwidth is a product, even though it might not feel like it.


    I am clearly not a management savant. I like to think that I'm good with people, but I know I'm not amazing. I don't particularly love management, except as an instrumental tool to creating a cohesive, productive team that makes great products. Doing many of the things I've listed above, particularly remembering to do them consistently, has been difficult for me to adapt to. Often, I would forget what management tasks I was supposed to do and focus instead on something I shouldn't have been doing. In order to make sure to do things consistently, I found myself following the advice that I should create a checklist of things to do ("Is anyone blocked on anything?", "Do any meetings need to be scheduled?", etc); one for the beginning and one for the end of the day, and follow it religiously. It is still on some days a struggle.

    Writing this essay has been cathartic, because it is the truth. I owe a great debt of thanks to Chintan, who had the unpleasant job of dragging me kicking and screaming through the coals to becoming a decent team leader, which I resisted the entire way; my cofounders, who supported the plans we came up with and had faith I could figure some of these things out; and most importantly the employees who had to put up with our extremely poor management prior to many of the realizations we had as the company's leaders, pretty much all of whom forgave our faults. Without all of these people, I wouldn't have made progress becoming a better team leader. But vastly more importantly, without them I wouldn't have grown into the person I want to be.

    How to build a great mobile development team

    It doesn't take any massive insight to see that the mobile industry is heating up. Mobile gaming companies are getting acquired, mobile media sharing companies are taking down massive funding rounds. With the excitement, there has been a massive demand for talented engineers to write apps for iOS and Android, which are currently extremely under supplied in the market. Scrolling through my list of gtalk contacts, about 1/3 of them have referral links to their startups for "great mobile developers."

    Despite the difficulty hiring great mobile engineers, I feel confident saying that we have an amazing mobile team at JTV. We released our first app for iPhone exactly a year ago. Since then, our mobile apps have collectively been downloaded over 4 million times across Android and iPhone. Recently, we released Socialcam for Android and iPhone which were built on both platforms in just under 2 months from start to finish.

    How did we go from a company with no mobile experience to one with thriving mobile apps in just a year? At first, we gave a half-hearted try at recruiting mobile devs with experience. Unfortunately, we quickly learned that they were few and far between, and all working on their own projects! In the meanwhile, the mobile ecosystem was heating up and we desperately wanted to get into the space and plant a flag in mobile video. What in heaven's name were we to do?!

    We ended up taking the approach we have always taken at JTV to solve every problem: we hired or repurposed smart engineers to work on our mobile apps who didn't necessarily have a ton (read: any) experience. Our philosophy has always been to hire talented engineers with strong programming backgrounds and let them work on areas of the company they are interested in, regardless of domain experience. Subsequently, we grew our mobile teams to 2 iOS engineers, 1 Android engineer, and 1 mobile product designer. 

    Mobile development isn't rocket science. For the most part it isn't even computer science. What we discovered while building a web company is that web development isn't a dark art; talented programmers can figure it out easily. The same is true of mobile platforms. Find some smart hackers and start hacking.

    If you want to work on great mobile apps, we're hiring strong programmers at Socialcam to hack on iOS and Android (whether you have direct experience or not :D). Come be part of a small, talented team that moves extremely fast.

    Selling Kiko

    I told this story to some new people the other night, and in its retelling I realized that it might be more interesting than I thought. I've already chronicled getting funding for Kiko, the first ever AJAX web calendar, from Y Combinator, as well as how we ended up starting What was left out was how transitioned out of the business. 

    When Emmett and I were winding down Kiko we thought a lot about what we could do with it. Eventually, we decided we would start a new company, but had to close Kiko, which had several angel investors including YC. We had a bit of cash left in the bank, but felt a great deal of responsibility to return as much money to the investors as possible.

    While brainstorming how to do this, I had the idea that we could cleanly liquidate our assets by selling everything on eBay. I wish that I could say the idea was original, but the previous year a site called Jux2 (which showed search results from both Microsoft and Yahoo) sold itself for $105,000. We figured if we could recover even $50,000 we'd be able to give the money back to the investors and walk away with a clean conscience.

    We set up a 10-day auction. In the description we included what you were getting (the domain name, source code, and user base -- which had around 70,000 signups but almost no actives), and what you weren't (Emmett and I as employees). We also offered to do a week of integration consulting for $3000 of travel expenses, at the buyer's option. We listed the whole thing for $49,999.99.

    We posted the auction on Reddit and, with the help of a few friends, got to the front page. Back then Reddit was much more like Hacker News in its focus on technology and startup related news. Pretty quickly the story was picked up by Techcrunch, John Batelle's blog, and some other tech related sites.

    The auction turned out to be a much bigger story than we'd expected. Apparently no one remembered Jux2's sale and we were credited with coming up with the idea -- something I'd taken pains to correct whenever anyone cared to ask. Pretty soon lots of people were writing to us to ask about the auction, more details about the technology behind Kiko, and other random questions. One person wrote us imploring us to open source the code instead of trying to make a few bucks off of it. To be honest, it's probably good for the OSS community that our unintelligible spaghetti code wasn't released into the wild. God forbid someone actually try to use it...

    After a few days of fielding questions we were wondering if we'd get a bid, but there wasn't much else we could think to do. But then we did! Our minimum, 50k! Emmett and I were excited and somewhat incredulous -- we had only half expected this to work and were doing it as a last ditch liquidation effort.

    Then, in what was probably the biggest web failure I've ever personally experienced, eBay cancelled our auction. I was notified by this fact when Jessica Livingston at YC emailed me asking if we had already sold it because the auction page was down. Digging into what had happened revealed that eBay's terms of service only allows for a single link to be included in the description, and we had included two: one to the domain proper and one to the API.

    This was unbelievable to me. First of all: multiple links, why is that so bad? Second: why wouldn't they just contact us and ask us to change it instead of wordlessly canceling the auction? Third: why wouldn't they just not allow you to create an auction with more than one link in the first place? You can do that in a single line of code! Having a $50,000 item cancelled was the worst possible thing eBay could possibly have done to us; we were convinced that we wouldn't be able to get our bidder back. 

    In the end reaching out to eBay through official and back channels did nothing. I ended up creating a new auction with a shorter length to attempt to mirror the original end date, then I contacted all the people who had been asking questions and blogs who had written about us and gave them the new link. We prayed for the best and decided to take a vacation to NYC that weekend to visit friends. The auction was set to end Saturday.

    We got the minimum bid back and breathed a sigh of relief. A couple days later it was the morning of the last day of the auction, and we were still at the same bid. The number of technical calls I'd been fielding had been heating up to several a day, and I still had some that morning, so I was up early watching the auction. Around 8 or 9 it jumped -- we were at 80!

    Exciting times. I think it was 90 degrees in New York that day. I was sitting in my underwear in some of my college friends' shitty East Village apartment, where four of them lived and three of us were crashing. Every few minutes I would click refresh on the eBay page hoping for a miracle while everybody else watched on amused. Emmett was at another friend's place in Brooklyn, so we weren't even watching the auction together.

    An hour left to go. It jumped to 100k. I ran out and yelled something unintelligible to my friends. A few minutes later it was 113. I was a genius. 150 with 15 minutes to go. I had just invented a new business model for web startups across the globe. 

    In the last 10 minutes it jumped over 100k to 258. I was on the phone with Emmett literally screaming. My friends were cheering. I felt like I'd won the Superbowl. I was a rock god.

    Final price: $258,100. Buyer: powerjoe1998, who turned out to be Elliot Noss, CEO of Tucows, with whom I'd had a few conversations. He called a few minutes later to congratulate us. That night I partied like it was my last night left to live.

    The Aftermath

    There were a few practical consequences to selling on eBay:

    • We should have had an actual contract attached to the auction. Tucows wanted a ton of warrants that we didn't want to provide, and the deal almost fell through after the fact because of it (and took a lot of lawyer-hours to negotiate). It also consumed a lot of my time.
    • Tucows bought Kiko to resell to ISPs (whom they already provided white label webmail services to). We went to Toronto to do the integration week with them. Toronto is a beautiful city.
    • If we'd wanted one, this would have been the best way to get a job ever. About 20 different people and companies reached out to us because they had heard about the auction. This included really big successful ones as well as many small startups.
    • We got to be in a bunch of press, which was probably the first time we got significant coverage for one of our projects. Lots of people wanted to write about the auction, including the Financial Times. I recall that I was obsessed with telling reporters that our next project would "change the way people think about the Internet" and trying to get that specific line in print (I was secretly referring to Eventually I managed to.

    Why entrepreneurs should love rap music

    I love pop music. Most of all, I love rap music. And I'm not talking about backpack rappers like Common or Kanye West; I'm talking about rappers who rap about flagrantly commercializing their music, doing whatever it takes to make it (even if that includes robbing or selling drugs), and are disrespectful to just about everyone. Among my circle of over-educated, yuppie friends, this is viewed with something between a mild embarrassment and a strong distaste. But I'm tired of hearing about Ben Folds, Vampire Weekend or whatever hipster band you happen to be listening to right now. I'm a fan of 50 Cent and Rick Ross and I'm just going to come out and say it (and not just at parties or because it happens to be on the radio).

    Rap music is music for entrepreneurs. Other genres write about love (rock, r&b), unattainable love (indie), nothing at all (electronic / dance), or redneck issues (country). But only rap music is almost maniacal in its focus on success, the acquisition of money and subsequent dispensation of it. Like startups, rap might be one of America's last great meritocracies. In the rap world, like the startup world, rappers are rewarded based on a combination of hard work, skill, marketing, and timing. Almost all famous rappers came up from humble backgrounds (Notorious B.I.G, Tupac, Jay-Z, Eminem) but through the aforementioned achieved amazing commercial success.

    Here are three reasons I love rap music as an entrepreneur:

    • It's all about hard work. In songs like Girl (Paul Wall) or Light Up (Drake), rappers espouse "staying 25/8 on your grind" (it's better than 24/7!) and grinding for days on end. While this might not be sustainable or healthy, it's definitely motivational!
    • Rappers understand marketing. In Moment of Clarity, Jay-Z blatantly states he dumbed down his music to appeal to a broader audience. No artistic pretentions here, just iteration of a product to appeal to a mass market!
    • The rap game is all about timing and a little luck. Just like innovations in tech, rappers ride on big waves, generally around certain geographical areas or musical trends becoming popular. Being in the right place at the right time is important!

    Do you love rap as much as I do? If you work at a startup and love rap music for its hustle, give me some love.

    Why starting was a really bad idea but I'm glad we did it anyway

    This post appeared on Techcrunch as a guest post earlier today. It might be the greatest day for my writing career yet!

    Right now I'm neck deep in product launch mode, putting the finishing touches on our new mobile video application - Socialcam. Of course, I’ve been here before...

    Years ago when we launched the show we had no idea what we were doing. This much was obvious to anyone who watched. Outsiders attribute far more strategic thought to us than we deserve: that we planned all along to start a live platform, and that the show itself was a way of promoting that platform. While this ended up happening, none of it had crossed our minds at the time.  

    Emmett Shear and I had been working on Kiko, the first Javascript web calendaring application in the Microsoft Outlook style. We prototyped the application in our final year at Yale, went on to raise money from Y Combinator, then continued working on it for over a year. 

    Boom. Google Calendar was released, absorbing most of our nascent user base and capturing most of the early adopter mindshare. But to be perfectly honest, Kiko would have failed regardless. We were too easily distracted and hadn't really thought through the strategic implications of owning a standalone calendaring property (hint: no one wants a calendar without email). A short time later we were burned out and spending most of our time playing Xbox with the Reddit guys in Davis Square - hardly a startup success story.

    Emmett and I started thinking about possible ways to get out of the calendar business. At the same time, I was startup fatigued. We had spent over a year paying ourselves nothing. Seed and angel investment market conditions were the polar opposite of what they are today, it had been a struggle to even raise a paltry $70k, and we had failed to build a product with real traction. I was starting to think about moving back to Seattle to try something new, maybe in a different industry.

    Still, we learned a ton and it was fun to be part of the early Y Combinator startup community (then largely in Boston). We became friends with Matt Brezina and Adam Smith (of Xobni), Trip Adler, Tikhon Bernstam and Jared Friedman (of Scribd), and many others. It’s amazing to see how many of those friendships persist today, and even more amazing how well many of those companies are doing. 

    Coming back from one particular YC dinner, Emmett and I were discussing strategic ideas for Kiko, and I remember telling Emmett an idea that popped into my head: what if you could hear an audio feed on the web of our discussion? Wouldn't that be interesting to other like-minded entrepreneurial types? We kept going, and eventually the idea morphed into a video feed. Then it became a live video feed. Then it became a continuous live video feed that followed someone around 24/7. Then it had chat, and a community built around watching this live show, which was now a new form of entertainment. I was hooked.

    I couldn't stop talking about the idea. I mentioned it at YC dinners and to other friends. I even came up with a perfect name for it: On one trip to DC, I told my Dad and my college friend Michael Seibel what I was thinking. Eventually, in-between drinking sessions, we thought of a brilliant idea for divesting ourselves of Kiko, which is a story for another day. After that, Emmett and I were coming up with other startup ideas (I guess we got excited about staying in the industry after all). One particular favorite was the idea of a web app that would ingest your blog's RSS feed and then allow you to layout and print physical magazines from it. Excitedly, we drove one afternoon to Paul Graham's house to pitch it.

    We explained the idea to Paul and Robert Morris, who just happened to be at the house visiting. I vaguely recall there also being a "this will kill academic publishing" angle, although I can't figure out how that sensibly fits in now. Paul didn't particularly like the idea: he didn't think people would use it. "Well," he said, "what else do you have?"

    I said the only thing I could think of: ""

    Because it was something I was clearly passionate about, and because creating a new form of entertainment was clearly a big market (if you could invent one!), Paul was actually into it. Robert's addition to the conversation was "I'll fund that just to see you make a fool of yourself." Emmett and I walked out of there with a check for $50,000.

    Six months later, we'd recruited two other cofounders (Kyle Vogt, our hardware hacker, who we convinced to drop out of MIT on a temporary leave of absence, and Michael Seibel, my college friend from DC, who became our "producer"). We built a site with a video player and chat and two prototype cameras that captured, encoded and streamed live video over cell data networks, negotiated with a CDN to carry our live video traffic, and raised an additional couple hundred thousand dollars. Our plan? Launch the show and see what happens. 

    Now, for the sake of properly delivering my intended message, I will break out of narrative and just tell you why this was a bad idea:

    • We didn't have a plan. We loosely figured if the show became popular we could sell sponsorships or advertising, but we didn't have a plan to scale the number of shows, nor did we understand what our marginal costs on streaming, customer acquisition, or actually selling ads were.
    • We didn't understand the industry. We didn't know what kinds of content advertisers would pay for. We didn't have good insight into what kind of content people wanted to watch, either.
    • We relied on proprietary hardware that we were going to mass-produce ourselves. Smart angels told us to drop the hardware and figure out how to do it with commodity, but we wouldn't listen because we thought hardware would be easy (or at least, doable). Ironically, months after we were told this we switched to using a laptop.
    • We were trying to build a “hits” based business without any experience making hits. We knew a lot about websites, but little about content creation. Smart VCs (who took our calls because Paul referred us) told us as much: nobody really likes investing in hits based businesses, because it requires the continual generation of new hits to be successful (instead of, say, building a platform like Ebay or Google whose success is built on masses of regular users). 

    How did we get as far as we did?

    • We were passionate. We honestly believed we could create a new form of reality entertainment. Put to the side that we had no experience with creating video (or any kind of content), by God, we were going to make this work.
    • Early stage investing is often about the people, not the idea. Paul has said as much about what he looks for. As two-time YC founders he knew that we worked well together and even if we were working on something totally inane we were going to stick it out with the company and iterate until we found a business model. 
    • We sold the shit out of it. Everyone we knew was excited for Why? Because our excitement was infectious. That's how we got Kyle to drop out of school. That's how we got Michael to quit his job and move across the country.

    Ultimately, the show failed. But all told, I'm thankful every day that things went the way they did. Why?

    We built a strong team. The four of us started, and the four of us all still have leadership roles in the company. Along the way we recruited the smartest engineers and best product designers we could find.

    We were willing to learn, and to pivot. After quickly realizing the initial show wasn't a sustainable model, we decided to go the platform route, and built the world's largest live video platform (both on the web and in our mobile apps, which have millions of downloads).

    It got us started. Some people wait until the stars are aligned before they jump in. Maybe that's the right move, but plenty of businesses get started with something that seems implausible, stupid, or not-a-real-business but pivot into something of value (think Groupon). If we hadn't started then, would we have later?

    Today, I'm more excited about than I've been at any time since we launched the initial platform. Why? We're taking everything we've gathered and learned over the past four and half years building the largest live video platform on the Web (17 million monthly unique visitors in Dec according to comScore’s MediaMetrix), and applying it to tackle a new generation of problems in mobile video. Our world class web and mobile engineering team, all of our product development knowledge, our substantial, scaled video infrastructure, and everything we've learned about building engineering teams has all been put to work on a new app that we think is going to change everything. 

    Our new app is called Socialcam. Check out the site for updates on our imminent launch.