Latest Publications

Discussing Startups and Intellectual Property with the Boston Inn of Courts

On Wednesday I had the privilege of being part of a panel before the Inn of Courts in Boston. This is an organization of patent litigators that meets for continuing education and discussing the practice of their craft. For this meeting, they invited a panel of practitioners from startups and academia to listen to lay people talk about how intellectual property is working (or not) for us.

Topics were quite broad including a focus on copyright, trademark, and trade secret as well as patents and licensing. In the end because the panelists were mostly from the software space we focused more on software patents and software licensing.

The audience was remarkably receptive of the idea that software patents are usually bad, potentially so bad they should be eliminated entirely. As one litigator I will leave anonymous told me at dinner, “When I’m on a case, if it is a pharma patent I can assume it’s a good patent, and when it’s a software patent it is usually junk.” I suppose this reflects prevailing sentiment in the courts after Alice and other decisions.

The discussion became heated, however, when an audience member questions why we want to throw out all patents, noting that because of business method and software patents, congress and industrialists and the public have started to tar all patents. He found it particularly concerning for the future of investment and innovation. And that it is not as simple has “pharma good, all other patents bad.”

I agree that eliminating the entire patent system is not going to be a global optimum, but at the same time I do see it as a problematic institution. The audience was surprised at how ignorant academics can be of the obligations of the patent system, and the right way to use it. Of course, academics would rather publish and collaborate than patent, in general.

This revealed an assumption on the part of many attorneys present, that patents are still an effective disclosure which can be used by practitioners seeking solutions. Unlike academic papers, they are reliably and permanently public information. But honestly, having written and read patents, I can’t imagine anyone using one to build something. I challenged a smaller group to identify a single instance of the software developer in the Boston area in the last 10 years implementing something based on a patent. They conceded it was a bet I would probably win.

For academics, I think that tech transfer programs are effective at encouraging people to think about commercialization, more than they are at encouraging innovation through financial incentives. In most cases, academics innovate because that is what they want to do, and they publish, and they commercialize later, as a way to maximize impact of their work. Of course some academics find ways to become wealthy doing this, but they are the exception. Tech transfer created structures in the university to promote commercialization, and those are good for society. I suspect other ways of facilitating commercialization could be as successful. Notably StreamBase and hundreds of other software startups to come out of university have been helped by BSD-like open source licenses, without a need for any patent protection or commercial licensing.

Overall I was glad to be a part of the passionate discussion. They understand that the patent system isn’t working well, and that politicians and the courts are starting to the create new boundaries that are necessarily optimal. I drew a parallel to the high frequency trading experience, where the political climate, the expectations of regulators, legislators, and the public are being violated. Often the things people react most strongly tare not the biggest problems, but their reaction cannot be ignored.

I think the patent community has a big obligation to maintain public trust and to think about the real basis for what they’re doing. The idea that patents and intellectual property can encourage innovation is a good one, but in areas where it’s having the opposite impact we need to question our assumptions. Wholesale repeal of IP law is probably not the best way to constructively improve the system.

In Sales, Questions are More Valuable than Answers

Inspired by “A day at the park” by Kostas Kiriakakis.

I spend a lot of my time helping people sell the software I write. For scalability, this often means teaching them how to sell it themselves. When I’m teaching people, which happens informally and formally, often times they want to know the questions the prospect will ask, and what answers they should give. The FAQ, as it were, so they can have the answers at the ready. And they don’t just want the technically correct answers, they want the answers that will encourage the prospect to buy. “What should I say if they ask what I think about competitor X?”, things like that.

Do You Have Something Against Answers?

Experienced account executives and solution consultants are more focused on stories. They want to know where we have made other customers successful, what the situation was, why that customer needed new software, how our software met the need. Their hope is that if they know enough stories, they can find a story of past success that matches the customer situation at hand, tell the story, and get the customer imagining what their success will look like. It’s a good plan, and often works. It’s a better strategy than just answering questions, because people actually buy stuff when they are emotionally engaged, not just analytically. Stories are a good way to engage people.

