FrameThink

Structured Approach to Event Blogging

2011-09-28T11:41:00.000-07:00

I like the "linkable assets model" in this SEJ post: http://www.searchenginejournal.com/effective-link-building-using-event-blogging/34104/

It's a nice, structured way to think about how to get inbound links for your event blog (if you're an event blogger and care about that kind of thing) :-)

The Language of Social Networks

2011-09-25T20:33:00.000-07:00

Facebook and Mark Zuckerberg have established near monopoly control over the language that we use to talk about social networks. Think about the words that we use to describe social network sites -- terms such as "like", "share", "connect", "transparent", "more open", etc. I'm not saying that Facebook were the first company to use these terms and they certainly didn't invent them. But I do believe that Facebook have been the most effective and the most consistent at using those words to frame the conversation about social network policies and features in moral terms.

The moral framework they're creating around their social network site is really key to focus on. Facebook are saying: It's *good* to be liked, right? It's *good* to connect to more people, right? You're a *better* person if you're willing to share more transparently, right? And, conversely, if you're *not* willing to share a thought or action openly, then what are you hiding; are you doing something that you *shouldn't* be doing?

Facebook have purposefully created this moral linguistic context for their service. As Zuckerberg masterfully puts it:

At Facebook we have a deeply held purpose [...] Our mission: “Give people the power to share and make the world more open and connected.” In the world we’re building where the world is more transparent, it becomes good for people to be good to each other. That’s really important as we try to solve some of the world’s problems.
Source: http://www.insidefacebook.com/2008/07/23/live-notes-from-mark-zuckerbergs-keynote-at-f8-developer-conference/

George Lakoff, professor of linguistics and cognitive science tells us that, in any debate, if one side manages to dominate the moral framing of the issues, then they've already won the debate before it even begins. Facebook appear to have learned Lakoff's lessons well. By framing the debate about social network policies and features in their own moral terms, Facebook could be walking away with victorious dominance over the social internet without firing a shot! Every other social internet company has been forced to define themselves using Facebook's terminology of "sharing", "openness" and "social graphs" (i.e., attempting to beat Facebook at their own game) or to contrast themselves against Facebook's feature functionality (i.e., attempting to convince the world that sharing, openness, and transparency are bad things). It's a lose-lose proposition either way and that makes it really hard for other companies to market and differentiate themselves using the language and concepts that Facebook own.

What are your thoughts on how the social network industry should move forward from here? I'll jot down some thoughts in my next blog post. Would love to hear your thoughts in the meantime.

Crafting Code Across the Stack: 3 Benefits of Cross-Technology Engineering

2011-07-06T23:26:00.000-07:00

One of the engineers in my startup asked some thought-provoking questions in a hallway conversation today:

Should engineers own end-to-end implementation of features that cut across multiple layers of our technology stack? Or should engineers focus/specialize on specific layers of the stack and collaborate with each other to develop each feature?

I've repeatedly observed that small teams of developers run circles around large teams in every company I've ever been in. [Caveat: I focus on consumer internet software, so my observations will be biased towards that industry.] I have a strong preference for company cultures that encourage individual engineers to develop as much of a featureset as they can on their own. If there's a front-end user interface to be created as well as a backend API required to support a particular feature, I'd like to see the same engineer coding it all. Obviously this isn't always possible for either technical or personnel constraints, but it is the ideal in my mind.

Today's announcement of Facebook's integration with Skype is a timely example of this principle in action. I wasn't a direct part of that integration project, but knew the folks on both sides. With two big companies like Facebook and Skype coming together, there were dozens of people involved in the overall project. Even so, it was really remarkable to me to see how much of the integration really hinged on two key individuals -- one on the Facebook side and one of the Skype side. Both of those individual engineers are really amazing "multi-lingual" developers who were able to make key coding contributions across multiple layers of technology ranging from Java applets and compiled desktop executables to in-browser Javascript and CSS/HTML to server-based API's and cloud services.

Seeing that reminded me of the three main benefits of getting engineers to own entire featuresets, even (or maybe especially) if they cut across multiple technologies...

1. Motivation

When an individual engineer works on a feature that they know is going to impact large numbers of users, they viscerally feel the huge contribution they're making to their company (and society!). Nothing is more motivating than feeling like your work really makes a difference.

2. Quality

An engineer who really understands an entire featureset front-t0-back is able to grok critical dependencies between technology layers more effectively than a team of multiple individuals. I assert that the ability to see the whole picture enables the single engineer to more effectively write test cases, identify likely breaking points, and ultimately deliver higher overall quality code that is defensively coded against future commits.

3. Iteration

This is a key advantage for individual engineers: the engineer who designed and coded an entire featureset on their own will be more likely and much faster to modify/iterate their designs when presented with market feedback from real consumers. In contrast, a team of engineers who each only coded parts of a feature (and therefore relied on some other person, usually a project manager or a product manager, to provide a holistic view and integration guidance) will be much slower to collectively process market feedback and iterate.

Now, this may all be much easier said than done... For one thing, it's hard enough to recruit great engineers in any given technical area, much less a team of cross-technology superstars. And in practice, there are significant friction points to the lone-ranger style of development. E.g., if every engineer is a gun slinger they may unwittingly produce a lot of conflicting or redundant code that at some point needs to refactored. Furthermore, even if an engineer is capable of contributing code across many different levels of a tech stack, that doesn't mean they will always *want* to do so...

Even netting out those potential disadvantages, I think that cross-technology development has a strong positive impact; especially in the consumer internet space where companies actually have a decent shot at recruiting engineers who can effectively contribute code across the entire LAMP (or insert your favorite mobile or web development framework here) stack. And even if your company doesn't, in practice, hand over entire featuresets to a single engineer to execute, I think it's still really important to foster cross-technology understanding. It can only benefit your team if the javascript front-end wizard really understands the database impact that all her AJAX calls are going to produce; or if your backend API engineer really understands how often and how quickly his REST services will be requested by a mobile client; etc.

Have you ever worked in a company that had a policy of "single engineer owns an entire feature"?

How employees get screwed in private equity deals

2011-06-23T22:22:00.000-07:00

