Monday, October 24, 2011

Registration Form Design with Facebook, Twitter, LinkedIn Authentication

I continually face the challenge of designing and building registration / sign-up pages on a wide variety of different web sites and mobile applications.  Back in January 2010, I wrote a post that's one of the most popular on this blog:

When to Use Facebook Connect – Twitter Oauth – Google Friend Connect for Authentication?

That post looked at when and why you would use Facebook, Twitter, LinkedIn, etc. as part of your registration and authentication mechanism.  While some technical aspects in the post quickly changed (e.g., Facebook changed its data caching policy), many of the issues remain the same.  It's definitely worth a read if you've not seen it before as background for this post.

Design Challenge

In this particular web site, we needed to get the user's email (and password).  We also wanted users to provide information about twitter and LinkedIn to help personalize the application.  At first it seems like this should be pretty easy to design - think again.

Here's a classic example that illustrates the issue - the sign-up page from Mahalo.


Mahalo offers you the choice of sign-up / registration via a host of social networks (powered by JanRain).  They tell you the other option is to provide your email and password.

At the heart of this is two main advantages of having social network sign-up / registration. 

  1. Allowing the user to click on the Sign-Up / Register via a social network such as Facebook, Twitter, etc. means faster, easier sign-up and increases the likelihood of sign-up.
  2. By having the user sign-in to twitter or Facebook, we can ask for permissions to tweet or post to their wall or other social actions on their behalf.  We also can get access to their social graph.

For some solutions, it's sufficient to just have authentication via the third party, but in my experience it's pretty rare to have that be the only mechanism used during a sign-up process for a startup. 

In my prior post, I point out two major downsides of relying only on registration via a third-party social network:

  1. Multiple Social Networks.  If there are multiple social networks offered, returning users may not be recognized if they click on a different social network.  In other words, the first time I sign-up with Facebook.  At a much later time or on a different computer (no cookies), I come back and try to sign-in with Twitter.  The system won't recognize me.
  2. Email Address.  The other problem is that only Facebook currently allows us to grab an email address.  If you want an email, you will need to either limit your sign-up to be Facebook only, or you will need to ask for an email address after their initial sign-up.  In other words, you are likely still going to go through the registration that's on the right side of the Mahalo sign-up page.

This is exactly what Mahalo ends up doing.  I signed into my twitter account and gave them permission.  But now Mahalo must come back and ask me to either establish my account (New User) or sign-in as an existing user.


As a user, this feels a little strange.  I first click on the register or sign-up button.  I am presented with a choice of using a social network to sign-up OR providing my email and password.  I choose a social network, but then I'm forced to put in an email and password anyhow.  Huh?

I've tried a few times to design around this and do something else, but it doesn't really work out in practice.  And you will certainly see this design pattern all over the place.  Here's XYDO's sign-up box:


It's behavior is a little different, but also a bit funny.  At first it seems like I can sign-up with Twitter or Facebook.  However, if you sign-up with twitter, it puts a check mark next to it and leaves you on this page still requiring you to enter your name and email address.  Even with Facebook, where you can get a name and email, it still needs to ask you for your user name and password.

StoreEnvy has a sign-up with Facebook option on it's first page.  It grabs your email.  But it still is left asking you for more.



Bottom Line

In our case, we were designing an application where we needed to get the email and password, but we also wanted to get users to authenticate with LinkedIn and Twitter in order to get information about them and their social networks.

At first we tried down the same path as Mahalo.  We provided a sign-up page that had an alternative of signing up with a social network (twitter or LinkedIn) OR signing up by providing an email and password.  However, we ran into the same problem as Mahalo where our second page was then asking for more social network information and the email and password.  The confusion factor was just too high.  So, we went back to a more basic design.

Up front, we have a well designed sign-up / registration form.  You can see a bunch of great information on designing these forms in the following posts:

The second step of the sign-up process asks the user to authenticate to their Twitter and LinkedIn accounts.  This is more along the lines of a multistep sign up using a progress tracker.


In our case, the steps are:

  • Step 1 - Get email and password
  • Step 2 - Get social network information / authentication
  • Step 3 - Confirm additional information

I personally think this is a more "honest" approach and makes it much more clear to users what is going on.

Thursday, October 6, 2011

Customer Validation - 33 Great Articles

I saw a great post from Tristan Kromer Pivoting on Investor Feedback a.k.a Beware of Mentors.  It was a top post on StartupRoar on Tuesday.  His basic point was:

If someone, including me, tells you something isn’t a great idea and there’s no market for it there are only two acceptable responses. Either:

"That’s interesting. I’m going to take that thought out into the field and validate it with my customers."


"You’re wrong. I’ve spoken to dozens of customers, I have a validated customer persona, built an MVP to test key behavioral hypotheses, and the data doesn’t back what you’re saying."

imageToday I had two conversations with early stage startups (see Free CTO Consulting).  In both cases, I was the mentor telling the person that the idea, as I understood it was "not great."  One was an enterprise software product.  The other was a consumer play with possible viral growth.  Neither felt like a slam dunk.  Would it take more work to sell the enterprise product than they could make on it?  Would the consumer one get traction and be viral?  In both cases, my gut said that as framed it needed work.

In both cases, the founder and I brainstormed on ways to shift the product in order to get closer to what I perceived as something that would be great.

Neither had done enough customer validation to be able to say the second line that Tristan suggested.  There certainly had not been enough validation of the concept as it stood.  I would guess that most people who are providing feedback on your idea have a pretty good filter for what you have done to validate the concept.  If you've not Done Your Homework, it will be obvious.

In both cases, the answer was that the founder would go to find other ideas, turn those into paper descriptions and validate it with customers.  Customer Validation 101.  And that's the first response that Tristan suggests.

