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.

We’ve been wrestling with a difficult decision for awhile at BrandVerity - how much information should we share about the techniques affiliates are using to hide from our customers?

Our company’s focus is on detecting affiliates that are violating their agreements with their merchants. These agreements typically disallow very specific activities (purchasing the merchant’s trademarked terms on paid search).

We certainly want to provide detailed insights to our customers but we also want to be careful of teaching would-be-abusers how to improve their techniques. This balancing act is a challenging one for us and up until now we’ve kept any discussion of the advanced techniques used mostly out of public discourse.

We decided to change that, and have posted our first detailed discussion of a technique used by affiliates to evade detection to BrandVerity’s blog. We also sent a more detailed version of this post to our customers before the post went live on our website.

Over time, we’ve seen the techniques used become more advanced and more widespread. We’ve seen deep and detailed discussions on blackhat forums, and even seen the launch of paid services that assist new abusers.

We haven’t seen a commensurate increase in industry awareness. The discussions on most whitehat forums continue to focus on the more basic techniques, and there is little to no discussion of them in educational resources available. Our intentions aren’t entirely selfless - we expect these posts to not only raise awareness of the techniques, but also to increase awareness of who we are and what we do. But that incentive has always been there and if anything is less impactful now than it might have been earlier in our growth. Ultimately, we felt that we have recently seen a shift in the balance of information too far in favor of the abuser.

Our intent is now to continue to discuss the tactics used in an open and transparent manner. This was not a decision we made lightly and we may reconsider it in the future.

Well, sort of. One of my articles in FeedFront was republished in Internet Marketing from the Real Experts. I guess I can now call myself one of the ‘Gang of 88’. I’ll have to give more thoughts later on my newly acquired gang membership…

Although the distribution of the book will likely be similar to the magazine, I can’t help but feel that getting published in a book is more substantial. I guess old media habits die hard.

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!

Matt has an excellent post up on the blist blog on cohort analysis. I’ll post a teaser graph here to give you reason to click through and read the full post:

Cohort analysis and Churn at BrandVerity

We’ve been thinking through a lot of the points that Matt makes in his post as we try to understand a common signup pattern: A user sets up their trial account and then never returns.

Tire-kickers or Satisfied Customers?

All services have a signup drop-off, but it is particularly hard for us to write off those users as ‘tire-kickers’: their behavior is nearly identical to what our most satisfied customers do. We strive to provide only actionable information in our daily emails, so that people monitoring trademarks receive all the information (and only the information) they need to make a decision or take action. So satisfied customers rarely visit the interface and instead interact mostly with our emails.

I had a great conversation with Chris Sanderson at AMWSO earlier in the week that shed some light on a likely cause. He had been trialling the service, but hadn’t returned to the site since creating his account. As I walked him through the online interface, he helped me understand the gap between trial customers and paid accounts.

We provide a lot of depth in our emails, but that depth can be illusory. Chris had thought that the emails were the extent of the service and not only did he find the depth lacking, he also found the emails somewhat overwhelming.

Most of our paid customers had either received a walk-through of the online interface or had been with us as the interface has developed. They understand the depth of the service, and also have tweaked their settings to refine the alerts they receive.

So, what next?
Well, obviously we need to do a better job with our trial funnel. We need to introduce the service better over the trial period. We need more information on the service outside the signup page (we had assumed that since signup was so easy, sceenshots and product literature weren’t important). We also need to create a few bits of ‘feature candy’ that encourage deeper interaction in a fun way.

We’ve also given thought to increasing the barrier to signup (require a credit card, or a second step in the signup process). However, trials cost us very little and additional barriers don’t seem like the right step at this point - improving the conversion funnel does.

While we can’t do quantitative cohort analysis (not enough volume), we’ll definitely qualitatively evaluate each ‘feature cohort’ as we evolve the service.

Back in grammar school our class sold greeting cards as a fund raiser. I don’t remember why we had a fund raiser, but I do remember that if an individual sold enough greeting cards, they would get a Nintendo.

My parents didn’t exactly favor video games so I quickly realized that the only way I’d be playing Mario Brothers at home was to go get orders for greeting cards. After hitting up every adult I knew, I found myself with only enough orders for a small inflatable raft - about 70 shy of the Nintendo. So, I did the only thing I could think of - began knocking on doors.

I quickly figured out where to target my efforts. The rich neighborhoods weren’t the place to go: the houses were too far apart and people were rarely home. However, people that were retired were always home and they couldn’t resist buying Christmas cards from a grade schooler. I also learned that if I never asked them to purchase the cards, they would talk for hours and not buy any cards. Early on, I would walk away with a full stomach and a head full of wisdom, but I wasn’t any closer to the Nintendo.

Asking for the sale comes naturally to some people. Not me. But it is a skill that can be taught and learned. It can be practiced and over time it becomes more natural. It is a necessity for early-stage survival and can often be the sole obstacle to companies founded by purely technical teams that expect their products to sell themselves.

BrandVerity began asking our alpha customers for a sale this week. I’ve been very pleased with the response and find few things as invigorating as the reinforcement of our work that comes with a ‘yes’. There is no greater recognition of value creation than a customer’s willingness to pay.

But you’ll never know unless you ask.

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)