There is something better than either answers or stories. The most important thing a technical sales professional can bring to a conversation with a prospect is not answers or stories, but questions. And I don’t mean analytic questions like “Linux or Windows?” or “How many transactions per second will the solution need to perform?” When engaging a customer, what you really want to find out is what they are worried about, why they are considering the risk of yet another new software product or new software project. You want to demonstrate that you understand their concerns, and the environment in which they are operating, and that by working with you they will be smarter and more successful.

Reality Can Change

In order to find out what people are worried about, sometimes you can ask directly. But with most prospects, particularly in group situations, they will be too guarded for that. What you want to do is ask questions that relate to the project and the business context around the technical solution, which find you the information you need.

  • “What is wrong with the system you are replacing?”
  • “What happens if you do nothing?”
  • “Have you considered running two of them side by side?”
  • “What is unique about your environment or business? What customization will be required?”
  • “What is driving growth in your business? Profitability?”

You can’t spend all your time asking questions. You have to earn the right by presenting your product and answering their questions. But you can probably ask more questions than you realize. People like to talk about themselves and their problems. Not only will you learn things by asking questions, the prospect may come to understand their problem better as they take the time to answer good questions.

You also want to demonstrate you understand their market, and make suggestions in the form of questions. There is a good chance that whatever system you are talking about, your customer has only built one of them. In fact, they may have build zero of them so far. You, coming from the vendor, have probably seen several customers do similar things, and maybe had dozens of conversations about this potential solution. Bringing up your knowledge in the form of questions is non-threatening.

  • “Are you going to be integrating per-customer analytics into the solution, or giving everyone the same analysis?”
  • “What segmentations do you have in mind? Will that impact the roll out plan?”
  • “How will your business partners measure or visualize the success or failure of the system on a day by day basis?”
  • “Will you calculate ROI by comparing revenue to last year, or with a more sophisticated attribution model?”
  • “Are you planning for regulatory change?”

Some of these questions will be particular to the industry or the solution, but many of them are nearly universal.

Questions Attract Better Questions

That universality is empowering. Questions have much more staying power than answers. Answers are always changing, by the time you write them down they are probably out of date. Information I know about my competitors is like that. But so is information about what other customers are doing, or what the next big regulatory change might bring. Answers about data volumes, rates, latencies, these are all information that goes out of date very quickly. Sometimes when preparing a sales enablement briefing I want to put an expiration date on it. Unlike answers, questions can live for a very long time. They are more portable between industries and products. They can continue to elicit new information, new answers from prospects, but also new discussion, and new stories.

As you prepare for customer meetings, don’t just bring answers. Bring good questions.

10 Tips for Not Giving a Sales Pitch at a Meetup

How do you give a sales pitch at a developer meetup? Don’t.

Glengarry Glen Ross - Always Be ClosingDeveloper meetups are technical, so it can’t seem like a sales pitch. Even if you paid for the pizza and beer and everyone knows you are there to pitch them on something with commercial upside for you, they want to feel like it is a technical community event where valuable information is being shared. This is the epitome of the evangelical or educational sale.

