Dave Naffziger's Blog

My copy of Venture Deals arrived a little while back, but it wasn’t until my trip to SF this weekend that I had a chance to read it. My plan was to skim the book and then pass it on to one of my friends that is actively raising a round. Instead, I’m keeping it on my bookshelf next to the essential Entrepreneur’s Guide to Business Law and sending out a few copies.

I found myself alternately skimming sections and reading every single word. The book is succinct and doesn’t unnecessarily repeat itself. I was able to quickly determine whether a particular section had something new to teach me and dig in as needed. The book easily fit into a few uninterrupted hours on a flight, but I expect I’ll reference it from time to time.

As an early entrepreneur, a disproportionate share of your legal counsel’s time is effectively spent educating you. No sane entrepreneur should negotiate an obscure point on a term sheet that he doesn’t understand. In my experience, one of the reasons legal bills are often higher on a first-time entrepreneur’s company is this education curve. Read the book. The last thing you need is to shovel money from your completed financing to the lawyer that had to coach you through terms you could have quickly taught yourself.

But, the value of the book isn’t limited entirely to negotiating a venture round. I also found the tips on negotiation to be both timeless and more broadly applicable (I suppose there are negotiation books for that also). For example, most corporate legal processes are set up to exploit the tendencies of smaller companies. They take forever to process revisions and can involve many back-and-forth discussions. While I’m not particularly sensitive to the length of the process, I’m extremely sensitive to the time I spend on the process. Looking back, I see myself consistently agreeing to slightly worse terms the more time I spend on the negotiation. This wasn’t something I was aware of, and that self-reflection will be useful going forward.

Some of the biggest gaps in the book are easily addressed if you read it while online - I find that spreadsheets help me internalize the dynamics of financing terms much better than printed text, and there are plenty of resources for that online.

If you are operating (or hope to operate) a startup, Venture Deals is a great asset even if you don’t plan on raising any investments.

Startups rarely launch the way they are intended. Jeff and Todd had spent the better part of a year working on the groundwork for their apparel company, Out of Print Clothing.

They had spent months obtaining license rights for the original cover art from a number of cult classics such as Atlas Shrugged, Brave New World and On the Road. Tracking down the artists that had created artwork 80 years ago took a bit of work. In one instance they traveled to an old mansion in Brooklyn to meet with the widow of one of the artists.

Both Jeff and Todd were pursuing a certain look in their shirts. The quality of the shirt and silk screening was essential - they tried lots of shirt/printing variants until they were satisfied.

More importantly they struck a relationship with Books for Africa to donate one book for every shirt purchased.

They had a launch date planned for several weeks down the road. Everything was coming together nicely. They were lining up influencers to wear their shirts and had developed a media list to reach out to.

Then JD Salinger died.

And they had license rights to the original cover art from Catcher in the Rye:

They had a few more weeks of solid work before launch, but knew they couldn’t miss the opportunity. They worked through the night, polishing as much as they could, cutting requirements where they could and launched the day after the news broke about Salinger.

The result is pretty awesome. Check out their line-up of shirts. In addition to the JD Salinger shirt, these two are probably among my favorites:

Oh and of course, they have the cover art to this post’s namesake:

While there are tons of measures of a startup’s success, one of the more amusing ones is the degree to which your competitors take notice.

We have been fairly quiet in public about BrandVerity and our growth, so I always take a special interest in how new prospects find us (good practice at any stage of a company). We make trials incredibly easy to start, so we often know very little about the party on the other end that creates the account. Occasionally, someone will create an account that just doesn’t seem to fit with what we do.

So far we’ve had at least two accounts that I can directly trace back to a competitor. In one case, the CEO of a peer opened an account using an email address from her husband’s company. She never contacted us directly, but looking at her usage patterns in the site it was pretty clear that she was conducting a feature comparison.

The more recent one was particularly brazen though. An employee of a larger competitor created an account (using a hotmail address), and then sent a note asking to speak. The employee represented themselves as a marketing consultant that managed campaigns for several brands, but over the course of the conversation it became pretty clear that she wasn’t a typical customer. Questions about unrelated aspects of the service, size of company, and customer counts just didn’t fit with a typical customer’s behavior. I declined to answer the more sensitive questions, and after the call I created an excuse to call her back to clarify something. The response at the other end of the call was ‘Hello, ’.

