Beyond the Buzzword: What “Viral” Really Means

“Every time I hear the word ‘viral’ I throw up a little in my mouth.”

Ok, I cheated a little.  No one I know actually said that out loud but I guarantee you that there isn’t a venture investor out there who hasn’t felt this way at one time or another.  Why?  Because some entrepreneurs waive that word around as if it’s a magic wand that can make any and all marketing related questions disappear.

It’s not.  And it stopped being cute months (years?) ago.  If you want to avoid investor MEGO, you need to show them that you truly understand what viral means for your service.  To that end, here’s a little primer on what I call “The Virality Spectrum.”

Negatively viral products are things you might use but that you actively don’t want others to know about.  If you use AshleyMadison.com to cheat on your spouse or spyware to get intel on the competition (or your spouse), you probably don’t want anyone to know.  It is certainly not impossible to market services like these, but do not expect testimonials from satisfied customers.  You had better have some other tricks up your sleeve to get the word out. AshleyMadison’s PR campaign is a good example.  If your keywords are cheap enough and your conversion rate and lifetime customer value high enough, search engine marketing can also do the trick.

Virally neutral products are ones that people use but don’t think much about. They tend to be utilities like Microsoft Word. We all use it, but when was the last time we bragged about it?  You can sell products like these with traditional advertising, marketing, distribution channel strategies, etc. but if you mention the word viral in a pitch for this type of company, you aren’t going to get very far.

Optionally viral products are ones where you hope people who really like then will pass the word on but there is really no special reason for them to do so other than the fact that they think you made something pretty cool and they want the social cred they can get from being the first to pass something new along to their peer group.  Games like Angry Birds certainly have gone viral but you never know when or where lightning will strike.   If you have a product like this and your strategy is to have it go viral, you had better have a lightening rod.  Put another way, would I invest in a record label that scouts out new music talent? No way. Would I invest in Simon Cowell‘s record label? Any day.

Inherently viral products are where things start to get interesting.  These services become more valuable for the user if he or she tells others.  The classic example of inherently viral products are Facebook, LinkedIn, and other social networks.  You still have to show that you can acquire that initial core audience (or better yet, that you already have that core), but if you can prove that you have an inherently viral product that fills a real need that no one else is servicing, you are well on your way to seeing a checkbook emerge from hiding.

But wait!  There’s more.  Some products go even further; they are necessarily viral.  These products can’t be used without letting your friends know about it.  In theory, you can use evite without emailing your friends, but it’s going to be a very small party.  Similarly, VolunteerSpot, the volunteer management tool I mentioned previously (and that – full disclosure – I am invested in), is designed to allow the prospective volunteers who you have invited to sign themselves up online for tasks.  Using VolunteerSpot without sending out that email or posting a link to your activity pretty much defeats the purpose.  With inherently viral products, using the service and the ask (“tell your friends”) are still separate tasks.  The beauty of necessarily viral products is that you don’t even have to ask.

So you can see why I love investing in necessarily viral products.  🙂

* I love them so much, I’m even working on one right now.  So of you are a developer / potential  CTO who appreciates the power of a necessarily viral service, give me a shout.

How To Handle Product Disconnect

“Why don’t you give Karen a call?”

I was chatting with Ryan Armbrust, an Associate at ff Ventures, about their portfolio companies.  ff Ventures is one of those rare VCs that has built a dedicated infrastructure within their fund to help their portfolio companies with the various functions (staffing, biz dev, et. al.) that they desperately need but are not yet able to support in-house.  Funds that devote full time resources to this are rare enough; in the early stage investment space that ff Ventures plays in, it is virtually unheard of.

We were discussing VolunteerSpot, a company that takes the pain out of organizing volunteer-led events.  87% of their nearly 3M users are moms and, since my prior two startups (Bunk1 & Layercake) were both family-focused, Ryan thought I might be able to offer some potentially useful insights.  So I set up a half hour call with their CEO, Karen Bantuveris.