I’ve attended dozens of these and done a few myself. In watching others, and especially watching for signs of audience engagement, I’ve come away with ten recommendations:

  1. Don’t have a non-technical executive give the presentation. Ideally your presenter should be as technical as the audience, or slightly more technical than the audience. A less polished speaker with more credibility is fine. In fact, meetups are a great place to get your chief architect more public speaking experience. If you are a less technical person presenting, just accept that. Mention your role, but don’t call attention to it. There is no benefit to being self deprecating. If you get questions that exceed your depth, take them offline and have someone follow up in email.
  2. Ignite Atlanta Audience

    By Tim Dorr, Flickr, CC/SA

  3. Do know your audience. If they are developers, don’t talk about not needing developers. if your tool isn’t for developers, talk about who does use it and where developers would find such people. If your tool is about enterprise, talk about key characteristics of organizations or people who benefit from your tool, don’t just assume people understand enterprise.
  4. Don’t spend one third of your time on background. Throw away your corporate pitch template. We don’t need to know the geography of your company, your target industries, the biographies of your executive team, who the investors are, how nice your office space is, or your mission statement. If you are going to try to recruit people, leave it to the end.
  5. Do talk about the changing context. Each time you say something has changed the the world spend time on that. If your tool depends on YARN, don’t assume people know what YARN is, or how the world was before. Help people understand how the world is different. Your audience is looking for new things, and hoping to adopt them. They will want to be able to explain to their colleagues why your technology is a logical move, not just a new shiny.
  6. Don’t talk about how long it took you to get there. The long-slog-through-the-woods part of any innovative technology is like your vacation photos: most interesting to the people who were there. Talk about the world as it is today, and let people assume you were so brilliant that you literally thought it all up last weekend – unless there are particular things people will want to know.
  7. Do talk about your mistakes, and what you learned that does not work. These are mistake that people can learn from. This may be a way to de-position your competitors as well, if what you learned was that the standard or obvious solutions to problems don’t work. Talk about why they don’t work. Imagine you are arming an audience member to have a technical discussion with their boss about why they need your technology instead of using the established offering. But don’t turn this into competition bashing, talk about it as things you tried that didn’t work.
  8. Don’t focus on customer validation or analyst recommendations. Logo slides say very little to a meetup audience. I’m probably not from your target vertical, I might recognize some fortune 500 companies on your list, but I know that fortune 500 companies are big enough to make plenty of bad choices in corners of the organization. Without more depth than a logo and a quote, there really isn’t validation here.
  9. Back of the Napkin

  10. Do show real architectural diagrams from real deployments, not marketecture. Even if they are ugly. In fact, between a black and white boxes and lines diagram someone just whipped up in Omnigraffle, and a polished marketing diagram, use the less polished one. It will enhance your credibility. And most importantly, these diagrams should correlate with real deployments that you’ve actually done, if at all possible. They aren’t just wallpaper, use them in your talk and call attention to how they are real by saying things like “This customer used nginx for the front end, but we can also use Apache” or “this bit here was custom code for this deployment, but in an upcoming release it will be part of the product.” If you aren’t comfortable drawing pictures, I recommend The Back of the Napkin.
  11. Don’t focus on competitors. Often times the meetup has a very broad range of topics, and people won’t know your competitors. If you start comparing feature lists, it will become an inside-baseball conversation and you will lose the audience.
  12. Do say what is hard. Each time you say something is hard, so people should use your product, be super detailed about why it is hard. When you mention something clever that you did, go at least one level deep, if not two. Ideally give people enough information they could imagine replicating your work. They are very unlikely to actually replicate your work, but they will then remember these parts and use them to argue why your solution is required.

Meetups are a great opportunity. Whether you are invited to present or sponsoring, you will have an audience that is technically engaged, wants to learn about new technologies, and more often than not wants to bring that information back to their day job. To make it work, know the audience and present in ways that resonate with this audience. The results can be amazing.

Identify and Manage the Honey-Badger Developer

A few years back I read Rands’ blog post about the Free Electron developer archetype: “the single most productive developer you’re ever going to meet.” This is a good archetype to understand, identify, recruit, and retain. I would like to discuss another related archetype which can be quite powerful if properly harnessed: The Honey Badger.

“There is no other animal in the kingdom of all animals, as fearless as the crazyass Honey Badger.”

Like the honey badger itself, the honey-badger developer has no fear. They will undertake any project, with any technology, on any deadline. They will not be paralyzed by the impossibility of choosing a good architecture. They will proceed single-mindedly in the direction of the current stated requirements, even as those requirements change.

What makes for a honey-badger developer?

  • Willing to work with grotty systems
  • Uses undocumented APIs
  • Reverse engineers protocols
  • Finds third party libraries whenever possible
  • Able to glue anything to anything else
  • Able to work within really challenging constraints
  • Pursues a successful implementation regardless of architectural purity
  • Gets things done

Of course, these are not universally positive traits. If you are developing the foundation of a new software platform, a new hypervisor or database kernel, you won’t want to make these kind of tradeoffs. On the other hand, if your largest customer absolutely requires an integration with their unmaintained COBOL running on an IBM mainframe by the end of the quarter, then a honey badger may be just what you need.

Sometimes it can be hard to tell the difference between a honey badger and a non-badger who is struggling. The difference is in what they attempt and accomplish. A struggling developer may try some of these behaviors, but their project isn’t actually that difficult and a better developer could just do it properly. A honey badger, on the other hand, brings out these tools in clutch situations where other developers throw up their hands in despair.