Competitive research is an imperative in business and I certainly expect competitors to try and learn as much as they can about us. I actually think that more direct approaches yield better success (eg just reach out and introduce yourself), but as a startup you should just be aware that anything you say to customers and prospects becomes generally available information.

Oh, and it is great if your competitors accept your Terms of Service!

I’ve long been a fan of Amazon’s E2, S3, FPS, SimpleDB, etc. These services are changing the way that early-stage startups make their platform decisions.

News outlets are quickly picking up that tonight Google is launching a hosted platform for web developers: App Engine.

I’m extremely excited about this for several reasons:

• Google is one of a handful of companies that have truly understand Internet scale. In addition, they have regularly dealt with the challenge of taking a small application and scaling it very quickly (nearly all of Google’s acquisitions go through this)
• By offering application hosting, Google is stitching together many of the components that Amazon’s services provide, making app development even quicker.
• While Amazon has been doing a great job pushing itself, the competition will be great and will raise the bar.
• It started off with Python support and is modeled after Django (which BrandVerity is built on and I’ve been very impressed with)

I look forward to seeing AppEngine develop further. I’m especially curious what it will take to launch an existing Django application on AppEngine.

I also learned for the first time that Google uses Python internally for its scripting. I guess that could explain all of the Google Python developer ads that keep popping up in my gmail account.

Update: I took a look through the documentation and now have a better handle on how AppEngine operates. It definitely borrows a number of aspects from Django:

• Django Templating Engine: The SDK provides Django’s templating engine (although it allows others to be used). The engine has been criticized by purists for allowing too much logic in the presentation layer, however I’ve found that the templates allow sufficient logic (if statements, for loops) to actually build webpages, while preventing the more complex view logic from making it to the front-end (variable assignment, method calls, etc.)
• Similar modeling system: In Django, you define your model classes and the framework provides common object methods that handle the sql underneath. The AppEngine models look very similar although it looks like the similarities are only conceptual (they definitely don’t share the same code and are interacted with in different ways). I can easily see how frameworks like Django (or Rails) could be modified to treat App Engine as another storage backend.
• Similar request and user frameworks: Django provides a few frameworks that are commonly used request.user (via contrib.auth) and its session middleware. These handle things like authentication, permissions, cookies, etc. Google’s APIs seem to function pretty similarly, although this isn’t exactly groundbreaking as these frameworks are fairly standard.

I don’t see a way to run python scripts that are independent of web requests. The O’Reilly article suggests that developers may utilize EC2 for batch operations. However, I have to believe that Google will support batch processing in some form as this forms a critical component of just about any web application (and I’m sure they don’t want to encourage people to write batch applications that are initiated by get statements)

I’m thrilled to announce that BrandVerity is now in closed alpha.

What is BrandVerity?

BrandVerity provides tools and services to identify and combat online trademark abuse.

The majority of the technology developed in this space has been developed by trademark abusers, while trademark owners typically resort to manual discovery techniques and are typically only engaging reactively.

Our first offering (still to be named) is a pay-per-click monitoring service that identifies trademark poaching by merchant affiliates.

What is Trademark Poaching?

If you’re a merchant with an affiliate program, you are probably already familiar with the practice of trademark poaching if not the name itself.

The most profitable search terms are those of a merchant’s own brand. Searchers that search for terms like ‘Macys’, ‘Amazon books’ and ‘Blue Nile coupons’ have already become familiar with the brand and are typically looking for the online store. The conversion rate of these visitors greatly exceeds that for generic searches.

Most e-commerce companies do not allow their affiliates to bid on these terms. The high conversion rates typically mean high bid prices and significantly higher cost of acquisition.

Grey and Black hat affiliates have found many ways to bid on these terms without the merchant noticing. They will day-part (run ads at night), reverse IP geotarget (run ads that target every city, but the one where merchant is based) and even copy the ads of merchant so that a visual scan of the search results won’t identify the poacher.

How does BrandVerity identify trademark poaching?

To put it simply, we know the tricks that the poachers use and our service uses technology that counters each of them. Some of the techniques are obvious and I’ll be talking about them later, but others aren’t and we’ll keep those private.