I learned a hard lesson from working with a ~~bunch of rat bastards~~ leading private equity firm, Silver Lake. I joined Skype after the company was spun out of eBay by SilverLake in deal valued at $2.7B and was recruited to help accelerate the pace of product development and make the Skype app more web-oriented. I was at the company for just over a year in a product management role and felt like my team accomplished some important things along the way, including reduction of software development cycles from months down to 2-weeks and delivery of a whole new advertising revenue stream to the company. It was a fun and challenging job, involving tons of international travel and I met some amazing people along the way.

Now despite the fact that Skype has a Palo Alto office and kind of seems like it would fit right in with Silicon Valley tech companies, it turns out that the employment terms for a Silver Lake company are *very* different from what most Valley high-tech employees are used to. Here are three important things to watch out for if you're thinking about joining a company that is being managed by a private equity firm or if your company gets taken over by a PE bank.

1. Lawyer Up

(image credit: http://weheartit.com/entry/5625871)

The most important lesson I learned from Skype was that compensation and stock policies in PE-owned firms can be very heavily tilted in the owners' favor and against the employees. Skype employees have 5-year vesting of stock options, for example, not the usual 4 year schedule that most Valley firms have. Even worse, Skype's stock option agreement had special clauses that the Board had slipped in that gives them the right to "repurchase" any vested shares for anyone who leaves the company voluntarily or is terminated with cause -- effectively taking "vested" shares and making them worthless. Here's a nice letter I got from the Associate General Counsel of Skype that points out exactly how my stock options have "no financial value." (see lee.pdf). Gee, thanks.

Now, I've seen my share of legal documents for tech companies. I've worked in Valley tech companies for over 15 years, have founded startups, done VC financings, and invested in companies. None of that prepared me for the kinds of legal shenanigans that the PE guys at Silver Lake pulled because I had never come across those kinds of terms before, let alone the fact that these clauses were hidden as one-liners in otherwise pretty standard-looking documents. (see Stock Option Grant Agreement for Kuo-Yee Lee - signed)

So my first point of advice to anyone considering working for a PE-lead firm is to LAWYER UP -- it'll be worth your while to get an attorney to carefully review all employment documents so that you know what you're really getting into.

2. The Bobs

Working with Silver Lake was my first opportunity to witness up-close-and-personal how a PE firm does its business of restructuring a company that they've just taken over. And it was breath-taking. The firm inserted itself into every level of the company. At one point in my tenure at Skype, Silver Lake had representatives or consultants on the Board, in C-level executive roles, in technical leadership and operating roles, and all the way on thru the organization to the person actually running our software deployment schedule... So Silver Lake put its fingers really deeply into Skype's pie and they started rearranging things.

You can agree or disagree with the practice of re-organization, but I personally had never been part of a restructuring that ran so deep in a company. During the year I was at Skype, the company:

lost a CEO

hired and fired a CTO

hired and fired a CFO

gained a CEO, CMO, CIO, and CDO

created an entirely new product development org structure

eliminated every Project Manager role

fired, re-interviewed, and re-hired Product Managers

created a two new business units

combined two business units into one

dissolved one business unit

opened a new office and hired several hundred people

the list goes on...

I mean, these are crazy changes for any company to go through over the course of years. To have that all happen within a short number of months was staggering. The conventional wisdom in Silicon Valley is that good engineers and product designers will always have job security. Still, there were times at Skype when even really solid engineers and designers were asking me if their jobs were going to be safe from all the changes going on.

So, second major lesson learned: prepare your resume and get ready to re-interview for your job (or a different one) because organizational change is a major part of the private-equity-lead restructuring of a company!

3. It Ain't Over 'til It's Over

Even if an employee of a PE-owned company has avoided the legal beartraps and weathered the re-org'ing, they're still not safe. Even as Skypers were celebrating the huge potential of the Microsoft deal, the PE bankers were sharpening their knives and plotting which employees to fire in order to maximize profits and minimize payouts to non-owners. Seriously, how greedy do you need to be to make $5B and still try to screw the people who made that value possible? I mean, Silver Lake is trying to hyper-optimize their returns to the point that they're trying to deny employee payouts that amount to less than 0.3% of the returns that they'll get from the deal. Srsly. Really?

So, just be warned: Silicon Valley startup folks may think we've had hard dealings with venture capitalists... But in my opinion, VC greed pales in comparison to the level of greed exhibited by the Silver Lake private equity firm.

And there you have it, my top three lessons learned from being raked over the coals by a PE firm.

Have your own story? Leave a link or comment below!

Three user-generated content UX principles

2011-04-29T13:41:00.000-07:00

Three UGC UX principles that I'm working towards in my products:
1) Fast -- sub-200 millisecond response time to any user input
2) Assistive -- give users something to react to; rather than forcing them to generate their own novel content
3) Learning -- system improves with every user click or action

What are your top three?

How Facebook Ships Code

2011-01-16T22:14:00.000-08:00

I'm fascinated by the way Facebook operates. It's a very unique environment, not easily replicated (nor would their system work for all companies, even if they tried). These are notes gathered from talking with many friends at Facebook about how the company develops and releases software.

Seems like others are also interested in Facebook... The company's developer-driven culture is coming under greater public scrutiny and other companies are grappling with if/how to implement developer-driven culture. The company is pretty secretive about its internal processes, though. Facebook's Engineering team releases public Notes on new features and some internal systems, but these are mostly "what" kinds of articles, not "how"... So it's not easy for outsiders to see how Facebook is able to innovate and optimize their service so much more effectively than other companies. In my own attempt as an outsider to understand more about how Facebook operates, I assembled these observations over a period of months. Out of respect for the privacy of my sources, I've removed all names and mention of specific features/products. And I've also waited for over six months to publish these notes, so they're surely a bit out-of-date. I hope that releasing these notes will help shed some light on how Facebook has managed to push decision-making "down" in its organization without descending into chaos... It's hard to argue with Facebook's results or the coherence of Facebook's product offerings. I think and hope that many consumer internet companies can learn from Facebook's example.

HUGE thanks to the many folks who helped put together this view inside of Facebook. Thanks are also due to folks like epriest and fryfrog who have written up corrections and edits.

Notes:

as of June 2010, the company has nearly 2000 employees, up from roughly 1100 employees 10 months ago. Nearly doubling staff in under a year!

the two largest teams are Engineering and Ops, with roughly 400-500 team members each. Between the two they make up about 50% of the company.

product manager to engineer ratio is roughly 1-to-7 or 1-to-10

all engineers go through 4 to 6 week "Boot Camp" training where they learn the Facebook system by fixing bugs and listening to lectures given by more senior/tenured engineers. estimate 10% of each boot camp's trainee class don't make it and are counseled out of the organization.

after boot camp, all engineers get access to live DB (comes with standard lecture about "with great power comes great responsibility" and a clear list of "fire-able offenses", e.g., sharing private user data)

[EDIT thx fryfrog] "There are also very good safe guards in place to prevent anyone at the company from doing the horrible sorts of things you can imagine people have the power to do being on the inside. If you have to "become" someone who is asking for support, this is logged along with a reason and closely reviewed. Straying here is not tolerated, period."

any engineer can modify any part of FB's code base and check-in at-will

very engineering driven culture. "product managers are essentially useless here." is a quote from an engineer. engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime. [EDITORIAL] The author of this blog post is a product manager, so this sentiment really caught my attention. As you'll see in the rest of these notes, though, it's apparent that Facebook's culture has really embraced product management practices so it's not as though the role of product management is somehow ignored or omitted. Rather, the culture of the company seems to be set so that *everyone* feels responsibility for the product.

during monthly cross-team meetings, the engineers are the ones who present progress reports. product marketing and product management attend these meetings, but if they are particularly outspoken, there is actually feedback to the leadership that "product spoke too much at the last meeting." they really want engineers to publicly own products and be the main point of contact for the things they built.

resourcing for projects is purely voluntary.
- a PM lobbies group of engineers, tries to get them excited about their ideas.
- Engineers decide which ones sound interesting to work on.
- Engineer talks to their manager, says "I'd like to work on these 5 things this week."
- Engineering Manager mostly leaves engineers' preferences alone, may sometimes ask that certain tasks get done first.
- Engineers handle entire feature themselves -- front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on. Same for Architect help. But in general, expectation is that engineers will handle everything they need themselves.

arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.

engineers generally want to work on infrastructure, scalability and "hard problems" -- that's where all the prestige is. can be hard to get engineers excited about working on front-end projects and user interfaces. this is the opposite of what you find in some consumer businesses where everyone wants to work on stuff that customers touch so you can point to a particular user experience and say "I built that." At facebook, the back-end stuff like news feed algorithms, ad-targeting algorithms, memcache optimizations, etc. are the juicy projects that engineers want.

~~commits that affect certain high-priority features (e.g., news feed) get code reviewed before merge.~~ News Feed is important enough that Zuckerberg reviews any changes to it, but that's an exceptional case.

[CORRECTION -- thx epriest] "There is mandatory code review for all changes (i.e., by one or more engineers). I think the article is just saying that Zuck doesn't look at every change personally."

[CORRECTION thx fryfrog] "All changes are reviewed by at least one person, and the system is easy for anyone else to look at and review your code even if you don't invite them to. It would take intentionally malicious behavior to get un-reviewed code in."

~~no QA at all, zero~~. engineers responsible for testing, bug fixes, and post-launch maintenance of their own work. there are some unit-testing and integration-testing frameworks available, but only sporadically used.

[CORRECTION thx fryfrog] "I would also add that we do have QA, just not an official QA group. Every employee at an office or connected via VPN is using a version of the site that includes all the changes that are next in line to go out. This version is updated frequently and is usually 1-12 hours ahead of what the world sees. All employees are strongly encouraged to report any bugs they see and these are very quickly actioned upon."

re: surprise at lack of QA or automated unit tests -- "most engineers are capable of writing bug-free code. it's just that they don't have an incentive to do so at most companies. when there's a QA department, it's easy to just throw it over to them to find the errors." [EDIT: please note that this was subjective opinion, I chose to include it in this post because of the stark contrast that this draws with standard development practice at other companies]

[CORRECTION thx epriest] "We have automated testing, including "push-blocking" tests which must pass before the release goes out. We absolutely do not believe "most engineers are capable of writing bug-free code", much less that this is a reasonable notion to base a business upon."

re: surprise at lack of PM influence/control -- product managers have a lot of independence and freedom. The key to being influential is to have really good relationships with engineering managers. Need to be technical enough not to suggest stupid ideas. Aside from that, there's no need to ask for any permission or pass any reviews when establishing roadmaps/backlogs. There are relatively few PMs, but they all feel like they have responsibility for a really important and personally-interesting area of the company.

by default all code commits get packaged into weekly releases (tuesdays)

with extra effort, changes can go out same day

tuesday code releases require all engineers who committed code in that week's release candidate to be on-site

engineers must be present in a specific IRC channel for "roll call" before the release begins or else suffer a public "shaming"

ops team runs code releases by gradually rolling code out
- facebook has around 60,000 servers
- there are 9 ~~concentric~~ levels for rolling out new code
- [CORRECTION thx epriest] "The nine push phases are not concentric. There are three concentric phases (p1 = internal release, p2 = small external release, p3 = full external release). The other six phases are auxiliary tiers like our internal tools, video upload hosts, etc."
- the smallest level is only 6 servers
- e.g., new tuesday release is rolled out to 6 servers (level 1), ops team then observes those 6 servers and make sure that they are behaving correctly before rolling forward to the next level.
- if a release is causing any issues (e.g., throwing errors, etc.) then push is halted. the engineer who committed the offending changeset is paged to fix the problem. and then the release starts over again at level 1.
- so a release may go thru levels repeatedly: 1-2-3-fix. back to 1. 1-2-3-4-5-fix. back to 1. 1-2-3-4-5-6-7-8-9.

ops team is really well-trained, well-respected, and very business-aware. their server metrics go beyond the usual error logs, load & memory utilization stats -- also include user behavior. E.g., if a new release changes the percentage of users who engage with Facebook features, the ops team will see that in their metrics and may stop a release for that reason so they can investigate.

during the release process, ops team uses an IRC-based paging system that can ping individual engineers via Facebook, email, IRC, IM, and SMS if needed to get their attention. not responding to ops team results in public shaming.