How do you properly manage a honey badger? What a honey-badger developer needs is audacious requirements, guardrails, and admiration. What they don’t need is unrestricted commit access. Create the right environment, and they will be a powerful force for project success.

Audacious requirements are the honey for the badger. They are happiest when attempting projects other people think are impossible. So make sure you pick good projects. The best projects will have deadlines. Integrations are often good, particularly when one or both systems are proprietary and poorly understood. Performance challenges can also be a fit, particularly in scaling and throughput (latency often requires more detail work). Demonstrations and proof of concept work often create the right context, with lofty aspirations and tight deadlines. Make sure the honey badger understands whether the goal is to do the work or to show the work. It may make a big difference in how they approach things and where they spend their limited time.

The guardrails for a honey badger should give them plenty of room to choose implementation, but a bright line not to cross. For example, your code must run in a separate process, or it must run on a separate machine. It must expose this API, or use this API. It must run in this VM or this container. And be clear. If you want the code to be in Java, you have to say that, otherwise your requirement that it work with a JVM may result in the use of Clojure because the honey badger found a library that did most of the work.

Finally, a honey badger needs admiration. They are going to do things which are hard, and unpleasant. They will likely work long hours to meet a deadline, or travel to work directly with an inaccessible customer system. They know they are creating solutions which are not the most elegant code. They need to hear from you, and from the team, that what they are doing is important and they are doing an impressive job.

The one thing not to do with a honey badger is invite them to make changes on your core systems. This is a corollary to the guardrails requirement. If the honey badger has the ability to change something, they will, and often not in a way that everyone on the team appreciates. Unfortunately, it will be in service of some critical requirement. So get in front of those conflicts, and either create a process for approving their changes, or just enforce a guardrail.

When your honey badger has succeeded, you will have a working system, sometimes just a single unreproducible instance. To defend against this, try to get them committing early and often, even if it is to a private repository. Your system, if it was built for a customer, may be distressingly close to production. Your customer will also have fallen in love with the honey badger and not want to let them go. You must either fit this into the economics of your  business, or ideally find ways to wean them off the honey badger.

The honey-badger developer can be tremendously valuable asset to any software team, and especially a software business, if managed correctly. What other success stories do you have about honey badgers? Other management tips?

Lessons Learned from Startup Weekend

A year ago this month I attended startup weekend in Boston. The company that I helped to launch there,, is now a successful ongoing concern, with funding and a handful of employees. So I think that counts as a success story for startup weekend, and my conclusion is that it’s a great program and can work well if you make the right choices going into it. To that end, I’d like to share some of my lessons learned from my first startup weekend, and solicit anyone else to add them in the comments.

First, always come with an idea. Create a good pitch. This is the way the other participants will know you, and it’s worth giving them a chance to get a sense of you in this context. You don’t have to bring your best idea to startup weekend, but it helps if you can bring your best startup weekend idea.

Second, don’t be too attached to your own idea. In fact, you might get more out of this if you can join another team that has an idea that is even better suited to startup weekend than your own. Very few good ideas can be implemented and validated in 48 hours. Plan to pick the best one, and don’t worry if it isn’t your own. You can always take what you learn and apply it to your own idea on a more practical timetable.

The best ideas have a few unique characteristics that make them fit into the timeline, audience, and competitive aspect of Startup Weekend. A few principles of idea selection:

  • Select an idea that fits into a weekend. Ideally you will want to validate your idea with customers, build a prototype, validate more, prepare a demo, and make a presentation. That means you can’t invent any substantial new technology, you are looking for something that is class-project sized, not 20 engineer months. If you have a big idea, cut it down until it feels like it might fit, then cut it down by another two-thirds.
  • Appeal to the audience. Present an idea that people in the room will want to use. That makes it easy for them to understand and get excited about, and will give you your first customer validation. The people in the room will nearly all be younger professionals in the tech sector. Ideas related to socialization, recruiting, and personal services are easy to get excited about. Ideas related to financial risk management or construction not so much. Surprisingly, medically oriented ideas got people pretty excited, I think because “doing well by doing good” is hot. Feel free to trend-follow here.
  • Appeal to the judges. It’s a competition and people like to win. Choose an idea that can be validated in a weekend. You probably won’t get any CFOs on the phone on a Saturday, but you can go outside and find consumers. Don’t choose an idea with huge market risk, or where your team will be clearly unqualified. Choose an idea that resonates with current investing trends, with an additional hook.
  • Explain why you are the leader. Ideally come with some kind of pre-validation, and include that in your pitch. “I already have a list of 20 prospective customers who are willing to do interviews this weekend, and I need people to do the interviewing and build a prototype based on my vision and feedback” makes your idea feel much more achievable and worth joining.