We understand that this is an arms race and are already working on the techniques we expect we’ll need when the poachers counter our techniques.

How do I get an alpha key?

I’m sure all of the readers of this blog have a burning need for trademark monitoring.

If by some chance you do have a need to monitor a few search terms on Google, and you’re willing to work with a bit of wet paint, drop me a note. The key bits of functionality are there but there is a lot that is still pretty rough. I’m watching load pretty closely so it may take a little bit before I send you the key.

Companies can easily spend $10K+ on identity and brand consultants while creating the company’s logo and related identity materials (letterhead, business cards, etc.). However, you typically only have access to the ideas and creativity of a handful of designers. Logo creation is much more art than science, so there is a good chance that you actually limit the process by working with an expensive consultant.

I spent $200 on a Sitepoint Design Contest to produce a logo for a new venture I’m working on. I received over 50 entries from ~20 designers. Some of the entries were definitely amateurish, however others were really well done.

The diverse ideas submitted by the designers were extraordinarily useful. I was able to look at many different ideas and would reinforce themes that I liked.

Logos are personal decisions
I solicited input from a handful of friends and colleagues. There was zero overlap on the designs - each person selected a completely different design or two as their favorites. The selection of a logo is always going to be a highly personal decision that reflects the unique likes/dislikes of the person running the process.

Which leads me to my final point:

The exact logo you use is one of the least important aspects of your business and you don’t want to spend a lot of time or money creating it. Find something that works and get back to creating value.

The guys at Cooler Planet, put together a very cool Google Map mashup of the growth of solar power in California.

You can see how solar panel installations have grown over time. I took these two screenshots of the installations in Northern California. I find it fascinating that there is more solar generating capacity in Berkeley than in San Francisco or Oakland.

2001	2008

They used hard-to-access, but publicly available data to build a yearly snapshot of the CA solar installations. I think its a great example of what you can do with government data that hasn’t really ever been put together in a compelling manner.

I’m thrilled to see them take a ‘content-rich’ approach to the solar space. While they don’t make money directly from work like this, it helps build their credibility and awareness in the space and helps establish themselves as a leading solar content destination.

(Disclosure: I made a small investment awhile back in Cooler Planet)

Conventional wisdom has held that if your’re selling software solutions to large companies you need an enterprise sales force.

The type of sales force is most frequently determined by your average selling price (ASP). If you can support $100K sales, then you use a field sales force. $10K to $100K and you use telesales (although I’ve seen it attempted at lower ASPs).

There are a number of reasons (beyond ASP) that would justify the use of a sales force (I’m sure I missed a few):

• The sale requires buy-in from multiple people (often in different organizations). Software hosted within internal IT departments is a great example.
• The decision makers are difficult to reach / difficult to discover. Some decision makers within an organization make themselves known and are easy to find. Others are uncomfortable with the spotlight and prefer to not have their name listed on the company website.
• The product is complex (or requires configuration, or has subtle benefits). The product can’t be fully conveyed on a website or in a white paper (that customers rarely read). Customer’s can’t figure it out on their own.
• The product is a commodity (or is perceived as one). The sales force gives customers a reason why they should buy a product from your company instead of your competitor’s.
• The solution isn’t a priority . This could because the pain your product solves isn’t great, or the capability it provides isn’t substantial enough.
• The product requires a commitment. It could be time invested to understand or configure the product, dollars to purchase it, or the opportunity cost of not selecting another solution.

The very nature of the products and the solutions they address requires a salesperson to sell them.

However, I’d argue that many products require a sales force because they are poorly designed. They are too generic, too complex, too undifferentiated…

Google (OK, Overture) completely overturned many assumptions about the enterprise sales force by creating massive amounts of value and by making it trivially easy to get started. 6 years ago it was inconceivable for a business to spend thousands a dollars a month on advertising without ever speaking to a sales rep.

I expect that one of the next waves of enterprise innovation will be software that doesn’t doesn’t require a sales force. It will require simpler products, that require minimal user investment, that address well-defined problems, and will very often be delivered over the web.

The products and services that accomplish this are going to price significantly below conventional enterprise-sales-based products. The conventional products will be structurally unable to compete at those price points.