once code has rolled out to level 9 and is stable, then done with weekly push.

if a feature doesn't get coded in time for a particular weekly push, it's not that big a deal (unless there are hard external dependencies) -- features will just generally get shipped whenever they're completed.

getting svn-blamed, publicly shamed, or slipping projects too often will result in an engineer getting fired. "it's a very high performance culture". people that aren't productive or aren't super talented really stick out. Managers will literally take poor performers aside within 6 months of hiring and say "this just isn't working out, you're not a good culture fit". this actually applies at every level of the company, even C-level and VP-level hires have been quickly dismissed if they aren't super productive.

[CORRECTION, thx epriest] "People do not get called out for introducing bugs. They only get called out if they ask for changes to go out with the release but aren't around to support them in case something goes wrong (and haven't found someone to cover for you)."

[CORRECTION, thx epriest] "Getting blamed will NOT get you fired. We are extremely forgiving in this respect, and most of the senior engineers have pushed at least one horrible thing, myself included. As far as I know, no one has ever been fired for making mistakes of this nature."

[CORRECTION, thx fryfrog] "I also don't know of anyone who has been fired for making mistakes like are mentioned in the article. I know of people who have inadvertently taken down the site. They work hard to fix what ever caused the problem and everyone learns from it. The public shaming is far more effective than fear of being fired, in my opinion."

It'll be super interesting to see how Facebook's development culture evolves over time -- and especially to see if the culture can continue scaling as the company grows into the thousands-of-employees.

What do you think? Would "developer-driven culture" work at your company?

Four early-PayPal entrepreneurial culture norms

2010-05-04T16:32:00.000-07:00

(in response to Quora question "Which strong beliefs on culture for entrepreneurialism did Peter / Max / David have at PayPal?")

Four aspects of early PayPal culture really stood out to me when I joined as a product manager:
1) self-sufficiency -- individuals and small teams were given fairly complex objectives and expected to figure out how to achieve them on their own. If you needed to integrate with an outside vendor, you picked up the phone yourself and called; you didn't wait for a BD person to become available. You did (the first version of) mockups and wireframes yourself; you didn't wait for a designer to become available. You wrote (the first draft of) site copy yourself; you didn't wait for a content writer.

2) extreme bias towards action -- early PayPal was simply a really *productive* workplace. This was partly driven by the culture of self-sufficiency. PayPal is and was, after all, a web service; and the company managed to ship prodigious amounts of relatively high-quality web software for a lot of years in a row early on. Yes, we had the usual politics between functional groups, but either individual heroes or small, high-trust teams more often than not found ways to deliver projects on-time.

3) data-driven decision making -- PayPal was filled with smart, opinionated people who were often at logger-heads. The way to win arguments was to bring data to bear. So you never started a sentence like this "I feel like it's a problem that our users can't do X", instead you'd do your homework first and then come to the table with "35% of our [insert some key metric here] are caused by the lack of X functionality..."

4) willingness to try -- even in a data-driven culture, you'll always run in to folks who either don't believe you have collected the right supporting data for a given decision or who just aren't comfortable when data contradicts their gut feeling. In many companies, those individuals would be the death of decision-making. At PayPal, I felt like you could almost always get someone to give it a *try* and then let performance data tell us whether to maintain the decision or rollback.

Those four cultural attributes actually make up a lot of the attitudes and beliefs that you'd expect to see in great entrepreneurs -- i.e., multi-disciplinary, self-sufficient, action-oriented, data-driven experimentalists. So it's no surprise to see the number of successful startup ventures founded by PayPal alums. To be sure, PayPal is/was not unique -- I would expect any company that established these kinds of cultural norms to produce a lot of entrepreneurs.

Four Viral Loop Drivers [updated]

2010-03-28T18:36:00.000-07:00

I was noodling about different categories of viral loops and started making a list...

Viral Loops typically center on:

Contact Lists -- e.g., inviting new people thru the process of finding/adding new contacts to a contact list

Conversations -- e.g., inviting new people by adding them to chats, events, groups, etc.

Media -- e.g., inviting new people by sharing media/content with them

Incentives -- e.g., inviting new people to unlock functional or financial incentives

Any others that you can think of?

Five Points for Better Exec Summaries and Briefings

2010-01-31T20:54:00.000-08:00

Here's a quick five-point format for executive summary/briefing documents. This is intended to be a short "get to know you" briefing for prospective investors. It's also supposed to be a scalable document -- that is, you can expand it into a full business pitch deck by fleshing out each section more. Or you can compress it all the way down into a single paragraph by just putting the punchlines together.

I'd recommend doing this in a single page (it's good discipline to be brief). The bullet points of each section should all build towards the punchline.

1) Team

Bullet points: Quick recap of team members' experience

Punchline: why your team has the right experience and/or unique industry connections that give you an unfair advantage in this business

2) Market size

Bullet points: who are your paying customers? who are your users (for ad/audience-driven businesses)? what's the overall industry size? what specific segment (or sub-segment) of that industry are you going to dominate? how big is that segment (e.g., how many customers/users are there in your target initial segment multiplied by your expected penetration of that segment multiplied by anticipated customer lifetime value)?

Punchline: there's a believable path for the company to get to $100MM in annual revenue

3) Customer tests

Bullet points: if working alpha/beta product, then what are the customer/user activity stats like? if no product yet, then what surveys, smoke tests, or mockup tests have you run?

Punchline: we're not just sitting in an office making up a business plan; we've gone out to talk with real customers or users, lots of them. We've tested working product or realistic mockups with customers/users and they like it.

4) Distribution strategy

Bullet points: how will your customers/users learn about your service? how much do you need to pay per customer/user acquisition? how will you drive a customer/user adoption curve that is doubling every month?

Punchline: we know how to reach customers/users. we're not gonna end up blowing your money on building something that it turns out we can't sell.

5) Deal and Milestones

Bullet points: how much are you looking to raise? what will that money be used for; e.g., what milestones will you hit? what questions will you be able to answer with this investment? which risks will be de-risked with this investment? how long will these milestones take to achieve?

Punchline: your money is going to buy significant reductions in risk (and therefore significant increases in the next valuation)