When you are selecting an idea (including if you select your own), you are actually selecting a team. So if you can find someone with an appropriate idea, a great idea, who also has the personality or presence to pull together a team of people in the chaos that is startup weekend, all the better. The number one thing you are looking for in a team is a good breadth of skills and a good number of people, enough people and skills to get something real done and have someone paying attention to all the parts.

Beware of teams with only 1-2 engineers unless the idea is super simple, and avoid teams with more than 3-4 business people. If your idea needs a designer, your team needs a designer. In my experience, the designer was the most valuable member of the team (even though he hadn’t ever done startup web design before) and the rarest find. The Startup Weekend organizers try to keep the skills balanced, but it’s never perfect. Too few engineers and your engineers (maybe you) will be death-marching for the weekend. Too many business people and they will be off on distracting tangents.

Usually you are going to be implementing some kind of application, web or mobile, whether it is a prototype or not. Choose a team where the engineers have good skills overlap and can quickly converge on a technology (e.g. Ruby on Rails, Python Django, node.js and seven other libraries). Avoid science projects. Avoid any devops, host on Heroku or someone’s personal machine or whatever someone already knows. We lost 3 engineer hours to fighting with Amazon hosting, which was completely uncessary. Choose technologies you know and that you know to work, and focus the risk on the application you are building and the ridiculous timeline.

Speaking of building things on a ridiculous timeline, the best advice is to begin with the end in mind. Know what you are going to be doing at the end, which is presenting for 5 minutes to a group of VC/Angel/Entrepreneur judges who will want to see that (a) you build something impressive, (b) your idea is coherent, (c) there could be a business here, and (d) that business would actually do something important. To that end, start building a demo script and a PowerPoint as soon as you have converged on what your idea is. Make sure that whatever you build as a product supports a well-scripted demo, and that whatever work you do around customer validation fits into the pitch.

Finally, don’t sweat the ownership until you have something real. This is the trickiest aspect of startup weekend. Failure is an orphan but success has many fathers, as they say. In our experience, having created something successful that was on track to get funded, we were able to more than satisfy those people who helped at startup weekend with a token amount of stock (a few hundred shares) once we made clear the additional work that was going to be required. Of course, it is always possible for someone to make a stink, and this is why you should be careful about what ideas you choose for startup weekend.

I hope these tips are helpful to anyone doing SW, and if you have more please add them in the comments. I encourage everyone with an interest in startups to try out Startup Weekend. The environment is very high energy, and you get nearly immediate feedback on what you are doing. Concentrated learning and coworking in such a short period of time is great fun. And if you are lucky, you may come away with a startup you are really excited about.

Recommending the Franklyn D Resort (FDR) in Jamaica

I just got back from a week in Jamaica, and I’ve been talking off everyone’s ear about the experience. That’s because the Franklyn D. Resort has one major thing going for it: every family gets a full time nanny for the duration of your vacation.  Larger families, particularly with multiple age groups of kids, often had two nannies. The resort seemed especially friendly to large families, with big multi-bedroom suites and reasonable rates for additional children. For our trip they were also running a “grandparents stay free” promotion, which I think they do every January. If you are planning a family-oriented vacation, particularly with young kids, you have to consider the Franklyn D. Resort.

