To start off the Learning to Program series with Nate Abbott and Natty Zola from Everlater, I asked them the simple question “What Was Day 1 Like?” Nate responded first:
Day one was totally overwhelming. Overwhelming because we didn’t know what we didn’t know. It’s one thing when you don’t know how to do something (e.g., validate email addresses or change a button’s hover state). But we didn’t know what we needed to learn, and that made it difficult to even start down a path. The first week was spent just googling "web site design", "web site architecture" and "web server" to try to get a handle on all of the acronyms we were coming across (such as CSS, HTML PHP MYSQL, ROR, JS, AJAX). Our goal was to piece together the list of skills that we were going to collectively learn in order to create a web service like Everlater.
Day one was also thrilling and exciting. It’s the same feeling I get when I’m starting a long bike ride in the mountains, the same feeling I got when I first got to college, or when I got my first offer letter for ibanking in New York. To me, there’s nothing more exciting than beginning a large task, and nothing I had done was quite like the task at hand.
Natty responded shortly there after with a few things to add:
We also researched sites we liked and benchmarked what they were doing/using to get a feel for what the popular/hot sites were using. Most notably I remember looking at Facebook and seeing .php at the end of the url string. This gave us ideas of where we should start our research.
I was excited like Nate, but also somewhat afraid. We quickly realized we were going to be learning another language, but much harder than a foreign language because we couldn’t rely on familiarities like verbs, nouns, and sentence structure. Worse, we would have to learn the basics of speech in becoming functional at the command line, databases, and editing programs.
The other interesting thing was that before we put any code down or started day 1 of our idea, we had spent a month brainstorming what we wanted to build. While this was pre-day 1 it enabled us to focus on making code/tech decisions and learning the code rather than also having to think about what we were doing with it. I think this sped our research because we had a framework within which to think about the decisions we were making.
Lastly, it really helped to research with Nate because we could bounce ideas around, problem solve, and challenge each other. Plus, it made it significantly more fun knowing we were diving into the unknown together.
To summarize. They were simultaneously overwhelmed and excited. But fearless – they just jumped into the swimming pool off of the high dive and hoped there was water in the pool.
I love my morning reading routine. Most mornings during the week – between 5am and 6:30am – I sit at my computer, catch up on email, read the stuff in my daily folder, go through my RSS feeds, and generally explore whatever I can on the web. Some is systematic (my daily folder, my RSS feeds), some is more random (Techmeme, Hacker News), and some comes from places that I couldn’t tell you how I got to.
Today’s amazing story was from The Tech, MIT’s newspaper (currently in Volume 130). The article is Opinion: The story BCG offered me $16,000 not to tell and is a great story from Keith Yost, an MIT grad, about his relatively short experience working at BCG in Dubai as a management consultant.
It’s a story that will be familiar to anyone who started working at a management consulting firm straight out of school. Or an investment bank. Or a law firm (out of law school). Or an accounting firm. Or any number of other “professional services firm.” It’s especially relevant for anyone who got an A+ education and was at the top of their class, which seems to correlate with the type of people that management consulting firms are interested in hiring.
When I was at MIT, I never really contemplated getting a job working for anyone. I started a few companies while I was in school, the first two of which failed but the third (Feld Technologies) took hold. During my senior year, I was also finishing up my first year of business school at Sloan so for the hell of it I went to a few recruiting dinners, mostly to see what they were like. I vividly remember one for McKinsey at L’Espalier when it was in its old location on Gloucester Street. This would have been 1987 when L’Espalier was the best ticket for a fancy meal in Boston (I think I’d been once) so there was plenty of buildup. The evening was one part delightful (the meal was awesome) and one part “turn a power drill on, place it between my eyes, and put me out of my misery” as the senior consultants and partners from McKinsey took the room through a presentation using overhead slides (this was before the age of Powerpoint) talking about the firm, the firm’s history, the firm’s importance in the universe, and a bunch of other things I forgot within 15 seconds of leaving dinner.
Over the years I’ve had plenty of opportunities to work with other large management consulting firms on various projects. While I found the style and tempo to vary, Keith’s article rang true to me, especially when I talk to some of my ex-investment banking friends who didn’t make it through year three of their “advanced copy machine operation and presentation wrangling” skills.
If you are early on in your career in a professional services firm, you’ll benefit from reading Keith’s article and thinking about the story of “Find Me A Rock.” If you are a manager or a partner, you’ve probably already found a rock, but it’d be worth your time to read this story also and ponder what you are doing on a daily basis. Think of it as having something healthy for breakfast instead of the usual Cocoa Puffs.
Yesterday I published one of Sawyer’s posts titled Why the Decks are Stacked Against Software Startups in Patent Litigation. In it, I realized that Sawyer hadn’t defined the different types of plaintiffs in a patent case. Below are good definitions (from Sawyer) of each type and clear explanations about what you are up against in each one.
If you’re sued in a software patent case, the first thing you should do is figure out what kind of plaintiff you’re up against, because that will have a major impact on your negotiation posture, and you will almost surely want to settle out sooner rather than later.
One important prefatory note has to do with contingent fee arrangements. Most software patent plaintiffs hire their lawyers on contingent fee. Depending on the state, the contingency can be anywhere from 30-40% of the final dollar amount exchanged between the parties, and it’s usually taken off the top. This arrangement gives the lawyers powerful incentives to (1) push the case toward its maximal outcome and (2) not do any work on the case if they don’t have to. So, if you think you have a contingent fee suit on your hands, know that you’re not just negotiating with the other side, but also with the lawyers who, both in front and behind the scenes, may be trying to undermine a resolution that they don’t feel is significant enough financially.
Now, here’s my non-exhaustive classification of types of software patent plaintiffs:
The active competitor: These are the IBMs and Apples of the world, the active, money-making companies that get patents and sue their competitors for market advantage. Competitor cases are usually not on contingent fee because the plaintiff doesn’t want money, it wants a more intangible advantage in the marketplace. Between big players, these cases are often settled in cross-license arrangements, but one can imagine cases like Apple v. HTC being taken straight to trial because the plaintiff wants nothing more than to wipe out or diminish the defendant.
The defunct competitor or pseudo-competitor: Many startups in the dot-com era filed for and got patents on things that we now would consider silly or obvious. As those companies went under, or go under now, the entity that ends up with the companies’ assets seeks to monetize whatever is left, which usually ends up being the patents. These companies morph from going concerns creating stuff to pure licensing entities that proceed to sue every player in a particular market sector. These case are often on contingency because the plaintiffs can’t pay hourly. Settlement strategies vary widely in these kinds of cases, but usually the plaintiff will be incentivized to push every suit to its rational limit unless someone comes along to vigorously defend against the patents. These, in my experience, are the cases startups get caught up in the most, because the plaintiff doesn’t want to sue big players who can defend themselves (the patents are usually pretty bad), and so decides to extract as much value out of small companies in a particular sector as it can.
The “small fry” troll: Here’s the strategy – I have a patent, and I want to collect money to fund some serious suits against big players. What I do is find dozens of small companies (and by small I mean even made up of two people) and I sue them all in one suit, or several suits. I have my lawyer play “nice guy” and offer to settle each plaintiff out for anywhere from $30k-100k, depending on company size. At the end of the day, I’ve collected several million dollars and I can roll that money into suits against the big companies. The reason the defendants settle is that they can’t afford to litigate the case out for a few months, let alone to trial, so they’re stuck and have to pay something. I won’t call it extortion, but I guess I just did. These cases are also sometimes on contingency, but the plaintiff usually hires very inexpensive counsel, with no intention of litigating the case, and those lawyers are fine with the relatively small payouts they get from small settlements.
The fund troll: Many patent suits these days are backed, if you can figure out who the backers are, by specialized funds. These are “venture funds” that collect money from LPs like traditional investment banks and use that money to identify and buy promising patents and set up/manage litigation against significant players to “make” the fund. These cases are sometimes on contingency, and usually on partial contingency with capped fees (half of fees paid, with a 15-17% contingency). The guys running these suits from the funds are usually very sophisticated, and have very specific ways of evaluating cases and deciding settlement amounts. They usually won’t sue anyone too small to defend themselves, because it doesn’t make financial sense. They also don’t let their lawyers influence settlement discussions. In my experience, they are the most reasonable people to deal with in settlement, but at the end of the day you’re still paying the toll.
The “big fish” troll: Sometimes there are software patents out there that have no good invalidity defenses, and where infringement by major players is very likely. These are the holy grail for plaintiffs: big, valuable, winnable cases. The number of firms who handle these types of cases is very small, and one in particular has been racking up huge wins down in Texas for a few years now, especially the past year or two. The plaintiff could be a specialized fund, or just an individual inventor; regardless, the plaintiff and the lawyers are perfectly aligned in wanting to litigate the case through trial. If you see one of these firms, it’s a signal that they did their homework and think they have a very good shot at winning several hundred million dollars against some major player in the case. The chances of settling these types of cases for anything less than eight figures is basically nil. If you’re ever on the other side of a case like this, be afraid.
There are other “types” of software patent plaintiffs, but I think they draw characteristics from the types above. The key takeaways, I think, are (1) that as a defendant, you’re negotiating both with the plaintiff and with the lawyers and (2) the suits aren’t usually filed by “real” businesses, so it’s generally hard to reach fair business-driven settlements. Favorable settlements tend to happen only when a defendant is prepared to litigate a case to the end, and in discovery produces some very solid prior art and information on good non-infringement defenses. This ends up being a function of the ability of the defendant to pay its own legal fees, so at the end of the day, settlements are based much more on the ability of the defendant to pay than the merits of the case.
The conventional wisdom has long been that software startups benefit from patents. I’ve been investing in software / Internet companies for over 16 years and I’ve never once had a patent influence my investment decision. More importantly, since it takes a number of years to get a patent, most startups haven’t even contemplated applying for a patent when they raise their first angel or venture round. Our friend Sawyer has seen this first hand and has some specific thoughts on what they decks are stacked against software startups in patent litigation.
Software startups are particularly vulnerable to patent suits, and often are in jeopardy of losing their businesses entirely after being sued. I think it’s important for everyone to understand the dynamics involved, because knowing why and how startups can be sued into oblivion will give you a new appreciation for the problems in the patent system.
A typical one patent case costs approximately $5 million to litigate through the end of trial, according to data that isn’t available online for some reason (the lack of pricing transparency in attorneys’ fees is a topic for another time). Costs vary wildly depending on where the case is, how complicated the technology is, who the firm involved is, etc, but $5 million is a decent estimate all-in-all.
I’m sure you can already see the problem. What software startup has $5 million to burn on defending a case with no value-add? Even $500k? I’d say it takes $1-2 million or thereabouts just to get through claim construction, which will give the parties a better sense of the overall merits of the case. One patent suit with a slightly determined plaintiff could very easily end a software startup just in legal fees, let alone the impact of the suit on gathering customers in the future.
So, software startups have to settle patent cases very early, and at high settlement amounts, because they have absolutely no leverage. Invalidity takes years to litigate, so you can’t threaten to invalidate the patent; same with inequitable conduct. Non-infringement arguments are great in theory, but the plaintiff won’t have a judgment day until the middle of the case at the earliest, after claim construction, when summary judgment motions are allowed (on most schedules), and that’s several years of litigation and several million dollars away. The defendant could file for a re-exam, but once it’s filed, the defendant has no control over it, and it takes a few years to get through the PTO.
Software startups sometimes have other leverage points, like the value of publicly shaming the plaintiffs, but when software patent NPEs are backed by investment funds through seven layers of corporate shell companies, or are dead companies with nothing to lose, who can you shame? And does anyone particularly care? The average person thinks patents are property (not entirely true) and a “great thing” for the economy; heck, our elected representatives say the same thing all the time.
The bottom line is that, in a world where a few million dollars and several months of work can build a promising software business, albeit one without serious cashflow, a patent suit can stop progress and kill those companies very quickly.
Luckily, perhaps, plaintiffs want money, and so in most cases it’s not worth it for them to sue a company with no revenue. But sometimes it happens, and it seems to be happening now with more frequency.
Startups can and do usually settle these cases, it’s just that the amounts paid aren’t particularly fair or a reflection of the value of the patents (generally nil); rather, it’s a reflection of a patent litigation system that only allows the huge players to defend themselves. Everyone else? Well, they’re kind of screwed.
In the last few days there have been a large number of posts about two platform companies – Apple and Twitter. These posts covered a wide range of perspectives (a few of the better ones are linked to below) but fundamentally came down to the tension between a platform (e.g. the iPhone OS or Twitter) vs. third party developers that build applications on top of the platforms.
Several of the Twitter related posts include The Twitter Platform’s Inflection Point, Twitter and third-party Twitter developers, and Developers In Denial: The Seesmic Case Study. Several of the Apple related posts ones include and Adobe Vs. Apple War Generates Rage, Facebook Group, Why Apple Changed Section 3.3.1, Steve Jobs response on section 3.3.1. If you missed the leads to the story, Apple made a major change in their TOS and Twitter launched an official Blackberry client and acquired the Tweetie iPhone client, rattling their developer community. And Twitter Officially Responds To Developers and Tries To Calm Fears.
While there has been an amazing outburst of reaction – including much surprise and criticism – to both of these situations, they should come as no surprise to anyone that has been in the computer business for a long time. What we are experiencing is the natural evolutionary struggle that exists between a platform and its developers. In the past few years, both Twitter and Apple have created amazing platforms and build incredible network effects on top of their platforms. One way they have done this is to embrace developers, who have flocked to these platforms in droves, building a huge variety of awesome, great, good, mediocre, and crummy products on top of the platforms. Some of these products have created meaningful revenue for the developers, others have generated fame, and many have generated a giant time sink of work that hasn’t resulted in much. This is the nature of being a developer on top of a platform.
True platforms are special things that are rare. Fortunately, developers have a lot of choices and that is a powerful dynamic that keeps both the platforms and developers evolving. I think the next few months are going to be pretty exciting ones as the current phase we are in sorts itself out.
Sometimes I feel like a conference promoter. It’s worth noting that while I put plenty of events up on this blog, I only post the ones that I’d consider going to. Specifically, I probably get 10 requests to post something for everyone one I do.
Over the past year, I’ve gotten to know Eric Ries through the work we’ve done together on the Startup Visa initiative. If you don’t know of Eric, he’s a software entrepreneur who over the past few years has been developing and evangelizing the idea of the Lean Startup. He’s an extraordinary writer – I gobble up every word that he writes on his blog Lessons Learned.
Eric wrote me the other day about a new conference he’s doing called Startup Lessons Learned in San Francisco on 4/23/10. The overview of the event follows:
Startup Lessons Learned is the first event designed to unite those interested in what it takes to succeed in building a lean startup. The goal for this event is to give practitioners and students of the lean startup methodology the opportunity to hear insights from leaders in embracing and deploying the core principles of the lean startup methodology. The day-long event will feature a mix of panels and talks focused on the key challenges and issues that technical and market-facing people at startups need to understand in order to succeed in building successful lean startups. We have a great lineup of speakers, including Kent Beck, Steve Blank, Sean Ellis, Andrew Chen, Randy Komisar, Hiten Shah, and many others.
While I can’t be there I highly recommend anything that Eric is involved in. He’s given me a discount code of ERIES25 which is good for 25% any ticket if you register for the event. If you are in the bay area on 4/23/10 I encourage you to check it out.
Amy and I love sushi. While my sushi dining experiences have been limited to the US and Europe, I’ve had a number of amazing sushi dinners, including Masa in New York. Boulder has a bizarrely large number of sushi restaurants and over the years we’ve frequented them all numerous times.
A year or so ago a new one – Kasa Japanese Grill and Bar – opened up on the corner of Pearl and 15th. It’s around the corner from our condo in Boulder so we stopped in a few times. The first time went there it was empty, but the owner and manager Mimi was delightful and upbeat, shining her happiness on us. As we kept going back, the number of people in the restaurant at any given time increased, but Mimi always welcomed us as if she was welcoming us into her home, doted over us, and made sure we had an amazing time.
Last week Kasa finally got a review that it had long deserved when the Boulder Camera wrote Kasa Japanese Grill review: Delicious excess has its place. Amy and I had dinner at Kasa tonight with our friends Tim Enwall and Hillary Hall and the place was packed. It was fun to watch Mimi run from table to table, making sure everyone was having a great time as her staff did the same.
I’m a Kasa regular and hope to be for a long time. I’m psyched they are getting the recognition they’ve been working hard for. The next time you think of sushi in Boulder, give them a try.
I had lunch today with Nate Abbott and Natty Zola, the co-founders of Everlater, a TechStars 2009 company. Nate and Natty are two of my favorites – not only because they regularly kick my partner Seth Levine’s ass on bike rides but also because they starred in last year’s TechStars The Founders video series.
Today, while enjoying a veggie burger at Mustard’s Last Stand, we talked about how Nate and Natty learned to program. When they came up with the idea for Everlater, they were both young finance geeks on wall street. Nate was a math major; Natty was a econ major, but neither had a clue how to build a web app. They decided that rather than find a “developer” to team up with, they would learn how to program.
I regularly get asked questions (via email, face to face, and this blog) by non-technical entrepreneurs how they should get started if they don’t have a technical co-founder. There are a variety of answers – one is “learn to program.” In Nate and Natty’s case it’s worked out great and their story is an instructive one. So we’ve decided to work on a series of blog posts together about their story of how they learned to program, the resources they used, decisions they made, struggles they had, and beer they drank (well – maybe not the beer).
Now, both Nate and Natty are smart, which is obviously a pre-requisite. But neither were computer science majors, nor were they “hackers” (although apparently Nate is pretty good at a wide range of video games.)
Look for some posts over the next few weeks on this topic. Of course, like any of the series I’ve written, your feedback matters a lot to how much I keep it going. If you decide that the story is great and/or helpful, tell us and we’ll keep it going. If not, we won’t.
I hate spam. Over the years I’ve been an investor in a number of companies that address the spam problem, including Postini and Return Path. I’ve also been involved in lots of other companies in the email ecosystem and spam has always been something I’ve paid close attention to.
I’ve thought hard about Blam (Blog Spam), Spim (IM Spam), Skam (Skype Spam), and SMam (SMS Spam). A few times in the past I’ve thought about Twam (Twitter Spam) but Twitter has done a good job so far of dealing with most of the nasty stuff, the most visible being the porn-follower twam that they somehow managed to beat back (or that I’ve successful ignored).
Today, I got caught in a twam trap. I got a note from someone to try out a service. It’s someone I’d heard from before so I went to the new site and played around with it. I wasn’t terribly impressed and didn’t really get it. A few minutes later I got a DM from a friend that said “@bfeld none of the links on that page are active, fyi. tried Chromium + Safari”
I didn’t know why my friend was tweeting me that, but then it occurred to me that playing around with the software must have sent out a tweet. I took a look and lo and behold it did. I didn’t want that, nor did I set it up. But it did. Yuck.
Automatic tweeting from within applications is becoming commonplace. This is good in many cases, but unless the sender authorizes the actual tweet, it’s twam. There’s no opt-in dynamic around twam, so before a service sends out a tweet for the first time, it seems like good form is to make sure the user wants to tweet. Most, but not all, do.
When you develop a twitter integration, think this through. Don’t be a twammer.