Hope that's helpful. Did I miss anything? Leave any questions or edits in the comments section... Thanks!

TEDxSV LiveBlog

2009-12-12T11:05:00.000-08:00

My notes on ideas that struck me at TEDxSV

Ustream broadcast: http://bit.ly/7nBVEw

Twitter hashtag: #tedxsv

Steve Blank explains the evolution of Customer Development

2009-09-07T13:04:00.000-07:00

If you're an entrepreneur or are thinking about starting a company, Steve Blank's blog is must-read material.

Steve's latest series of posts establishes the reasons why Customer Development and Lean Startup methodologies are so important (and why prior models of startup development often resulted in failure). Read them in order:

The Leading Cause of Startup Death

Customer Development Manifesto Part I

Customer Development Manifesto Part II

Customer Development Manifesto Part III

Customer Development Manifesto Part IV

Many Benefits and The One Big Risk for Entrepreneurs-in-Residence

2009-08-08T02:35:00.000-07:00

See my last post for context: http://framethink.wordpress.com/2009/08/08/what-does-an-eir-do/

There are some really great benefits that come from being associated with a venture fund as an entrepreneur-in-residence (EIR).

EIRs have a unique position that makes it easier to launch a company. In some ways, being an EIR actually inverts the typical resource-gathering exercise that most entrepreneurs go through -- the partners at a venture firm will often pitch ideas to their EIR's and they continuously introduce their EIR's to interesting and talented people who could be potential co-founders or business partners. The first time that happened to me as an EIR, I was completely bowled over by the fact that a venture capitalist was actually pitching me on an idea instead of the other way around -- it's an interesting role reversal to say the least!