So while I’ve been recommending the resort to people verbally, I wanted to take a moment to write down what I learned vacationing there, and what people might want to know before they take my advice and book their own trip:

  • Having a nanny while you are on vacation, as I mentioned on Twitter, is amazing. Compared to my week in Puerto Rico last year with the baby, this was total relaxation. I had exactly as much toddler time as I wanted. And I was lying in the hammock, and Patrick wanted to play basketball, Carlene our nanny was happy to take him, and I could go with them or catch up later. I was able to do my own things, like trying out scuba diving, without having to negotiate childcare with my wife.
  • The resort is wonderful, for what it is. It is locally owned, and definitely not maintained to Disney standards. They stay on top of maintenance, but there is still chipped paint to be found, overgrown plants in places, and parts of the pool deck collect water. But the price is good, the staff members are wonderful, and I didn’t have any facility problems that actually impacted my vacation.
  • If you want to spend time with your kids, you have to be really clear with the nannies. Their default mode is to whisk the kids off into kid-oriented parts of the resort, where there are lots of activities, lots of other kids, and other nannies to socialize and share duties with. Our son was a bit sick, and tended to be clingy. But whenever he wanted to head off to the playground, our nanny Carlene was happy to take him. By day three we realized we were missing him. But it took a couple of conversations to get to the right balance of Patrick-directed, Carlene-directed, and parent-directed activities.
  • “Gratuity included” is only technically true. While the prices and the organizations is gratuity included, many of your fellow resort-goers, particularly the repeat customers, will be ignoring this rule. Tips are not large, mostly one dollar US or one hundred Jamaican (which is about $1.20), but they help to get you priority service at the bar and at breakfast. If the resort had been more crowded, they might have been more necessary.
  • Nannies are happy to stay late, but you won’t get a lot of guidance from the hotel management. Based on conversations with our nanny and others at the resort, a large fraction of their income comes from overtime when you hire them after 5pm for additional childcare at $6/hour. We converged on having Carlene take a break and come back at 6:30 for a few hours while we went to dinner. Tips are also big for them, it seemed standard to tip the nanny $100 for the week if you were happy.

The resort wasn’t without a few opportunities for improvement:

  • The food isn’t very good. This may be par for mid-range all-inclusive resorts. The menu gets a bit repetitive, and in particular the deserts were downright poorly executed. Also, presumably because it was a light week, only 2 of the 3 restaurants were open on any given night. On the bright side, this probably helped me avoid gaining weight, and the breakfasts were reasonably good.
  • Some parts of the facility aren’t as child-safe as I would like. Part of this is Jamaica’s more relaxed building codes, and part of it is that kids are pretty much always being watched, so they don’t have much opportunity to get into trouble. But, for example, the railing between the pier and the ocean had big gapes, definitely not up to US code. And the cribs they provided were not SIDS safe. If you are a parent who is especially concerned about these things, it could be quite frustrating.
  • It could be crowded. We were there the slowest week of the year. If all the rooms were full, I expect the deck chairs around the pool and other facilities could be more taxed. It’s something I’ll keep an eye on when booking our next trip.
  • They are not helpful with arranging off-property trips unless the trip is run by one of their partners. This means that if you are interested in walking ten minutes down the road to the town center in Runaway Bay, and want advice for a place to eat, you won’t get any answers from the staff. Of course, Jamaica is a high crime island, so maybe you are best off staying on the resort. But if you want to catch a cab or their shuttle bus to do some shopping at a tourist-friendly Jamaican mall, expect to be taken advantage of unless you haggle the price and set things up in advance. Just because the resort booked your trip doesn’t mean you will get a good price or good service.

Of course I’m still very positive about the resort, and if you have young kids and are looking for a relaxing vacation I highly recommend it.

I hope you find what I wrote here useful. Especially if you are booking a trip to the FDR, leave a comment to let me know. Thanks.

Toddler Science and Big Data

"Stand Back, I'm Going To Try SCIENCE"I’ve been spending a lot of time following my son Patrick around watching him explore the world. I’ve shared a few of his important discoveries with Twitter and with friends, under the tag “Toddler Science”. Key discoveries include that tissue boxes contain a finite supply of tissue and that cat magnets do not stick to cats. I spent the New Years weekend with friends, and they too had an opportunity to watch Patrick learning.

The metaphor that keeps coming to mind, particularly when watching the destructive testing of my belongings, is that a toddler is a video gamer playing with a new engine. They get their bearings by testing out the physics model: how far can I throw a grenade? Do they bounce? If I shoot up the wall and leave the room, does the damage persist or does the state reset?

Patrick is learning the physics engine of his world. To do it, he is doing a large number of observations. And try to make sense of these observations, which is quite difficult.

“He needs to figure out if he is a universe governed by Newtonian mechanics, or just the Quake engine.”

“Aristotle never got past the Quake engine.”