Now some helpful articles on Customer Validation, Customer Development, Lean:

  1. Six Idea Validation Tests to Pass Before Startup
  2. Customer Validation Really Starts with In-Person Interviews
  3. A Day in the Life of Your Customer
  4. How to Know If Your Startup Idea is the Next Big Thing
  5. Some Startups Forget to Validate a Business Model
  6. The Challenging Pace of Lean Startup
  7. How To Prioritize Feature Development After Launching an MVP
  8. The MVP is a Process not a Product
  9. Digging Deeper into Lean Business Model Canvases
  10. Wasting Time Validating Assumptions?
  11. Startups Need to Make Leaps of Faith, But Not Blindly
  12. Lessons Learned: Validated learning about customers
  13. Entrepreneurship as a Science – The Business Model/Customer Development Stack
  14. You Can’t “Feature” Your Way to Success
  15. The Phantom Sales Forecast – Failing at Customer Validation
  16. Customer Development and Marketplaces
  17. No Business Plan Survives First Contact With A Customer – The 5.2 billion dollar mistake.
  18. Vision Synching in a Lean Startup
  19. The Fallacy of Customer Development
  20. Entrepreneurs, Lower Investors’ Risk by Validating your Start-up Company’s Business Proposition
  21. Lessons Learned: What is customer development?
  22. How I Test The Market Validity Of A Product
  23. Customer Development Gut Checks
  24. Build a Path to Customers from Day 1
  25. Top 3 Ways to Fail at Customer Development
  26. Creating Startup Success – Customer Development + Business Model Design
  27. Customer Development and Marketplaces
  28. Hubris, Passion and Customer Development
  29. Free Customer Development Help –
  30. The Fallacy of Customer Development
  31. Hubris Versus Humility: The $15 billion Difference
  32. Less is More, More or Less
  33. Yes, but who said they’d actually BUY the damn thing?

Tuesday, September 27, 2011

Equity for Early Employees in Early Stage Startups

I was asked by a reader how much equity he should give out to early employees and to service providers in a very early stage startup.  I'll get to service providers in a later post.

Founders vs. Early Employees