EIR roles are also fantastic for research. EIR's get direct access to their firm's partners for feedback, advice, and brainstorming. They get to sit in on business pitches and help evaluate them from the VC's perspective. Participating in pitches and listening to how your venture firms partners think about companies is a truly precious learning experience... Think about how many VC pitches you might be involved with directly as an entrepreneur -- through the span of an entire career, how many VC pitches do you think might give? Ten? Twenty? An EIR might get to see that many pitches within a few weeks if they wanted to. Getting exposure to that volume of pitches in a compressed time frame really helps an EIR develop a comparative study of business pitches and gives you an opportunity to see what happens when teams come in to pitch in various states of preparedness & maturity, with varying styles, and different team compositions. With full advantage of those learnings and direct access to their firm's partners, an EIR should end up with a very good understanding of what pitches will work for their firm (and which ones won't).

And let's not forget the great fringe benefits of being at a venture fund! Most VC's have very nice office buildings that are quiet, secure, ergonomic places to work (much nicer than trying to do conference calls while hunched over a noisy cafe table). Firms always have free snacks, coffee, and sodas to power you through long days. Plus they have comfy couches to crash on after that all-nighter.

It's not all sugar and spice, though -- there are serious downsides to being an EIR, too...

It's seductively easy to hang out in a swanky office, sit in on meetings all day long, listen to other entrepreneurs pitch, and dispense your opinions. It's fun to play "the connector" role -- introducing that entrepreneur you met at a conference to the firm's partners. The partners appreciate it. The entrepreneur who is raising a round really appreciates it. And you get to give your ego a smug pat on the back for being so smart and well-connected. All of that is so fun and easy that an EIR might literally spend entire days taking calls, doing meetings, vetting ideas, and introducing people (mea culpa). That may be fine if the EIR is trying to add value to the firm by essentially playing an associate's role, but definitely is not helping the EIR directly learn about use-cases that a customer would actually pay for or launch a new company per se. So there is this unfortunate but very real tension between spending time helping the firm vs. working on launching a new venture.

This notion of the balance between an EIR's firm vs. an EIR's startup leads me to the The One Big Risk for EIRs...

The tension between firm vs. EIR becomes most apparent if/when the entrepreneur seeks financing for their new startup. VentureHacks would tell you (and I would agree) that the key to closing a financing quickly with favorable terms is to have a strong BATNA. But an EIR is at a fundamental disadvantage in getting their company favorable financing terms relative to a non-EIR making the exact same pitch... because EIRs have a harder time creating strong BATNAs. Why? There is a fundamental information asymmetry between an EIR's host firm and other venture firms. Whether or not the EIR's host firm actually does know more about the EIR and her/his company, they appear to have access to much deeper information about the EIR's deal than other venture firms do. So, as such, if an EIR's firm does not participate in an EIR's deal, then you can imagine the partners at other firms wondering: "What does this EIR's host firm know that we don't know?" , "There's got to be something wrong with this deal..." or "Maybe there's something wrong with the EIR her/himself!" This information asymmetry gives an EIR's host firm a strong upper-hand in financing negotiations. That dynamic can prevent other investors from participating in what otherwise would have been a "fundable" deal or cause them to come in with reduced commitment at lower pre-money valuations. Every EIR I've spoken with has said that their firm brought them in with a promise of "no strings attached, you can work with whomever you want" -- but when it was fundraising time, everyone felt palpable pressure to do the deal with their host firm. Usurious firms can take advantage of an EIR's lack of negotiating leverage to drive down pre-money valuation and thereby inflate their post-money stake in the firm. Even well-meaning firms that have great relationships with their EIRs may cause an EIR's company to accept sub-optimal valuations if the EIR fails to create a market for their shares as aggressively as a typical (non-EIR) entrepreneur would have done.

This is the biggest pitfall for an EIR and potentially a dire/fatal situation for a hatchling startup... If a startup's cap table becomes too tilted towards investors in Series A, then the founder(s) may give up control of their company too quickly, or become too diluted to make the startup worthwhile to pursue. Obviously, everyone loses when a startup gets pushed to the point that the founders are demotivated. But that's a very fuzzy boundary and EIRs seem more prone than non-EIRs to end up pushing that boundary in a bad way.

So, is being an EIR the right thing to do? Depends on your goals and how you manage the risks mentioned above. I'll wrap up this series on EIRs in my next post with a list of venture hacks for EIRs to mitigate these risks.

What does an EIR do?

2009-08-08T00:47:00.000-07:00

I'm back after a looooong blogging hiatus. Yay, glad to be getting back into the swing of things.

So, @vijayv recently asked me:

Would you be able to tell me more about being an eir? Mainly Interested in role specifics/responsibility

I've had the honor of being an entrepreneur-in-residence (EIR) with two VC firms, Venrock and Matrix Partners. And through those programs, I've been lucky to have met and learned from many other entrepreneurs who have had way more success and experience than me. And if there's anything I've learned about the EIR role, it's that there's no such thing as a "standard" EIR program. It's kind of a "make it up as you go along" role (and that actually suits entrepreneurs very well). Quite frankly, there aren't that many EIRs running around Silicon Valley all the time because most venture firms do not support EIR positions at all. Those that do will customize the role on a case-by-case basis.

At the highest level, I think we could say that EIR programs involve:

working with partners at a venture firm whom you've previously worked with or gotten to know very well

researching existing startups to find promising ones that you'd like to personally join or introduce to the firm

ideating and creating new businesses

helping the firm vett business pitches

Within those general activities, roles do vary a lot depending on each individual's prior experience and their goals. E.g., some EIR's are seasoned executives who are specifically looking for teams that they can pair up with to launch a startup. Other EIR's are product innovators who are trying to launch new companies while incubated at the VC firm. Still others are entrepreneurs who are considering switching to become investors and are using an EIR program as a way of getting to know a firm.

And the specific arrangements that an EIR has with their host firm will vary a lot, too. Some EIRs are actual employees of the firm, some are contractors/consultants, others have no contractual relationship with the firm at all other than coming by to use a spare desk every once in a while. Most, but not all, EIRs are compensated by their firms; and compensation levels seem to vary significantly from corporate-executive-equivalent to ramen-subsistence-stipend.

There are significant benefits and risks associated with being an EIR and I'll talk about those more in my next post.

Two schools of thought on how to gain early traction for consumer-focused startups

2008-11-03T14:59:00.000-08:00

I'm a co-founder of a startup and I've noticed that our advisors are beginning to form "teams" around two opposing schools of thought for gaining early user adoption. These two philosophies are mostly mutually exclusive so I think entrepreneurs need to make a choice about which camp they fall into... Which are you?

I won't call out individual advisors/directors to preserve any "secret-sauce" that these folks may be building around their own businesses, but suffice it to say that some folks much smarter than me are championing these philosophies.

Philosophy #1: I'll call this the "Loop Experimentalist" or "New School" approach. This approach focuses on building and experimenting with a number of viral loops (email, web, scrapers, mobile, etc.) in a completely quantitatively-driven manner. First step is to build a viral loop (e.g., register for your site, add friends from Gmail importer, site sends invitation emails to selected friends, friends receive email and clickthru to register at your site). 2nd step is to try throwing users into the loop(s) with minimal generically-good-sounding instructions ("Add friends to your GoodPalsNetwork!"). No product necessary, a broken flow at the end of the loop is OK ("Thanks! More features coming soon!"). Find a loop that has K > 1.0 and then see what kind of users are going through it. Build a product around those users.

Philosophy #2: Let's call this the "Use-case Driven" or "Classic" approach. This approach centers on gathering qualitative data through consumer focus groups, interviews, ethnographies, and BD/pre-sales discussions. Use qualitative data to understand customer pain points and find a vertical use-case or problem that you can define your product around. Build a product that delights some users. Goto market with the same consumers/partners that you talked with initially. Get linear adoption within that target set first, then figure out how to grow exponentially from there.

Do these models jive with your observations of the startup-o-sphere? Lemme know!

Payments: Critical for Social Network App Platforms?

2008-03-19T23:33:00.000-07:00

I recently had the pleasure of connecting with TS Ramakrishnan. Super smart guy and clearly one who know a thing or two about how to launch app platforms/APIs for social networks.

TS has an interesting short-list of four requirements for a successful social network app platform:

Users -- the social network must be large enough to bring lots of distribution to app publishers

Language -- platform must be backwards compatible with existing web development languages/frameworks

Marketing -- the social network must expend significant effort to recruit, retain, and support app developers

Transactions -- the social network must facilitate secure transactions (i.e., payments)

I found his last requirement to be really thought-provoking... It sounds like a pre-requisite for ecommerce transactions, but we haven't seen a whole lot of apps pursue ecommerce models yet on social networks. The vast majority of social apps are 100% ad-supported, but we're starting to see some "freemium" models develop. For instance, Slide's SuperPoke app has Premium poke actions that users can get access to via a monthly subscription.

Even in an advertising-dominated economy, I wonder if the social apps on Facebook might monetize more efficiently if Facebook were to facilitate the payments/collections process between ad networks and app publishers? E.g., would social ad networks operate more efficiently if ad units were rendered in FBML and Facebook provided standardized tools for measuring impressions, clicks, follow-on actions, pathing; and financial transaction support for buying/selling social ads...

The Four Viral App Objectives (a.k.a., "Social network application virality 101")

2008-01-15T13:57:00.000-08:00

A lot of folks have asked for more details on the way we measured and optimized viral app growth in the Stanford class I co-taught recently. So here's a bit more info on methodology for measuring virality and what it means for an app to "go viral."

K-factor and R-zero

Terms like "K-factor" (contagion) and "R-zero" (reproduction rate) are often used to describe the growth rate of viral apps. These terms come from the fields of medicine and biology -- they're originally intended to describe the spread of of viral diseases, but they're nice analogies for how web/SN apps grow. Some would even describe widgets and apps as "diseases" that have "corrupted" popular social networks like MySpace and Facebook! ;-) Of course, having worked at Slide and authored some FB apps of my own, that's clearly not my belief... So, read on if you're interested in viral apps!