Karen and I hit it off immediately.  A recovering consultant like myself, she built VolunteerSpot to solve a personal pain point.  As she explained, she would turn on her phone after a flight home from a client and her inbox flood with dozens of emails.  But work was not the worst culprit; the majority of the email overload had to with her personal life.  Every time she was invited to volunteer for something (e.g., with her daughter’s school, her church), she entered Reply All Hell.  You know the place.  It’s where otherwise intelligent people think it’s fine to spam all their friends with short emails (“I’m in,” “Sounds great!”, “Cool!!!”, etc.) that don’t answer the question (e.g., “When can you man the concessions table?”) or omit key info (e.g., their name (Really?!), their contact info).

Two hours into this half-hour call, we finally agreed to finish the conversation the next day.  By the end of the week, we were talking about my devoting a sizable block of time to help them with strategic partnerships and business development.

Now I am a product guy at heart.  As much as any non-developer can make this claim, I build every product I have ever been involved with from the ground up, from vague concept, to prioritized feature list, MVP, wireframes, detailed specs, UX, etc. all the way through QA and customer support.  But because everyone at a startup wears multiple hats, I’d also done quite a bit of biz dev, marketing, sales – whatever had to get done – so I dove right in.

After a few weeks of networking, I began to notice a strange feeling of disconnect from the product I was pitching.  I quickly figured out why: every other time I’d done biz dev it had been for products I’d built.  I knew them intimately, inside and out.  If a potential partner had a slightly atypical use case, I knew which lesser-used product feature to steer him to.  If he wanted something custom-coded, I had a good sense of whether it was a big or small ask from the tech team.  But VolunteerSpot was built and up-and-running over a year before I got involved and so, for the first time, I didn’t have that deep product knowledge.  It felt oddly surreal.

So I’ve had to adapt a little.  I am happy to share my strategies for beating product disconnect… and eager to get any suggestions you might have.

1.       Learn the product

There’s no excuse for not putting in the hours.  You should know enough about the company to understand the typical use cases and to try to use product that way.  Then look through the help section of the website to get a feel for known limitations, suggested workarounds, and other, less typical use cases.

It helps to have a few email accounts you can use for testing, especially if your product has multiple user types.  For instance, I needed to experience VolunteerSpot’s services both as an event organizer and as a participating volunteer.  If you use gmail, you can set up email aliases on the fly for this.  If your actual email is yourname@gmail.com, you can use yourname+organizer@gmail.com and yourname+volunteer@gmail.com.  No prior setup is required and both emails will go to your normal address but you will be able to tell which email was sent to which user by seeing which alias is in the email’s sent to field.

2.       Set expectations

In my case, since I don’t have an official role at VolunteerSpot, I often frame my participation as my “helping out a company that I am invested in.”  So if I don’t know every nook and nuance of the service, it is to some extent excusable.  When this is not an option, you might instead acknowledge that you joined the company relatively recently.  Done correctly, this can segue into all the great things about your current company that seduced you into leaving your old one.  Sometimes the same pitch sounds less salesy when phrased as “but what I really loved about this company….”

And when all else fails, you can always mention a recent product redesign.  🙂

3.       Don’t fake it

It’s much better to firmly say, “I think so / don’t think so but let me double-check and get back to you” than it is to fake it and not sound genuine.  Or worse, get caught getting it wrong.  If you’ve done your homework (see #1 above), odds are that this situation will only arise in response to an obscure or novel use case.  Your prospect is likely even aware that he is taking things off the beaten track and won’t judge you harshly if you don’t have the answer right away.

4.       Learn from it

When this happens, don’t just hook your prospect up with someone else in the company who can answer the question.  You talk to the expert and educate yourself.  Or invite the expert to a conference call to answer the prospect’s questions while you listen and learn.

(Afterthought: Reading over the post above, I can’t help wondering how wide an audience it will find.  Seasoned biz dev professionals may find this advice blindingly obvious; they may be used to joining companies after the early building stage and accept some level of product disconnect as entirely normal.  On the flip side, startup veterans are more likely to be handing off their biz dev role to the pro when their companies reach that level than they are to be taking on a biz dev role at a different company.  So please let me know if you found this post useful or not.)