Of course, humans don’t make use of nearly all the data that is available to them. If they did, they would learn a whole lot more a whole lot more quickly, as we can learn from Eliezer Yudkowsky’s fable That Alien Message. But we do receive a whole lot of data, and somehow filter through it to learn to interact with a complex universe, to empathize and communicate with other humans, to learn and to create new ideas. The amount of data consumed by a child before he learns to speak or throw a ball is staggering.

Computer Science is just starting to learn how to manage and analyze data sets at this scale. Today’s Big Data systems come in many flavors, from Google and Facebook to Walmart and eBay. There is some debate about what big data means, with Curt Monash and Dan Abadi having recent posts on the topic.

Regardless of how you define it, there is lots of data available that computers are still ignoring. What passes for big data in artificial intelligence is only starting to approach what passes for big data in biological systems. As big data gets truly big, interesting things will happen. It may be that previous generations of AI weren’t bad ideas. They were just data starved.

Book Review: Early Exits: Exit Strategies for Entrepreneurs and Angel Investors

“>As someone several years into a successful venture backed enterprise software startup, I find myself spending a lot of time looking at the green grass on the other side of the startup fence: angel funding and quick flips. People have mixed opinions on flipping, both the practicalities and the ethics of quickly flipping a company. Ethically, I tend to agree that “Flipping is Good“. But practically, there are a lot of moving parts in a company and lining them up for a quick windfall seems to require more than a bit of luck. It was in hopes of better understanding these practicalities that I read Basil Peters book Early Exits: Exit Strategies for Entrepreneurs and Angel Investors (But Maybe Not Venture Capitalists).

Many business books have only one good idea. This book has three, which is nice:

  1. The business environment is in great shape for early exits – If you want to sell a company for $5-30 million, there are a lot of buyers, they have gotten easier to find, and the deals have gotten simpler. For many more businesses than in the past, an early exit is feasible.
  2. Align your exit timeline with your investors to make an early exit possible – If you take traditional venture money, that is a commitment to swing for the fences. It can be very difficult to accept a $5-30 million exit after you have raised even seed money from a VC, because they are depending on your company to consume growth capital and deliver the kind of returns that their funds require.
  3. Employ an outside party to manage the exit – The book really drove this point home, presumably because the author is making a career out of this role. It was an interesting perspective to me, not something I hear much about in the blogosphere, and something I’ll have to investigate further.

Unfortunately there were a few problems with the execution of the book:

  • Lack of rigor – Peters’s financial models are quite simple, and generally not backed up by broadly sourced data. The traditional-versus-early-exit model that makes the cover of the book and drives home the point about avoiding VC is purely hypothetical numbers, for example.
  • Canadian heavy - Writing about what you know is great, but more information about key geographies like the United States would have helped make the book more credible. There is plenty of research and statistics available, and the author only scratched the surface.
  • Simplistic Angels versus VCs viewpoint – There are a lot of opinions flying around about what makes someone a super-angel, or what makes a seed-stage VC firm. Suffice to say the book’s black and white distinction between angels and VCs is simplistic. I would have expected more reasoned discussion of investor types, given that investor alignment is a key point.
  • Insufficient detail – The later chapters in the book, notably around pricing, are insultingly light on detail. I realized that pricing is complicated and it’s best to work with a professional, but that’s no excuse for introducing net present value of cashflow and then leaving everything else as an exercise for a consult.
  • Too much of a commercial – I understand that the point of this book, and many others, is to promote the author’s services. However, there were too many pages dedicated to the need for such services, and too few to the nuts and bolts of what would be done or how value would be realized. That, in the end, is the real problem with this book. I was hoping the author would tell me more of what he knows, since I’ll probably never have the opportunity to hire him directly.

The author has a blog (, and it remains somewhat unclear to me why he put the effort into a book rather than sticking with the blog format. Much of the information in this book is available on his blog and around the blogosphere. I had been hoping for more new work, or more depth. Unfortunately I did not find it.

If you’re considering starting a company with an eye to early exits, it’s easier to read this book than to track down 100 good blog posts on the topic. Unfortunately, you’re going to need the blog posts either way to fill in the gaps.

2010 The Year in Bookmarks

As you may have heard, Delicious is going away, or at least being sold off, or otherwise being destroyed by Yahoo. In the last 72 hours, I’ve tried out the two leading alternatives, Diigo and pinboard. Along the way, I got to wondering why I keep all these bookmarks around. I do often search back for things. And in paging through my 1173 bookmarks from 2010, they formed an interesting lens through which to look back at the year. And so I present 2010, the year in bookmarks.

Startups and the Death of VC

A lot of the links in my bookmarks are about startups and venture capital. A popular topic in 2010 is the death of VC, or debates about angels versus VCs. Also, discussions about whether Boston or New York are the number two startup hub to Silicon Valley.

Startup Visa

The notion of a startup visa also caught my attention. Here are just a few links.

Startups Without Software

At the same time, everyone is excited about the prospects of tech startups that don’t have any technology risk, because they don’t actually require new technology. Unfortunately, the best examples of these startups are fairly small businesses

Old Ideas are New Again

Another theme was all the old ideas that are new again, demonstrating that timing and execution can both make all the difference.

The Maker Movement

I’m not sure if it is old or new, but the “Maker Movement” is getting a lot more press attention, and a lot more bookmarks from me.


The iPad was the biggest new consumer technology of the year

  • Best New (to me) Blogs
  • Memes

    Far be it from me to catalog all the memes, but here are two

    Next Generation Marketing:

    Though speaking of memes, I also have a bunch of bookmarks around next generation marketing.

    Data and Journalism

    The use of data to drive new journalism was a big trend.


    If you are going to do journalism with data, visualization matters a great deal:



    Who Programs and Who Doesn’t

    Video Games


    Birth Control

    It was the 50th anniversary of the birth control pill, inspiring a range of articles, including two contrarian pieces:

    The Beatles

    It was also the 30th anniversary of John Lennon’s death

    Keeping Your Eyes Open

    Finally, two links about keeping your eyes open for the surreal and the wonderful things around you every day:

    There Can Be Too Many Suckers at the Table

    Everyone knows the old saw about poker: If you can’t spot the sucker, it’s probably you. It’s nice to think you could sit down at a table with incompetent players and take their money. It probably works in poker. Mark Suster applies the aphorism to angel investing in his post Dealflow – Are You Sitting at The Right Poker Table? It’s a good post, dealflow is really important. But the poker metaphor falls short. Too many suckers actually ruin a startup market.

    Consider the music business. In nearly every segment, from performers to promotion to distribution, there is far more talent and capital being applied than will ever be able to be profitably returned. People get into the music business as a life choice. Nashville is full of artists just barely getting by, but thankful to be in the business. On the web there are hundreds of startups trying out dozens of business models for selling/giving/pushing/pulling music. Hardly any of them are making profits, and none of them are seeing big exits. But money and talent keeps flowing in, whether it is hedge fund veterans backing LimeWire or  Google trying several strategies.

    When there is too much capital, the bad can start to crowd out the good. There are only so many early adopters, and they get tired of hearing about all the new things. Your competitors are losing money on every sale, making it up in volume, and setting customer expectations all wrong. Lavish launch parties, expensive marketing campaigns, and picky consumers drain your resources. Incumbents with natural or historic monopolies become demanding and exploitive of new partners. A new entrant who tries to be above the fray doesn’t find anyone doing business at that level.

    Music isn’t the only market with this problem. Many other media segments have it too, including video games, Broadway theater, and film. For most of its history the airline business has been losing investor’s money. Nearly any tech-VC fad, particularly one with light capital or intellectual property requirements, can fill up with suckers. The restaurant business may be subject to the same problem, and the nightclub business probably is.

    If you know you are in a market full of suckers, it might still be possible to build a successful business. You can find an angle to exploit people who want to be in the market, either in the style of The Producers (generally illegal) or in the style of Ticketmaster (potentially illegal). You can be consistently and significantly better than everyone else, like many Hollywood directors or Apple’s iTunes. Or use the market to prove out your idea and build your brand, but make your money in a more diverse market, like Moontoast (whose presentation at WebInnoinspired this post).

    Two Seven Off Suit

    At the poker table, it’s not very often that a sucker turns his two-seven offsuit into a full house. When it comes to startups, there are a lot more ways for people with capital and skills to spoil the game for everyone. If you look around the table and everyone else looks like a sucker, you might be one too.