[digg=http://digg.com/programming/The_Four_Viral_App_Objectives]

Whether we're talking about apps or diseases, the key factors in determining virality are the same:

Distribution: how many people, on average, will an "infected" host make contact with while the host is still "infectious"?

Infection: how likely is a person, on average, to also become "infected" after contact with a viral host?

If you multiply these factors together, that's your viral growth rate (or "K" or "R-zero" or "viral coefficient"). The product of these factors answers an important question:

"How many people will be infected by a single viral host while the host remains infected?"

With real-world viruses, the infectious period has very dramatic outcomes. E.g., a host remains infectious until either the virus kills the host or until the host's immune system fights off the virus. If K=1, then the host basically passes the virus on to one new person before either the host dies or the virus is expelled. Either way, if K=1, then the host exactly replaces him or herself in the population of infected people before becoming non-infectious.

Hopefully, the growth of social apps will never involve physical death or illness! [Disclaimer: No readers were harmed for the writing of this post.] Instead, we would consider a host to be "no longer infectious" if they either uninstall the app or stop actively using the app. Using that definition, an app with a K-factor of 1 will have a userbase in steady-state - no growth, no decline, just flatline; where every current user replaces themselves before leaving the userbase. K>1 means an app is growing its userbase virally (exponentially). And, conversely, K<1 means an app's userbase is exponentially decaying.

With these factors in mind, designers of viral applications have four levers to pull on in order to increase virality:

The Four Viral App Objectives

Increase the percentage of "active hosts" who actively make contact with uninfected people

Increase the contact rate for each active host (average number of contacts per time period)

Increase the duration of each active host's infectious time period

Increase the likelihood that contacts turn into infections (i.e., infection conversion)

Sidenote on app metrics

Note that this also implies that in order to affect any of these, you, as an app developer, need to be able measure each of these stats for your userbase. You can't tell if you're driving any of these numbers up (or down) until you know how many contacts/invitations each of your users sends out per day/week/month that they have the app installed; how many days/weeks/months each of your users tends to keep the app installed; and what the conversion rate from a contact/invite into a new infected user is.

Collection and analysis of metrics for social apps is a meaty topic in and of itself, so we'll leave that for another day. But for now, it should suffice to say that it's really important to have an effective way to collect statistics on what your users are doing with your app!

Assuming that we've got a reliable way of collecting metrics, here's a quick list of some techniques for achieving each of the four viral app objectives.

Some example methods for optimizing virality

Active Hosts

Require users to invite more people to join the app before they can view/use the app. Typically paired with premium or high value content. E.g., "Invite 10 friends in order to unlock this pr0n video in high-definition" or "Invite 15 friends to see how who has a crush on you." Some users complain about this tactic, but you may be surprised at how many users will effective. (just kidding about the pr0n, kiddies -- that stuff doesn't fly on most social networks. ;-)

Opportunism -- you can't always predict how people will utilize an application, so give your users multiple ways to share your app. Ideally, every app pageview should contain one or more ways for a user to share the app (and thereby become an active viral host).

Contact Rate

Create incentives for inviting more people. E.g., "invite 10 more friends to level up and become a Black Belt Ninja"

Specific requests tend to work better than vague encouragements. E.g., don't just ask users to "please invite friends", specifically ask for a number, "invite 10 friends" (don't laugh, it actually works!)

Simplify, simplify, simplify. If your #1 goal is to go viral, then that should be the #1 action-request that "pops" out to a user. Make it easy to invite more people. Utilize address book importers. Auto-select large(r) distribution lists for invitations. Basically, minimize the amount of hunting-and-clicking it takes to get a user through your invitation process. Ideally, it should just be 1 click.

Activity Duration

User-to-user messaging is a great way to keep users coming back to an app. If pokes, walls, comments or private messaging fit into the context of your app, you should seriously consider building those in.

User generated content and media -- in general, apps that have some form of UGC/media built into them (music, photos, videos, drawings, etc.) do a better job at drawing repeat visits. I'd also group collaborative filtering functionality in this bucket -- e.g., ratings, rankings, top playlists, "most viewed" lists, etc.

Infection Conversion

Social context -- when you're writing the content/copy for your app invitations, be sure to keep in mind the fact that all your app invitations are occurring in the context of a social relationship between two friends. Use that knowledge as you phrase every call-to-action and craft each sentence to reinforce the social relationship and play on influence mechanisms between these two friends.

Images and buttons -- beyond writing the actual content/copy, app authors should also experiment with design and layout of their invitations. Some top tips include: use buttons instead of plain text links; and use images of people to draw the eye.

Of course, the list above is not exhaustive, it's just a sampling of top-of-mind viral engineering techniques. If you have other favorite/top tips for tweaking virality, please post a comment below.

A note on prioritization:

In general, all other things equal, it's most effective to pull on the Contact Rate and Activity Duration levers first -- followed by the Host Activation and Infection Conversion.

By definition, your Host Activation and Infection Conversion rates are capped at 100% -- the best you can do is to get 100% of hosts to invite other people, or 100% of contacted users to become infected. In contrast, the Contact Rate and Activity Duration are theoretically unbounded. (Well, I guess all human users must eventually expire, but I haven't seen any Facebook apps that specifically optimize on age of users, yet!!) In any case, for our purposes, the total number of viral contacts initiated by your userbase is theoretically unbounded.

So as an app developer, you should explore the upper limits of how rapidly you can grow your viral contacts before circling back to optimize conversion rates. E.g., if you think of each of your current users as an "infected host", then your first priority should be to get a maximal number of invites/contacts sent out by each of your hosts while you have them on the app.

Benchmarks

Just for comparison, I've included some common ranges for Host Activity, Contact Rate, Activity Duration, and Infection Conversion below. These are derived from my own experience with Facebook apps, observations of my Stanford Facebook class'es apps in Fall 2007, and also observations from companies that I have worked at or advised.

Active Hosts

App age is an important consideration -- newly launched apps will tend to have more active hosts

Anything above 50% is pretty good for early-stage apps

Single-step funnels perform best for maximizing host activation (e.g., select and invite friends from a single page, ideally the FIRST page that a potential new host sees)

In general, minimize the number of steps/pages that you ask hosts to go through in order to invite their friends. Each additional page/step in a funnel will drop 50% to 60% of users, so each step in a funnel carries a very steep penalty. (Note this is a LOT steeper drop off than the rule of thumb 33% dropoff for page-to-page conversion rates that ecommerce or content sites see!)

Contact Rate

For Facebook apps, 15+ total invitations per user is very good (Note that Facebook imposes a daily limit of 20 invitations per app per user)

Activity Duration

Activity rates and user tenure will vary widely, depending on the purpose and design of app.

Healthy ranges are typically between 5% and 40% of an app's userbase will be active on any given day. (Starting high for young apps and then decaying over time for older apps)

Good retention practices should generate 8+ repeat visits per month per user

Infection Conversion

Expect net conversion rates from invites-to-infections in the range of 5% to 8%

K-Factor / R-zero / Viral Coefficient

Ranges between 1.4 - 2.1 (or higher) are typical for apps experiencing "hot" viral growth

Summary

OK, so good luck to all you app developers out there seeking app virality! As you can see, none of this stuff is "secret sauce" or anything -- you can readily view all of these techniques in action on Facebook, MySpace and other social network sites today. Still, I hope that summarizing this stuff in one place is useful and many apologies in advance if I've misrepresented anything, especially the biomedical stuff. (Is there a doctor in the house?!) Please leave comments or corrections below!

And, of course, if you've got some viral ideas or would like to collaborate on viral apps, drop me a line: yeelee at gmail (or connect to me on Facebook, LinkedIn, etc.)

[digg=http://digg.com/programming/The_Four_Viral_App_Objectives]

Six Risks that Venture Capitalists Take

2007-11-26T14:39:00.000-08:00

Mark Davis of DFJ Gotham Ventures posted this nice summary list of six types of risk that venture capitalists typically examine when evaluating a potential investment.

Management Risk

Product Risk

Revenue Model Risk

Market Risk

Competitive Risk

Partnership Risk

Read the full article here

VMGOSPA - nested organizational objectives

2007-11-15T22:25:00.000-08:00

I mentioned AlphaBlox in my last post and that made me think of something I learned from Michael Skok (CEO and Founder of AlphaBlox, now Partner at North Bridge Venture Partners).

Michael had a great framework for explaining how each person's daily activities fit into the larger company objectives. He called it "VMGOSPA", an acronym for the following framework:

Vision -- The company's long term vision. E.g., "Acme Widgets is the world's leading provider of basket weaving technology"

Mission -- Short-term (1-2 year) mission statement that builds toward the company Vision. E.g., "Acme Widgets' mission is to dominate equipment sales in the fastest growing segment of basket weaving technology: underwater basket weaving"

Goals -- Immediate goal statements that build towards the Mission. E.g., "Successful completion of human trials for Acme's innovative noninvasive underwater basket weaving equipment"

Objectives -- Current objective statements for executives, business units, functional departments, or teams that collectively achieve the company's Goals. E.g., "The R&D department's Q1 2008 objective is to produce 20 units of UBW equipment for trials."

Strategies for achieving Objectives

Plans for implementation of Strategies

Actions on a day-to-day basis that execute the Plans

Now, the seven layers of VMGOSPA clearly will not apply to all companies. Small companies and startups, especially, may not have enough team members to subdivide and delegate actions to! ;-)

The key concept here, though, is absolutely critical to scaling up an organization: every individual's daily activities should aggregate up to achieve the company's mission and thereby propel the company towards its vision. The way to do that is to visualize and define each person's and team's objectives in a recursively nested structure.

Avinash Kaushik's Five Levels of "Web Analytics 2.0"

2007-11-15T21:55:00.000-08:00

I had the pleasure of hearing Avinash Kaushik, Google's analytics evangelist, speak when he came to our CS377W class at Stanford this quarter (the "Stanford Facebook class"). He's an amazing speaker, really breathing life and purpose into the too-often dry topic of web analytics.

He's promoting a new way of looking at web analytics, what he calls "Web Analytics 2.0". Avinash'es central message is that analytics cannot stand alone as a decision driver in organizations; rather analytics need to be considered in the context of additional data (from customers, competitors, and other internal sources) in order to drive rational decisions.

Avinash has a brilliant decision framework, consisting of the five decision inputs that should be considered in order to gain insight into customer behavior and drive optimal decisions. He calls this "The Five Pillars" and here's the cliff's notes summary:

Clickstream -- Typical web analytics can give you data on unique viewers, pageviews, session times, browser types, and geolocation.

Multiple Outcomes Analysis -- The payload for most web analytics tools is goals/funnels and conversion rate analysis. Having clearly defined website goals is necessary and a great starting point, but not sufficient for true user insight. Analysts should recognize that users and companies may have many different reasons for visiting or hosting a website. All those objective outcomes need to be measured to see if the site is really driving the desired outcomes.

Experimentation & Testing -- In it's simplest form, this means A/B testing the design of your website, including text, graphics, buttons, banner ads, everything. Some free tools like Google Website Optimizer actually automate the process of running multivariate tests to help you quickly find the optimal.

Voice of the Customer -- Even after taking your best stab at Multiple Outcomes Analysis (#2, above) ask website visitors through surveys: (1) why are you here?; (2) were you able to achieve what you came for?; (3) if not, why not? The results can be tied back to analytics data and may reveal customers' true motivations.

Competitive Analysis -- Your site does not exist in a vacuum. Your competitors may be running campaigns or launching products/features that are impacting your site's performance (could be either up or down).

An important theme that runs throughout Avinash'es comments but doesn't explicitly show up in his framework is:

Analysts should not be the only people in an organization who see all this information. The process of gaining customer insight is becoming more and more automated and this information can and should be put into the hands of more people throughout each organization.

This is really, really powerful stuff -- everything I've seen in my experience at AlphaBlox, PayPal, and Slide confirms that (1) companies are hungry for this kind of analytically-driven insight; and (2) teams that really LIVE this analytical process are winners -- when people talk about "cracking the code" on how to continuously improve a web-based business, this is analytical process is really what they're referring to. The early PayPal team established a metrics-driven culture that did a good job at upholding the Five Pillars (though we didn't call them that at the time). And the Slide team is doing an awesome job at this, using a slightly different but equivalent analytics framework. The information is out there... Avinash does a great job packaging it up, now companies need to really internalize his message.

If any of this strikes a chord with you at all, you should do yourself a big favor and read Avinash'es entire post (and watch the video!) on this topic:

http://www.kaushik.net/avinash/2007/09/rethink-web-analytics-introducing-web-analytics-20.html

He's even got a primer at the bottom of his blog post on how to get started with this analytics methodology.