To help with this discussion, let me start with a definition of "early employee."  Steve Blank divides the individuals associated with startups as:
  • Founders
  • Early Employees (Employees # 1-25)
  • Later Employees (Employees # 26-125)
The reality is that the definition of founder and employee is not clear.  The first few people into a startup are on a spectrum of founder vs. early employee.  Founders are likely not paid for a long time and have a sizeable equity percentage for early risk and having the concept.  An employee is later, has a greater portion of compensation as cash, has lower risk, and generally does not bring as much to bear in terms of the concept. 

Early Employee Equity is an Art

I somewhat agree with Fred Wilson in Employee Equity: How Much?
For your first key hires, three, five, maybe as much as ten, you will probably not be able to use any kind of formula.  Getting someone to join your dream before it is much of anything is an art not a science.

Equity Formulas

While it's somewhat an art, there has been a lot written about how you can look at equity compensation.
Paul Graham provides what is roughly the core formula for equity at any point in The Equity Equation:
You can use the same formula when giving stock to employees, but it works in the other direction. If i is the average outcome for the company with the addition of some new person, then they're worth n such that i = 1/(1 - n). Which means n = (i - 1)/i.
For example, suppose you're just two founders and you want to hire an additional hacker who's so good you feel he'll increase the average outcome of the whole company by 20%. n = (1.2 - 1)/1.2 = .167. So you'll break even if you trade 16.7% of the company for him.
Let's run through an example. Suppose the company wants to make a "profit" of 50% on the new hire mentioned above. So subtract a third from 16.7% and we have 11.1% as his "retail" price. Suppose further that he's going to cost $60k a year in salary and overhead, x 1.5 = $90k total. If the company's valuation is $2 million, $90k is 4.5%. 11.1% - 4.5% = an offer of 6.6%.
Of course, to be able to use this kind of formula, you will need to be able to determine how much impact the person will have and figure out a valuation.  I've talked about this topic before in How Investors Think About Valuation of Pre-Revenue Startups, and CTO Salary and Equity Trends 2009-2011.  You can also take a look at StartupRoar's topics: Startup Valuation, Pre-Money Valuation, and Early Stage Valuation.

Same Value for Sweat Equity as Investment Dollars?

Jason Cohen in How to think about cash vs. equity compensation (definitely read the comments) provides similar kinds of formulas.  The key in his approach is that equity compensation should be viewed the same way that you view investment.  In other words, the loss of compensation for the early employee as compared to market rate should be viewed as equivalent to the equity for that same dollar amount from an investor.

Logically, that's correct, but I personally would put a risk premium on equity compensation.  I also believe that early employees should be bringing higher value than early investor dollars as they can and should contribute to the concept greater than an investor.  They are partially rewarded by the increase in value of their equity.  But their contributions raise the value for everyone.  I believe that Paul Graham's core formula takes that into account.

Ben Yoskovitz gets to a similar point In Changing Equity Structures for Early Startup Employees:
The more that those first employees feel like founders in terms of their ownership, emotional attachment, responsibility and overall understanding of the startup process (including financing, running day-to-day activities, etc.) the better the startup will be.
David Beisel puts it another way:
Being an early hire at a startup gives an individual the ability to make tremendous impact on an organization as it grows – and both the founders and those hires should know it.
Of course, all of that assumes that the early employee does make an impact.

Risk Premium on Equity Compensation?

While Jason Cohen suggests that investment cash and sweat equity should be viewed the same, quite a few people suggest that there should be a risk premium for early employees at early-stage startups.  A risk premium is a multiplier that says that any equity compensation should be viewed as being worth less than cash for that employee because of the risk. 

The risk premiums that I've seen vary widely with seemingly camps of:
  • None - like Jason
  • 20-50%
  • 3x - 4x
In a way, suggesting there should be a risk premium is just arguing over valuation and expected return.  There's also the aspect that the equity that you typically get as part of equity compensation is behind other equity in preference and thus effectively has lower value.

But the more important rationale is raised in the following about why employees most often do not have significant outcomes even in fairly positive liquidity events.

Memo to CEOs And Founders: Share The Love
Consider the proceeds of a $50-million acquisition for a 100-person company that has raised $14 million with a typical liquidation preference:
  • Because of the liquidation preference, the investors get $14 million right off the top. The remaining $36 million is divided according to equity ownership.
  • Investors own 50%, and get $18 million, split between two firms
  • The two founders own 33%, and split $12 million
  • The 3-person executive team, including a CEO if one was hired, owns 10%, and splits $3.6 million. The team gets another $3 million as a severance payment or an earn-out, to sweeten the acquisition offer.
  • The remaining 95 employees split 7%, each earning $27,000. Unlike the founders, the employees have to wait until their grants vest, working at a company no longer of their choosing for two years.
Is it Time for You to Earn or to Learn?
You get 1%, you sell for $150 million and it’s in 3 years (e.g. you won the lottery).  That’s an after-tax gain of $287,500 / year for 2 years.  Not bad.  Doh!  Wait a second.  Stock vests for 4 years.  You didn’t get acceleration on a change of control?  Sorry bud.  We’ll have to either cut your earnings in half to $143,750 or you’ll have to complete 2-years at BigCo that bought you making the money spread out over 4 years so it’s $143,750 / year for 4 years.
The reality is that an early employee in a pre-funded startup that eventually raises a few rounds of capital will be diluted significantly, is down the line in preference,  and will likely be locked up for a while to harvest it.  And that's assuming that it's a fairly positive outcome.  If it's anything less that positive, preferences will mean they get nothing other than what's required to keep them working if that's needed at the acquiring company.

Sample Equity Numbers

I personally always like to see some actual numbers rather than basing things on formulas.  Because of the Art aspect of early employee equity, I had trouble finding much in the way of numbers for that specific aspect.  I did find a few things for later points. 
 Wilson Sonsini and DFJ Gotham Ventures:
The Option Pool Shuffle:
Title Range (%)
CEO 5 – 10
COO 2 – 5
VP 1 – 2
Independent Board Member 1
Director 0.4 – 1.25
Lead Engineer 0.5 – 1
5+ years experience Engineer 0.33 – 0.66
Manager or Junior Engineer 0.2 – 0.33
It's important to note that this is all post Series A.  If the company is pre-funding or only has a small friends and family seed round, then the numbers should go up from there based on expected dilution  and greater risk.

You can also look at some data around this in Startup CTO Salary and Equity Data at some specific numbers at different stages

Where I Come Out

Again, like Fred Wilson says, early employee equity is more art than science.  I would look at the individual involved and factor in:
  • Domain expertise
  • Connections
  • Experience with related ventures
  • Ability to make significant contributions
  • Replaceable - are there lots of other people out there who can do the same thing.
  • Part-time vs. Full-time - doing something on the side is less valuable
In other words, if I find someone who's willing to dive-in, who's going to significantly contribute to make the company a success and it would be hard to get anyone else, then I would provide significant equity, most likely an equity premium.  If this is a junior level developer, then likely you can provide significantly less equity.  The example numbers above bear this out.

Oh, and one last thing, make sure you figure this out upfront, you have it vest, you have ways to get it back, etc.  There's a lot of advice out there on structuring equity compensation agreements.  Go read up on that and do it right.

More Resources

There's a lot out there on this topic that's well worth reading.
Equity Compensation at a Startup is a Big Gamble
The bottom line is that you shouldn’t even think about joining a startup, stock or no stock, unless you believe in it and are ready for the adventure of your life.
Splitting Startup Equity for Your Piece of the Pie
Equity-Only CTO and Equity-Only Developers
CTO Equity and Compensation at Venture Backed Companies
Visualization of Startup CTO Equity and Salary Data
CTO Equity - Negotiation After Funding
What is the best way to divide up ownership in a startup?
How To Calculate Sweat Equity
Startup Equity For Employees
A VC: Employee Equity: How Much?
How to figure out what those VC terms mean for your equity
Make Sure Sweat Equity Vests
How To Allocate Founder and Employee Equity
Is Dilution Considered When Talking About Equity Ranges?
How much equity for investors and employees?

Tuesday, September 20, 2011

NDA Stealth Mode and Sharing Your Startup Concept

One of the readers asked my opinion around sharing your startup concept:

My first question has always been - how do you protect your idea while shopping around for feedback, partners, developers, etc.? Especially if the idea could be whipped-up by a few 24-year olds in a few weeks?

imageLots of thoughts here.  First, if your idea really is something that a couple programmers can whip up in a few weeks, then you may not have much of a business here.  But let's leave that aside for a minute.

My basic claim is that you MUST HAVE LOTS OF EARLY CONVERSATIONS.  As Chris Dixon says in Why you shouldn’t keep your startup idea secret.  He tells us you'll get the following benefits from talking to lots of people:

There are lots of benefits to talking to people.  You’ll get suggestions for improvements.  You’ll discover flaws and hopefully correct them.   You’ll learn a lot more about the sector/industry.  You’ll learn about competitive products that exist or are being built.  You’ll gauge people’s excitement level for the product and for various features.  You’ll refine your sales and investor pitch.  You might even discover your idea is a bad idea and save yourself years of hitting your head against the wall.

Niel Robertson in The Stealth Mode: Trada’s Position on Staying Stealth captures the basic communication needs of early stage startups pretty well:

In the beginning there are three basic things every startup needs: experts to give you input on your product as you’re building it, users to help you beta test your product in a real-life setting, customers who will give you real money for what you’re building and take real risk in doing so. You need all of these people to bake the cake.

He left out capital sources, but it's still a pretty succinct list of the types of people / communication you should be having early stage. 

What is Stealth?

imageWhat's also interesting in Niel's piece is that he defines Stealth Mode not as not having conversations, but rather he says it's not make public pronouncements.  Seth Levine in To stealth or not to stealth says this pretty well:

There are varying degrees of stealth, ranging from companies that won’t tell anyone what they are up to, to companies (like the one I’m referring to)that don’t have a web site and haven’t made any announcement of their business intentions or funding but aren’t hiding what they are doing in daily industry conversations, etc.

The reality is that Stealth is defined differently in each case.  What we are talking about is a spectrum of how you restrict early communications around your business:

  • Who you will talk to including the public / press / etc.
  • What you will convey in your conversations
  • What protections you will place on those communications

For example, you might decide that portions of your concept will be controlled more closely (a secret algorithm). This will only be disclosed when there is an NDA in place.  But you will be able to convey other aspects freely, even publicly. 

How Stealthy Should You Be?

This is going to be fairly specific to the company.  I would suggest that it's best to be as open as possible.  My general take is similar to Chris Dixon.  In that same post Why you shouldn’t keep your startup idea secret where he argues to make things open, he defines only one group of people that you may want to avoid having a conversation with:

The handful of people in the world who might copy your idea are entrepreneurs just starting up with a very similar idea.  You can probably just explicitly avoid these people, although by talking to lots of people your ideas will likely seep through to them.

I might also be concerned about taking my idea directly to a large, well funded competitor who is know for innovation.  And I probably will not announce detailed specifics publicly prior to creating them.  Beyond that, I want lots of conversations with experts, users, customers, VCs, partners, etc.  I may decide to hold back some detailed specifics around algorithms.  But generally I'm going to favor being open.

Since I fall into the expert category, my belief is that you should be pretty open with me.  Startups that come to me and ask me to sign an NDA in order to get Free Startup CTO Consulting really are missing it.  And getting into a discussion but not being able to tell me about your business also hurts you.  "We are doing something in mobile advertising."  Ummm ... "Good luck with that."  What can I say.

I like how Mark Suster handles the question in 10 Marketing Lessons for Early-Stage Tech Startups.  Definitely take a look at he suggests you balance the choices.

I also will point out that in the The 15 Mistakes of First Time Entrepreneurs:

9. I don’t want to share my idea because someone might steal it – the benefit of sharing is greater than detriment- investors won’t sign an NDA.

And there's more via StartupRoar in Stealth Startups including:

  1. 7 Reasons For Your Startup to Skip Stealth Mode
  2. Stealth mode is back. Long live stealth mode!
  3. Startups in stealth mode need one piece of advice
  4. Startups in stealth mode need one piece of advice - Discussion
  5. New Thoughts on Stealth Mode
  6. Stealth Mode
  7. Why go stealth?
  8. Stealth Mode Startup
  9. Startup Myths #1 – You Need an NDA
  10. Ultimate Advice to Stealth-Mode Startups: Just Stop
  11. Stealth Mode, Schmealth Mode: The Real Reasons Why Startups Don't Talk
  12. Why It’s Not Healthy To Be A Stealthy Startup
  13. Is "Stealth" the Best Way to Build Your Business?
  14. Someone Stole My Startup Idea – Part 1: Are Those My Initials?
  15. Someone Stole My Startup Idea – Part 2: They Raised Money With My Slides?!
  16. Someone Stole My Startup Idea – Part 3: The Best Defense is a Good IP Strategy
  17. First Rule of Fight Club Does NOT Apply
  18. Worry About People Listening To You, Not About Them Stealing Your Ideas
  19. If you love your idea, set it free….

NDAs or Other Protection

imageSo you decide you want to be able to share with experts, users, customers, VCs, partners, etc. in order to get the benefits that come from those conversations.  You decide what you will convey in those conversations (and what you will not).

Again, relying on StartupRoar this time looking at NDA for Startups, I found some good stuff that you should definitely go through in more detail.

Startup Reality Distortion #3: The Fallacy Of the Non-Disclosure Agreement (NDA)

Don’t rely on an NDA to protect the truly “secret” stuff.  It’s likely not going to give you the protection you think it is.

More more via StartupRoar in NDAs for Startups including:

  1. Don’t Ask Known Investors to Sign Non-Disclosures
  2. Three Simple NDA Rules for Entrepreneurs
  3. On NDAs (revisited)
  4. One More Time: No NDAs

Don't Lead with Protection

I want to close this with one bottom line thought.  Please don't make protection of your idea a major topic early in conversations.  This is much like condoms.  You don't bring the topic up early in conversation.  Condoms like protecting your idea can come up naturally later in the conversation.  Instead go in knowing what you will share and won't share with this person.  Try to be as open as you can, but be prepared when questions reach the border.  Simply say that you have some secret sauce in that part of it and aren't prepared to share it.  And make sure that does preclude you from sharing enough to make it an effective conversation.

You really should go read Brad Feld's Implied Suspicion Versus Implied Trust.  It captures the typical scenario and some of the logic and emotion that goes along with early conversations. 

Entrepreneur: Following is an email describing my idea.  Since you won’t sign an NDA, you agree that by reading beyond this paragraph you are agreeing not to share my idea with anyone, forward this email to anyone, or discuss the idea without my consent.


Feld: You seem to be operating from a perspective of “implied suspicion.”  I don’t work this way – I much prefer to operate from a perspective of “implied trust.”  Since you clearly don’t trust that I’ll behave responsibly, then I don’t think I’m a good match for working with you.

Definitely read the whole thing.

More Reading

Finally, if you are reading this, then you probably should be reading more about Startup IP (Intellectual Property) and definitely follow Jill Hubbard Bowman's IP Law for Startups.  Some resources on this:

  1. Intellectual Property is More Than Patents
  2. Does My Startup Have Intellectual Property?
  3. The Top Five Reasons Entrepreneurs Should Learn About IP Law
  4. What Can a Well Drafted Contract Do For Your Company?
  5. Track the Ten Elements of Value for Your Venture
  6. Intellectual Property Concerns for Software Startups
  7. Entrepreneurs, Use Patents to Protect Your Intellectual Property and Create Value for Your Start-up Company
  8. Startups Beware: Patents are Like Umbrellas. False Confidence.
  9. Barriers: The Best Defense Is A Good Offense
  10. How Ideas Grow: Seth Godin Inspires an iPad App
  11. IP 101 for Startups
  12. Venture Deals: Chapter 13: Legal Things Every Entrepreneur Should Know

Monday, September 19, 2011

Startup CTO Resources

I've posted quite a few things on the topics associated with being a Startup CTO. I've tried to collect them together here as a starting point for this topic.  And here are my CTO Speaking Topics.

You can find more here: Startup CTO. And you may also want to review Startup Development.
If you are interested in this topic, I post on it frequently. You can sign up for free email updates using the subscribe box on the right side.

Wednesday, September 14, 2011

How to Hunt Programmers for Your Startup - A Field Guide

imageThis post is admittedly the outcome of a conversation with a few people over some beers.   Some of it is a bit tongue-in-cheek and certainly we are greatly simplifying things.  The people around the table included a bunch of us who would be prey in some situations.  So, please take this in the spirit intended.

The conversation centered around a founder who's key question is "Where Do I Find a Developer for My Startup?"  In this case, he had a pretty compelling idea, had very little money, and didn't have the capacity himself to build it.  His goal was to find a programmer who would come in as an early partner and work as an Equity-Only Developer.   The situation is pretty common it got us to riff a bit around how to get programmers to help him build out a proof-of-concept version for his startup.  Along the way, this gradually turned into hunting programmers in the wild.

Before You Hunt - Be Prepared

But before I answer the core question, let me address a few up-front questions.  Don't go hunting for programmers until you've answered these.

1. Have you done all you can on paper?

Do you have wireframes?  Have you tested the concept with customers using paper?  Have you signed some test customers?  Have you tested what you can without development?  Don't try to hunting programmers until you've pushed this as far as you can on paper and get early customers.

2. Do you know the relative effort to build your prototype or minimum viable product?

The relative size of the development effort will make a big difference in your strategy.  There's a cutoff point once you reach roughly 3 person months of development time.  At that point, you can't really just try to find someone to build it on the side, do equity only, etc.  It needs to be funded to be successful.  The grind is too much and too long if it gets beyond that size.

What do you do if you don't know the size?  Ask a few CTO type people.  Or ask me Free Startup CTO Consulting Sessions.

3. What are the key developer skills that are needed?

Is this a Wordpress hack?  Is it big data?  Deep algorithms?  Have a rough idea of what you are looking for in terms of talent.  Again, if you don't know you should ask people who will know.

4. Is this compelling to a developer?

Be prepared to sell this to the developer.  More on this below.

In the case of the entrepreneur that was the genesis of this post, he had done a lot on paper.  He had a few early customers ready to go.  The size of his initial build was roughly 3 person months and it wasn't particular complex.  It was a mobile app, so he ideally would find someone who had experience with mobile development or someone who could pick up a mobile framework.  And generally, it seemed pretty compelling for a developer.

In this particular case, because mobile development is hot, it was pretty unlikely that this founder would find someone with experience with mobile development willing to jump on this.  So, instead he was really looking for two people: (1) someone with experience who could spend an hour here and there guiding development, (2) an up-and-comer who wanted to get into mobile development.  Did we just make his problem twice as hard?  Not really.  This will still work if you run into exactly the right person. 

Getting to Know Your Prey

At their core, programmers are often motivated by a few specific things:

  • Solve a problem, create something neat from scratch - basically all of us technical people love to tackle problems.  The beauty of programming is that you take a concept and turn it into reality with just typing some stuff into the computer.  It's about creation.  It's really an amazing beautiful thing. 
  • Learn something new - most programmers love learning new technologies or solving new kinds of problems.  They don't want to do the same old thing again.
  • Food and other Rewards - Programmers (like most people) love to be treated nicely.  Most days, they toil away and no one really seems to appreciate what they do.  If you buy them food (pizza, donuts, coffee) or free stuff (tech gadget, big monitor, t-shirt), they will love you for it far beyond the cost of the actual item.

There are also a few things that programmers really do not like, make sure you avoid these:

  • Salespeople / Being Sold - Does anyone like this?  You are selling them, but be subtle.  Ask for help.  Enlist them.  Don't sell them.
  • imagePretending to Know More Than You Know - When people are speaking a non-native language, they often miss subtle things.  I remember how my Swiss German colleagues would say "his English is perfect."  No one who grew up in the US would ever say our English skills rise to the level of perfection.  That's just too high and there's always more.  It tips you off that the person doesn't quite get the nuance.  Speaking tech to programmers is the same thing.  Programmers will hear your little mistakes and if you pretend you "speak perfectly" - it will immediately lose respect with them. 
  • Not Knowing Enough - Unfortunately, you also cannot get into a conversation with a programmer and not know the first thing about the technology.  If you don't understand the basics about mobile technology, then read up on it.  Admit you don't know the details, but at least get to a 101 level before you talk to a programmer.
  • Time Wasters - Don't talk too much.  Stay on point.  Only go social when they go social. 

If you need more help on really getting inside the mind of programmers, two great resources are Dilbert and Foxtrot (the little kid is a budding rock star developer).


Find Your Prey

Urban Legend - Willie Sutton, the bank robber, is known responding to the question "why he robbed banks" by saying, "because that's where the money is."  Turns out that's disputed, but it's still the basis for Sutton's Law.

Where do programmers hang out?  The answer is that programmers are hard to find.  They are generally less social creatures.  They tend to cluster and don't like to talk to people who have lesser abilities (i.e., anyone who doesn't program). 

Some places you can find programmers locally:

In your company or other companies.  Find your dev shop.  Find out who the programmers are.  Visit your friends and ask them to bring you to their dev shop.  Ask your friends to visit their dev shop/programmers on their behalf.

Tech Events / Meetups - There are lots of Networking Events in Los Angeles and Southern California that are techie oriented.  In this case, looking for mobile developer events in the local area makes a lot of sense.  But it would also be good to look for developer oriented events aimed outside mobile to look for people who might want to get into mobile.  You should definitely hit up the Startup Weekend events as well.  And look at

Make sure you meet the people who run these events.  They often can help a lot in navigating to expertise and to possible resources.

Student Groups - Go to the local university and find out what student groups there are for programmers.  Ask around for ideas on where they hang out.

LinkedIn - This remains one of my primary tools.  It's a bit hard to use for this kind of request, but I would certainly go ask everyone I know to introduce me to programmers they know.  And then use them to get to even more.   You can certainly do this through Facebook as well, but I would use LinkedIn.

Twitter - You can run searches for various types of techie terms being used in a given geography.  Follow them and reply to introduce yourself.

Sites - There are a bunch of sites out there aimed at this or similar issues.  Most of them suffer from lack of activity, but it's worth a shot.  Some sites to check out:

You can lookup also on this Google spreadsheet:

You can try finding folks via

Oh, and often there are forums for particular technologies where you can look.  In this case, these sites didn't pan out all that well for the entrepreneur.  Part of the issue was that he wanted someone local.

Approaching Your Prey

Actually, before you approach any programmer, please keep in mind to use caution.  Don't scare off your prey.  Remember that programmers generally are skittish and don't trust outsiders.  You are an outsider.  If you come up to a programmer and just ask them to help you build your product.  Game over.  They will be thinking at that point - "How can I gracefully exit this conversation with my limited social skills?"

Instead think about what will motivate them.  If we take the example that was the genesis here, the founder wants two types of people.  He wants a person who knows mobile development pretty well who can help direct the action (the expert), and he wants someone who is a good coder who can learn to build out the needed mobile application (the developer).  What will motivate these two people?

The first person (the expert) will likely be motivated by being involved in a fun, exciting problem/venture, lots of immediate rewards, not too much time commitment.

The developer will be motivated by getting involved in a fun, exciting problem/venture, lots of learning opportunity.

So, if I'm at an event that's full of prey, I will go around the room introducing myself to people (probably starting with the host) and roughly say:

"I've got a concept defined and some early customers, but I'm not sure if using a mobile framework, building native apps directly, or maybe even doing an HTML 5 app is the right way to go.  Who should I talk to here who I can buy a coffee and tell them about my concept and get their input on the concept and especially on technical direction?"

This is intended to find the experts in the room.  A few notes about this:

  1. Make it clear that you've done your homework:  I already have some people who want this, but I need to get it built. 
  2. Present up an interesting question: I need to figure out what my technical approach will be.
  3. Show you also want their input on the idea.
  4. You are willing to buy coffee, pizza as an immediate reward.

By the way, this works just fine if you happen to already be talking to the expert.  By the way, if the person tells you that you should talk to a particular person then please say, that's great, "could you introduce me?" and start leaning to prompt them to start walking with you.  Most often people are happy to do it and it helps with immediate rapport with the prey.

Once you are talking to a person who's been introduced as a likely expert, the language is pretty much the same as above, but you likely will get into a bit more detail and then ask them if you can get them coffee sometime.  They likely will want to try to solve your problem right there (did I mention us techies like to solve problems).  Resist this a bit.  It would be much better to build more rapport with them.

When I'm looking for the developer, my approach is pretty similar.

"I've got a concept defined and some early customers and have someone who's helping me from a technical strategy perspective, but I'm looking for someone who's a good developer and interested in getting into mobile development."

More Resources

You can find a bunch more resources in this post: Startup Development

Thursday, August 4, 2011

32 Questions Developers Should Ask a Startup Founder

Latest update Oct 2019

Almost every day I'm talking to early stage startup founders (see Free Startup CTO Consulting Sessions) about what they plan to do. I tend to ask a lot of questions, challenge aspects, make suggestions. But I've often been very surprised by one aspect of these conversations. Many of these founders have talked with several developers or development firms about their plans. Yet, I'm often the first person who's asking them questions that I consider to be pretty basic. Of course, it's way more complex than just these questions. It needs to be a conversation. There's just too much variation. Still, if you've not heard these questions from a developer, they are not helping you as much as they should.

Background Questions

Before I jump into the developer questions, let me start with some background questions around the business and product that a developer needs to know. Think of these as the big upfront questions:

1. Who are the customers? What’s their specific need / pain? Please be able to provide me with a few specific examples of different types of customers, what they need, what the system will do for them.

2. Tell me about the business. How are you funding this? What level of funding do you currently have?  Who's helping you with fundraising?  Are there other Founders?  Do you have legal (Founder Agreement, IP, etc.) in place? 

3. What are the big milestones you have as a business? Do you have any specific deals done that are a basis of this? Where are you today and what's happening right now?

4. What have you done so far to validate the concept?

5. What’s different, special here? Where’s the mystery (see Matching Algorithm)?

6. Who are the other stakeholders involved? Other types of users? Partners? Administrators?

7. How will you be taking this to market? What channels will you use (e.g., Ads, Viral/Social, SEO for Startups)?  Is anyone working with you on this? 

8. What are your key Startup Metrics? How do you make your money? How do you measure success?

9. What already exists in your space? Who are your big competitors? What are some good examples of similar sites? How will you differentiate from these?

10. What special data, content, APIs, etc. are you going to leverage? What’s the state of the relationships that brings you that data? What’s the state of those systems?

11. Where do you stand on your brand, name, logo, positioning? Examples of other brands/sites that are similar from a brand perspective?

12. Are there any specific hard dates or important time sensitive opportunities?

13. What do you see as some of the bigger risks / challenges?

14. Major Phases / Major Features - What are the major features in the major phases for the product? What set of functionality would make your company launch-ready?

15. What has been captured so far? Are there specs? Mock-ups? Wireframes? Comps?

Questions Developers May Have Forgot to Ask

So here are some of the questions that developers may not have thought to ask and a little bit of commentary around each question.

1. eCommerce - Is this subscription? If so, how many kinds of subscriptions? What are the rules for subscriptions? Discount support? Free-trials? Bundling? Coupons? Often this ties to marketing support. In other words, you want to offer a discount to a given group to provide incentive. Is it pay-to-play? Do you transact immediately or on delivery of some product or service? Do you have a merchant account already set up? Do you have a payment gateway?

2. Targets - Are you developing for desktop, tablet, mobile?  Are you looking at responsive design or design for a single mobile resolution or something in between?  Is this browser only or are you considering a native application?  Can you do a hybrid web/native application?  Which devices will you test on specifically? This is an area where things are changing rapidly.  Most new sites (but certainly not all MVPs) need to account for mobile delivery which increases the design and development effort.

3. Registration - will you support Facebook Connect or similar authentication? Will you also have a separate login? See also - When to Use Facebook Connect – Twitter Oauth – Google Friend Connect for Authentication. Do you need to round trip an email to validate the email? Captcha? How much member profile information do you need before allowing a user to login?

4. Member Profiles - What data is included? Is there a step-by-step wizard? Pictures?

5. Social Integration/Viral Outreach - are you integrating in some way with social networks? Is your integration limited to login and “like” buttons or are you building a presence within the social networks themselves? Messaging? Any other kind of viral outreach? See Branchout an Example of Viral Spread Opportunity for Startups. Refer a friend? Cloudsponge for email invites to large group?

6. Communication/Forums - are there discussion forums? Commenting? Messaging? Flagging? Moderation?

7. Social Interaction - how do you represent users/members to one another? Is there interaction? What kinds? Friends? I would actually suggest that asking if you want friending/connections is a bit of a trick question. Generally, the answer should be "no." How, if at all, are users grouped by the system? By background (employer, university)? By preferences?

8. Location/Geography - are you using geographic information? How? Is your application location-aware? Will you tap into geolocation services provided by the browser or license a third-party lookup table? How does the application behave when location data is not available?

9. Gamification/Scoring - any kind of scoring and/or gamification to encourage participation? Are there achievements and badges? A leaderboard among users or groups?

10. Video (and Audio) - if you have video, are you hosting it or can we use YouTube, Vimeo? Do you need to process user-contributed media? What about reporting and moderation? Do you want Flash video, HTML 5 video, or both? Does it need to playback on mobile devices?

11. Notifications - what notifications are needed in the system? Dismissable? Do they generate emails or other external notifications? Do you need to provide RSS?

12. Email - are you sending out emails periodically? Are these blasts manually created? Are there complex rules for when emails go out? How often are emails updated, i.e., do you need to be able to edit the email easily? Do we want to use an email service provider to help with delivery? Do you need to track views and bounces? What are your privacy rules?

13. Marketing Support - what will the system need to do in order to help track with marketing and tracking marketing effectiveness? Are there specific landing pages? Tracking URLs? Referral sources? Affiliate tracking?  Do you need to do any significant A/B testing?

14. SEO Support - will URLs need to be well formed? Will back-end support for SEO be needed?

15. Content Management - do we need to allow easy editing of content in the system? How robust does this need to be? Arbitrary new pages? Lists of pages in the interface? Dates/times for posting? Content access controls? Are regular users contributing content or only system administrators?

16. Dates/Time Zones - Do we need to handle multiple Time Zones and do conversion automatically?

17. Search - is there search? What is searchable? How advanced does it need to be initially?

18. Logging/Auditing - do we need to log certain operations in order to help with customer support or for auditing?

19. Analytics/Metrics - what are the key startup metrics that you will need to track? Are there specific metrics needed for future funding rounds or for operations? Beyond simple web analytics, what is needed?

20. Administration - what will you need to be able to do from a back-end? Administer users? Dump out data?

21. Reporting - What needs to be reported? Are data dumps (CSV for Excel) sufficient? Important note here: reporting can be endless, keep it small.

22. Accounting - Do we just need to dump out transactions or is there more to it? Are you tracking inventory? What does the system need to provide to support fulfillment?

23. Customer Service Support - Do you need specific interfaces and support for customer service? Ticket tracking? Are customer service reps heavily constrained or free to make arbitrary changes (and run arbitrary transactions) on behalf of users?

24. Security - are there any specific kinds of security risks? Does the site need to throttle potential malicious activity?  This generally is a significant discussion itself.

25. Performance Requirements - What is the expected Volume of Requests?  What are the response time characteristics required?  What is the complexity of the application?  See: What are the Technical Performance Characteristics of your Startup for more details.

26. Integration Points - are there any third-party systems that we will need to be able to integrate with?

27. Existing People Capabilities - what capabilities such as graphic design, user interaction, product manager, QA do you already have access to? Who? How much availability?

28. Hosting - is there anything in place for hosting? Any preferences? Do you need help getting hosting going?

29. Site Management - what will be needed in terms of site management?

30. Platform – are there pre-existing technical platform decisions that must be considered?

31. Team – is there or will there be multiple segments in the development team? If so, are specific software development processes necessary?

32. Product Management – Do you have a clear vision of the initial product and a plan for sequencing changes after the initial launch? Do you have the internal staff to manage changes?

33. Compliance – What regulatory compliance do you need to support?  GDPR?  CCPA?

Wednesday, July 13, 2011

StartupRoar - Great Content for Startups

Today I join Ben Yoskovitz, Vinicius Vacanti, Jill Hubbard Bowman and Steve Blank and others in announcing the launch of StartupRoar.


This site aggregates and filters content from thought leaders who talk about topics such as Marketing, Sales, Design, Revenue, Hiring, Social Media, Business Models, Metrics, PR, Venture Capital, Angel Investors, Bootstrapping, Incubators, Agile and many others.

As you might imagine, when you go to the page on Customer Development, you find the best and the latest content from people like Steve Blank and Vinicius Vacanti.  For example:

Similarly, when you look at IP / Intellectual Property for Startups, it's dominated by Jill Hubbard Bowman's wonderful content.  Or looking at issues around Founders you find the great post from Ben Yoskovitz on Founder DNA – How Investors Evaluate Startup Founders.  Click around on the various topics to find some amazing resources.

The home page always shows the latest and greatest content coming out.  You can also “change edition” to focus on content written today, yesterday, this week, this month, this year, or other date ranges.  The top items from StartupRoar This Month are some really great pieces:

You can subscribe to a daily or weekly feed of content and you can follow StartupRoar on Twitter.

One thing to make clear, StartupRoar is a jump off point.  All content is shown as a snippet and links directly back to the source.  The site aggregates content but doesn't own it or try to copy it.  The goal is to bring together very high quality content selected by curators, provide a way to navigate through that content, help surface content that might be missed, and be a jump off point to the rich, vibrant startup content community.

Wednesday, June 22, 2011

Visual Basic Reinvented

Back in 2006, I posted about the Promise of Web 2.0 - Comparison to Macros, IDEs, and Visual Basic and pointed out that Visual Basic was a huge innovation that allowed many new developers to build applications.

We've been using Google Apps as the basis for developing some very interesting online applications.  The announcement today Building UI in Apps Script just got a whole lot easier that shows how you can use a drag and drop - Visual Basic like.  It's very crude, but interesting to see.


This is a long way from what you can do with Microsoft Office, Scripting, Visual Basic.  However, because of the cloud nature, this is interesting to see.  That said, it could very well be that Microsoft is able to beat Google to this.

Wednesday, June 15, 2011

Branchout an Example of Viral Spread Opportunity for Startups

imageBranchout, often called LinkedIn meets Facebook, has done a lot in their application to provide users motivation and opportunity to spread the word about the service.  The purpose of Branchout is helping people to network their way to jobs.  However, funny enough, I don't see the job search and showing you who you know at the company as being particularly well done.  As one review put it:

Searching by company to find connections you might have is arduous at best, and in my mind, basically useless.

But that's not the focus of this post.  Instead, I want to look at how they've integrated themselves with Facebook and particularly how they engage users to help viral spread.  And it certainly seems to have worked with reports of:

Branchout has seen explosive growth in January 2011, growing from 10K to 250K monthly users, with a total usership now in the hundreds of thousands.

That's impressive growth!  How did they do it?

Getting Going Is Easy

Branchout has done a great job making registration easy.  You connect with Facebook.  They ask for a little bit additional information and that's it, you are up and going.

They've also done a nice job of importing LinkedIn background information.  It brings in Work History and Education.  It allows you to easily edit items.

You are up and going in just a few clicks.  Of course, there's a lot more on any kind of application like this to really get things setup, but Branchout has done a good job making that happen incrementally.

As an example, they walk you through getting your profile more complete.


and as part of completing your profile, it helps you spread the message around Branchout.


But the next step is a bit questionable.  Is it even acceptable as part of Facebook's Terms of Service to require someone to Like something in order to "complete" it?  This one pushes maybe just a little too hard.  Later in this post, I'll talk about some of the downside of how they've made this viral.


One thing I liked in the design is how they treated completion of the profile:


It's now complete and you just dismiss it from that area.

Primary Interaction - Social Interaction

Okay, my profile is complete, now what?  Well it's interesting that when you look at the home page interface, most of the interface is really about social interaction.  Everything on the left side below your picture is an opportunity to build your network, I've got some details below about a few of them.  The right column also contains opportunities to expand your network.  It does have jobs and companies a little bit, but it's much more abut social interaction.


I'll explore a few of the social interactions that help with viral growth.


I think they did a good job on endorsements.  They use the profile completion to get you to do your first endorsement, so it's more natural to do them in the future.  They have the following information on your home page about what's happening with endorsements to get you into it more often.


When you go into the process of endorsements, they show you your friends and allow you to filter to those who are members and those that have career info.  Once you select someone, it's very easy to add an endorsement.  And, of course, that person gets notified and you can tweet or post your endorsement as well.  When you are done, it asks you to endorse more people.




People can also request endorsements which further promotes this and the interface to provide an endorsement for them is very easy to use.


Network and Connection Statistics

Possibly Branchout focuses too much on your network.  It feels a bit like the early days on LinkedIn.  They definitely push you to be a heavily connected user and give you lots of data.


When you drill down a bit:




I actually think they did badges pretty well.

They give everyone a badge "Early Adopter" and give you an opportunity to post it.  You can also post a Badge Request.


They've made it super easy for you to send badges to other users.  Possibly too easy as it likely devalues them a bit.  More on this below. You can either first choose a badge and then award it or choose a user and award a badge.




Notice also that on the user screen (Alan Edgett), you can give a badge, vote for Alan, request an endorsement, send a message or give an endorsement.  All of these generate social interaction.

I actually think that this particular implementation of badges is a bit weaker than what I've seen in other applications.  If you are looking at how your application can/should use badges, it might be good to review a few other sources.

5 Reasons Why You Shouldn’t Just Add Badges To Any Old Game or Website talks specifically to the issues of being careful about adding badges appropriately and not rewarding just any old action.

A lot of games and services are now copying foursquare to offer badges for actions, and in their rush to get ahead they are offering badges earlier and more often, to make players feel more rewarded. As a reviewer, I play with these services every day and now feel as if a badge has zero positive value, and is just an annoyance.

4 Reasons Marketers Should Add Badges to Social Apps - gives several reasons, but also points out that it's important to show how badges are "earned."  In the case of Branchout, they really are just votes, not as much earned.  There are a few other badges, but it's not clear how you obtain them.

Influence user behavior If users are clear on how badges are earned, badges drive desired user behavior. In our app, unearned badges are obscured visually and accompanied with instructions on how the badge is earned. In the Intel Phone of Tomorrow Challenge, users learn that the Ethernet Badge is earned by successfully inviting three friends to play and the Pocket Protector Badge is earned by commenting on 10 different ideas.


At first when I saw quizzes, I didn't think they would be viral.  Turns out they've done a couple of things to make them viral.


Within a quiz they have a question or two that asks you about your friends and when you choose one, it defaults to sharing this on their wall.  I have no idea how it chose these friends.


They also give you the opportunity to share your results.  They push pretty hard on this by making the little tiny "x" to dismiss and the BIG blue Post to My Wall where you would normally find the default interaction.


They also allow you to invite your friends to take this quiz.  I'm not sure if that really sparks that much interaction, but worth a try.


Hot or Not

As long as we are trying everything to go viral, let's also add in a proven winner - Hot or Not.  In this case, it's in the context of who you would want to work with.


See the little check box on the bottom left.  It's on by default and it shares the result with the winner.  If you uncheck it and begin to go through and choose people, pretty soon you get the following pop-up.  And the word "ignorant" is used to dissuade you from choosing that option.  Having it come up every few times is a bit annoying.


Once I was done going through 30 votes, I then understood what it mean to "vote" for someone which we saw in the interface associated with the user.  I get to see my "Friends with the most Votes".  Of course these are the people who are most connected hence they get the most votes.  So, this is really not quite the same as Hot or Not, but still similar and another way to provide viral growth.


Too Much Social Interaction?

There's been a fair bit of discussion that Branchout is a bit too aggressive in its push for social interaction.  From a post BranchOut, Inherently Viral Services And Customer Acquisition On Social Networks they point to the following kinds of responses that being overly aggressive in pushing viral can cause: