You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The general consensus is that a startup is a business built to grow extremely rapidly.
Rapid growth usually necessitates the use of a technology that invalidates the assumptions of politicians and businesses.
Startups in the past & present
Not only were capital costs low, at the beginning of each of these earlier startup eras, there was no permitting process.
The initial pioneers in these startup eras thus had time to get underway before competitors and regulations alike started presenting barriers to entry.
Key Features of Internet Startups
Operational Scalability
The theoretical cost-per-transaction (for both buyer and seller) is thus far lower than any physical store.
Market Size
It’s still not trivial to scale across borders or states, but the practically addressable market size has
never been larger.
Generality
Software is the most general product imaginable (every field uses s/w) and software engineering skills are highly portable.
Low Capital Barriers
You have an incredibly powerful manufacturing device on your desk, a kind of virtual 3D printer before its time, whose
price is now within reach of even the world’s poorest.
Low Regulatory Barriers
Unlike virtually every physical arena, the internet is still mostly unregulated, especially for smaller businesses.
Free and Open Source Software
The internet is built on open-source technologies, FOSS is a uniquely scalable means of charitable giving.
Long Tail
Not only is it possible to address markets of unprecedented size, it is now feasible to address markets of unprecedented specificity (e.g. via ads on FB).
Failure Tolerance
The almost nonexistent penalty for failure permeates every layer of decision-making at an internet company (e.g. Move Fast and Break Things). Moreover, as computer power grows, we can now simulate more of the world on the computer before shipping the final product.
Amenable to Titration
It's possible to build a hybrid business in which you engage with the physical world (e.g. Uber, AirBnB, Groupon). The advantage is that market demand is proven, price points are generally higher, and real-world impact is tangible. The disadvantage is that some or all of the above trends may no longer work to your benefit. The key is to titrate at the right level.
Technological Trends Toward Mobility and Decentralization
A number of new technologies on the horizon point in the direction of continued decentralization and individual mobility.
What is Startup Engineering?
Startup engineering means getting something to work well enough for people to buy. Startup engineering is concerned primarily with shipping a saleable product.
Technologies
One of the primary things a startup engineer does is systems integration: keeping up on new technologies, doing quick evaluations, and then snapping the pieces together. The right tools can be like the difference between going to the library and hitting Google.
When building a startup, in the early days you want to first choose the best contemporary technology and then forget about technology [1] to innovate on only one thing: your product. Outside of the core technology, you want to be as boring and vanilla as
possible until you begin to make a serious profit from your first product.
[1] At the inception of a company, or a new product, you will gain maximum advantage from selecting the best contemporary technology, one that is clearly rising but may have some rough edges. Today, that technology is arguably a full-stack JS framework based on node.js, making heavy use of AWS and Heroku. In 2-3 years it will likely be something different. But once you pick out the elements of your technology stack and begin developing your product, relatively little added value comes from radical shifts in technology (like changing frameworks), and switching technologies can become an excuse for not working on your product.
Design, Marketing, and Sales
To ship a product a startup engineer needs versatility. If you are a founder, you will need to handle things you've likely never thought about. You’ll need to be able to produce a passable logo, design the first brochures, and do the initial sales calls - all while moving technology forward. You will greatly benefit from the ability to handle things, like the ability to design, market, and sell the product you’re building.
Why Mobile HTML5 (for the Final Project)?
Mobile is the Future
Mobile clients are now vastly outselling PC clients.
Responsive Design gives Desktop UI for free
Design for the mobile interface and limited screen real estate first, then add more bells and whistles (like larger images) for the desktop site.
Location-Independence increases Scope
Mobile apps that increase people’s location-independence should significantly increase your perceived scope for mobile.
Simplicity
Mobile apps force simplicity.
Ubiquity
Your HTML5 app will be crossplatform and you will also have an API that you can use to build further apps.
JS is the Future
Fast JS interpreters became available in the browser (v8), on the server (node.js), and even in databases (MongoDB); it's the Next Big Language.
Amazon AWS is useful for having a centralized development environment that's accessible from anywhere and is easily clonable. There exist alternatives for cloning configurations, e.g. Puppet, Vagrant, Chef.
Setting up your instance
Create an EC2 instance with the quick launch wizard
You may also choose 13.04+, which ships with mosh.
Billing Alerts
Go to My Account > Billing Alerts and follow the instructions.
If you're taking advantage of the free tier, you'll want to set the alert threshold to $0.
Set up an EC2 Instance which allows instant previews
Set up an EC2 instance which allows HTTP connections on ports 80 and 8080. This will allow you to debug your webpages while previewing in a browser, rather than copying it locally or pushing to Heroku.
Go to the EC2 Dashboard to set up a new security group. Apply the new security group to an existing instance. Instances > select your instance > Actions > Change Security Group > select the new security group
Note that you can also create a new instance with the new security group.
Don't forget to add the UDP rule for mosh to work.
Set your web app to run on port 8080 (e.g. in web.js for a node project). Run your web app (e.g. node web.js).
Open your browser and view your site. E.g. ec2-54-218-72-128.us-west-2.compute.amazonaws.com:8080
Quick commands
You can run a command with ssh and exit right away, e.g.
$ ssh -i Downloads/dideler-startupeng.pem [email protected] uptime
03:17:15 up 17:00, 1 user, load average: 0.00, 0.01, 0.05
$ # mosh doesn't support this yet
Elastic IP
Note that if you terminate or stop your instance, the hostname of your EC2 instance will change and your SSH config will fail to work. You can either a) not terminate the instance, or b) assign the instance an "elastic IP" from Amazon and reference that address instead.
For an elastic IP, go to "Network & Security" > "Elastic IPs" > "Allocate New Address" > "Associate Address" to your instance, then use the given IP. Each running instance is eligible for an elastic IP at no charge, but multiple IPs costs $.
mosh
Set up mosh for AWS (it ships with 13.04+ but AWS has 12.04). Open the UDP ports 60000-61000 in EC2. From the AWS console, go to your EC2 instance manager and click Security Groups in the sidebar. Select the security group your instance is using (probably quicklaunch):
Now connect to your instance
$ mosh --ssh="~/bin/ssh -i ~/path/to/your/ec2/keypair" [email protected]
Configure SSH config for less typing
Configure ~/.ssh/config so you can just type a shortcut (e.g. mosh aws or ssh aws) to connect.
mkdir -p ~/.ssh
mv ~/Downloads/identity.pem ~/.ssh
chmod 400 ~/.ssh/identity.pem # if you haven't already
chmod 700 ~/.ssh
nano ~/.ssh/config # see below for content
chmod 600 ~/.ssh/config
Contents of ~/.ssh/config should look like this.
Host aws
Hostname ec2-54-218-72-128.us-west-2.compute.amazonaws.com # or use the IP address
User ubuntu
IdentityFile "~/.ssh/identity.pem"
man ssh_config for more info.
Install tools
You'll have to install all your core dev tools, such as npm and node.
Don't forget to install git and set it up (use GitHub's tutorial). Also copy over your dotfiles.
Vagrant et al
Alternatively (and probably a better solution) is to use virtual environments and something to easily manage them (e.g. Vagrant + Puppet/Chef, Salt, Ansible (good for small jobs), virtualenv/virtualenvwrapper, etc). This allows you to easily create disposable development environments.
Vagrant is an established project that wraps around a number of existing virtualization providers (e.g. VirtualBox, VMWare, EC2) to allow for extremely quick provisioning of disposable, consistent environments. Create a single file for your project to describe the type of machine you want, the software that needs to be installed, and the way you want to access the machine. Store this file with your project code. Use vagrant up to configure a new VM (using a virtualization provider) using that configuration. Then, Vagrant can use one of many configuration management tools -- Chef, Puppet, Salt -- to configure that disposable environment to mirror your production environment. Vagrant doesn't really do configuration on its own (unless you count running shell commands).
Transferring files
Copy files to/from the server using scp (GUI options exist and one is built-in to Ubuntu). E.g. to copy a file from the server to your local machine:
If you set up your SSH config file (see above), then scp becomes a lot simpler to use:
scp foo.txt aws:~/bar.txt
(Re)claim ownership of directories
Some commands, like npm, require superuser permissions. Instead of using sudo every time, you can claim ownership of the appropriate directory. E.g. sudo chown -R ``whoami`` ~/.npm
Also called the application-service-provider (ASP) loophole. You can include GPL software in your non-GPL software (hence not having to release your code) if you're providing service over a network, i.e. it's server-side code (todo: verify). You can also use GPL code in your non-GPL code if you link the the code but do not use it's source directly in your source.
Open Source Business Models
There's the professional open source model, which RedHat made popular. The problem with this route is that a model based on consulting is a service-business, not a product business. It doesn't scale as well (hiring more competent people vs buying more servers).
There's the freemium model (e.g. Dropbox, GitHub). Basic services are free and premium services are paid.
And other models, mentioned later.
How Linux is used in the Valley
Most common setup is to equip engineers with Macbooks (personally I think ThinkPad is just as good an option) for local development and servers running Linux (as a virtual machine) for production deployment. This is because OS X runs a BSD variant, so most code runs between OS X and Linux with little or no changes.
Gaining popularity is to use Chromebooks (which start at $200) and SSH to a server (e.g. AWS)
Virtual Machines
Infrastructure-as-a-service (IAAS) providers, like AWS, usually do not rent out single physical computers, but rather a virtual piece of a multiprocessor computer. Virtualization allows maximal physical utilization of expensive multiprocessor hardware. An 8-CPU computer split into 8 different virtual servers offers better utilization, even though the "virtual computers" are less powerful than native hardware.
The Cloud
A cloud computer is a remote computer accessible over the network (typically interent) and is used instead of running something locally. Many applications can tolerate a small degree of network latency and/or physical separation, making cloud computing quite useful.
There are 3 classes of cloud computing:
IAAS: AWS, Joyent, Rackspace, ...
Provide CLI access to the machine, but you have to take care of details for deploying code.
PAAS: Heroky, DotCloud, Nodester, Google AppEngine, ...
Provide an API that abstracts the CLI, but access to CLI is possible if absolutely necessary.
Note: Heroku began as a layer on top of Amazon AWS.
SAAS: Salesforce, Google Apps, Mint.com, ...
Provide GUI or API access, no CLI access (hence no control over h/w).
Allows you to reconnect and resume your session where you left off. Useful if a remote connection drops or for any long-running computation (running as a background process--see above--is a viable alternative).
tmux is considered a better alternative to screen. Use it with teamocil to automatically create sessions, windows and panes with YAML files.
In screen, type
C-t ? to bring up the help
C-t c to create new tabs
C-t u or j to switch tabs
C-t 0..9 to go to a specific tab (starts at 0)
C-t C-t to go back and forth between the current and previous tab
C-d to exit the current tab
C-t [ to go into copy mode
now you can use the arrow keys to move around or C-p/n to move up and down
copy stuff with (space) or (enter), you have to set beginning and end
paste with C-t ]
abort with C-(space)
screen -d to detach the screen (type inside screen)
screen -r to resume the screen (type in shell)
Note: C-t ? means CTRL and t followed by ?.
emacs environment for writing code
First execute the setup script.
sudo apt-get install -y git-core
# see https://help.github.com/articles/set-up-git for more help
git clone https://github.com/startup-class/setup.git
./setup/setup.sh
Launch emacs without windows and without customizations: emacs -nw -Q
Go to the command prompt with M-x, where M is the meta or alt key.
Type help-with-tutorial for a tutorial.
Exit with C-x C-c.
Note: I'm skipping the rest of the emacs section since I'm a happy vim user. You can view the rest of the emacs tutorial by reading the above linked PDF, or start by watching this lecture video.
git distributed version control system (DVCS)
Note: I'm also skipping this section because I'm already well versed in git. I once gave a presentation on git.
Tip: The crowdfunding site that we're building uses heroku/node-js-sample as a base. See here for more info. Don't forget to heroku create from your project's git repo, then git push heroku master.
DevOps Basics
You should have a setup.git repo (configures the machine) and dotfiles.git repo (configures the user environment). Setup.git will have a script that clones and sets up your dotfiles; you can also combine them into a single repo. These make setting up a new dev environment much easier and quicker by programmatically configuring an arbitrary machine.
For a business, it's better to use a more professional solution such as Vagrant (configures the [virtual] machine) + Puppet/Chef (configures the user environment & software) or many of the alternative options.
To fully automate setting up an EC2 instance, use the EC2 command line tools so you don't have to use the web GUI. Use in conjunction with a user-data-script for automatically running a startup script on each instance.
Any setup/configuration of a machine is code and should be treated as code. If the change is permanent, do not set it up manually on the dev machine. Instead, add it to the install scripts and config files and keep it under version control.
An idea is not a mockup
A mockup is not a prototype
A prototype is not a program
A program is not a product
A product is not a business
And a business is not profits
It’s useful to actually keep a single Google Spreadsheet with all your ideas, organized by stage in this manner.
Expect most to stay at the idea stage!
Idea
When it comes to starting a business, the conventional wisdom is that the idea is everything, the rest is just a matter of details. This is how the general public thinks technological innovation happens. Remember how people felt about the Instagram acquisition?
Execution
Execution is everything. Ideas and inventions don't matter if you cannot make a single sale.
The rationale here is that it’s easy to come up with a trivial idea like “let’s build a social network”, but quite nontrivial to work out the many technical details associated with bringing that idea to market, from large-scale to small-scale decisions.
It’s also extremely nontrivial to actually turn a popular technology into a profitable business.
If someone can steal your idea by simply hearing about it, you probably don’t have something yet that is truly defensible.
You can usually be reasonably open about discussing your ideas with people who can give a good bounce, who can understand the idea rapidly and throw it back with modifications. The vast majority of people are busy with their own things, or aren’t uncreative sorts who are both extremely good at execution and just waiting around to steal your idea.
BEWARE: If you have a pure internet startup idea, you should think carefully about whether you want to promote it on HN or the startup community before you’ve advanced it to at least a prototype stage.
People will copy the idea as soon as the market is proved out. It is far easier to verify a solution than to find one in the first place. A product selling like hotcakes is the ultimate demonstration that you have found a solution to a market need.
You’re going to need excellent execution to survive, because sometimes these “clones” far surpass the originals. Sometimes it makes sense to keep your head down and grow once you’ve hit product-market fit without alerting competitors to the scale of your
market opportunity.
Market
“It’s not the idea, it’s the execution”. From an investor's standpoint, “It’s not the product, it’s the team”.
A strong team will execute on that idea and push through all the details (financial, regulatory, technical, legal) to get that product to market.
The newest conventional wisdom: market is the most important factor in a startup’s success or failure. Why?
In a great market – a market with lots of real potential customers – the market pulls product out of the startup.
The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.
The product doesn’t need to be great; it just has to basically work.
And, the market doesn’t care how good the team is, as long as the team can produce that viable product.
The Idea Maze
A good founder doesn’t just have an idea, they have a bird’s eye view of the idea maze. A good founder is thus capable of anticipating which turns lead to treasure and which lead to certain death. A bad founder is just running to the entrance of the maze without any sense for the history of the industry, the players in the maze, the casualties of the past, and the technologies
that are likely to move walls and change assumptions.
A good idea means a bird’s eye view of the idea maze, understanding all the permutations of the idea and the branching of the decision tree, gaming things out to the end of each scenario. Anyone can point out the entrance to the maze, but few can think through all the branches. Historical perspective and market research is key. Find a hidden door, a unique insight from deep thought that others did not see.
The Execution Mindset
The execution mindset means doing the next thing on the todo list at all times and rewriting the list every day and week in response to progress. This is easy to say, extremely hard to do. It means saying no to other people, saying no to distractions,
saying no to fun, and exerting all your waking hours on the task at hand - run the maze rapidly.
Execution heuristics
The most important tasks are those that get you to the maze exit.
One Thing
Everyone in the company should at all times know what their one thing is, and others should know that as well.
Anti-TODO list
Periodically write down what you just did and then cross it off.
Even if you get off track, this gives you a sense of what you are working on and your progress to date.
Implement “Thiel’s One Thing” with chat status.
If there’s something that’s worth nagging people about, it’s keeping their Gchat status up to date with their latest Github issue. It constantly refocuses you on your one thing, and allows the entire company to know what that is without constant interrupts. Periodically, you too can scan what others are working on without disrupting their flow.
What Kind of Business Do you Want to Build?
Startups vs. Small Businesses
A startup is about growth and usually involves new technology and unproven business models.
A small business, by contrast, does not have ambitions of world domination and is usually geared towards a particular geographical area or limited market where it has some degree of monopoly through virtue of sheer physical presence.
You can start to see why startups are associated with the internet and small businesses with physical storefronts. There are exception, e.g. "life-style business" internet companies like 37signals, and physical operations like McDonalds that aim for world domination.
Small businesses must usually generate profits right away, while startups often can be in debt for a while.
Should you take outside capital and try to grow the business more rapidly, or should you rely on steady organic growth? Most go for outside capital.
Startups Must Exhibit Economies of Scale
Do a simple calculation to determine whether a given business is capable of getting there, i.e. it exhibits an economy of scale.
Shift per-unit costs into fixed costs (e.g. via software).
Costly up-front software development can pay off in the long run.
Determine how much capital is needed before the business breaks even.
Pricing is important; to the extent that you are not constrained by competition,
you really do want to charge the highest possible price at the beginning to get into the black as soon as possible.
Moreover, free or heavily discounted customers generally don’t value the product and are the most troublesome;
paying customers are surprisingly more tolerant of bugs as they feel like they’re invested in the item.
Incredibly difficult to achieve low price points (e.g. $199 or $99) without massive scale. It’s hard to make a profit!
Startups Must Pursue Large Markets
The annual market size is the total number of people who will buy the product per year multiplied by the price point.
To get to a billion dollars in annual revenue, you need either a high price point or a large number of customers.
Note that low price points require incredible levels of automation and industrial efficiency to make reasonable profits.
Do Market Sizing Calculations Early and Often
With all else held equal, you want to pick the project with the largest market potential.
Among other things, market size determines how much money you can raise, which in turn determines how many employees you can support. Among other things, you won’t capture the entire market, but only a portion.
The best market size estimates are both surprising and convincing. To be surprising is the art of the presentation. But to be convincing, you want to estimate your market size in at least two different ways.
Top-down sizing: Start from the top (high-level numbers) and work down from that overall number to figure out what’s relevant to your company.
Use Fermi estimates to determine the number of people who will buy your product (top-down market sizing). This will require knowledge of general stats like 300M Americans, 6B world population, 6M US businesses, as well as domain-specific stats like 4M pregnancies.
Bottom-up sizing: Look at individual customers or competitors and roll them up to get the overall size of the market.
Rolling up the revenue from individual companies (e.g. using SEC filings) to look at the overall market can be a great approach when there is a relatively small number of public companies in the market (e.g. US car market). In smaller and more fragmented markets, adding up individual competitors quickly becomes painful, but it can still be your best option.
Bottom-up analysis is generally more reliable, but you have to be careful not to overstate the boundaries of the relevant market. Usually the addressable market won't be the overall market, but a specific sub-market. Be a little critical of your own estimate and make sure that you’re sizing the market that you or your client can actually address, not a general market that looks impressive but isn’t really relevant. Also keep in mind that bottom-up analysis is generally not exhaustive.
Every market sizing approach involves a good bit of uncertainty. Time and data permitting, you should triangulate among a top-down analysis, a roll-up of individual customer spending, and a roll-up of competitor revenue. In an ideal world, these numbers should all be in the same ballpark, but if there is a discrepancy, you can troubleshoot your analysis or do a weighted average of the estimates based on your most reliable information. The resulting number won’t be perfect, but you’ll have a good analysis to walk clients or investors through to get their buy-in.
Tip: If data is really scarce, you can do some very rough market sizing by estimating company revenue based on employee numbers (which is typically easy to find, e.g. LinkedIn, Wikipedia, company's team/about page, Google Finance). This approach doesn't work well for early stage or small (< 100 employees) companies.
Tip: Stats Canada is a good source for market sizing. US sources.
Time to market (i.e. how long until shipping) is everything in startup land, due to the compounding effect. This is a second and crucial consideration in addition to sheer market size.
VC's will often use the following formula to help deciding on investing:
((QMP) / (SNT))^(1 / T)
Where:
Q: probability of success, or one minus risk
M: market size (in dollars)
P: percent of the market attained in the first year
S: average salary per person (in dollars per year)
N: headcount
T: time to market (in years)
This can be thought of as the amount of money returned divided by the cost of generating that money.
It measures a company's growth factor (because compounding is everything for investors). More accurately, it's the measure of first-year-revenue divided by cost to get to first-year-revenue, renormalized for time to market.
Market Research
A good idea means a bird’s eye view of the idea maze.
The execution mindset means rapidly navigating the idea maze.
Market size drives not just the relevance of the company, but also controls downstream parameters like the quantity of money that can be raised and hence the number of employees.
Tools for market research (!)
Establish that a market exists before building a so-called minimum viable product (MVP).
Get some news coverage or research papers to establish the overall frame and display in any pitch to investors.
Use Google Books, Wikpedia, SEC filings, and so on.
Back of the envelope estimate of market size, googling as necessary for any statistics.
Allocate a small Google Adwords or Facebook Ads budget to test out the market, and see how many conversions you get.
A framework for determining product tiers
You've got a market and product idea, what features do you build first?
Figure out the precise minimum scope of what you want to create
Calculate how much money is required to achieve that minimum goal
Consider the power of your social network. In other words, how much money do you realistically think you can raise?
Pricing tiers depend on what you're offering. On KickStarter, common high-grossing tiers (by percentage contribution) are:
$25
$50
$100
$250
$500
$10,000 (have some intermediate tiers to make this one seem more attractive)
People don't mind paying $50 or more for a project they love. Be careful, mindset changes for mobile apps.
Avoid tiers less than $25, they are statistically insignificant.
5 tiers maximum, too many tiers can put off supporters.
Create tiers for the exact same product with backer caps at each one until the highest one.
Bulk discount tier.
The average pledge is around $62.50 (based on old KickStarter data).
You're not just raising money, you're also building a community of supporters through the fundraising process.
For crowdfunding, keep your funding period to 3-4 weeks. Any longer and it will likely have stale periods.
Reach out to blogs, relevant news sites, social media, personal & marketing mailing lists early on. Send about two emails on the mailing list at the beginning, one midway, and one near the end (e.g. 3 days or less).
Think in terms of micro-seed capital not one-off money.
Use these steps to aid with selecting product tiers and prioritizing features/versions.
The basic idea is that the ultimate market research is a table with 7 billion rows (one for
each person), N columns on their attributes (e.g. location, profession) and K columns (one
for each product version), with each entry giving the amount that person will pay for those
features. You won’t be able to sample all 7 billion, but you can sample a few
hundred (e.g. with Google Consumer Research Surveys
or Launchrock landing pages), and this gives you a conceptual framework for how to set up your product tiers
In particular, you want to confirm that you will make enough money on version 1 to pay for version 2.
If this is not the case, you should rearrange the order of features until it is true, at least on paper.
The vast majority of people will pay $0 no matter how many features you add (or remove).
A big mistake software companies make is charging too little, but the biggest mistake is charging too much, so they don't get enough customers. People tend to believe that you get what you pay for. When you're setting a price, you're sending a signal. Price below your competition and people think it's crap, price significantly above and it's outstanding.
You're not trying to maximize units sold (i.e. sales), you're trying to maximize profits.
When calculating profits, disregard the initial/upfront costs, those are sunk costs. Instead, consider the incremental/recurring cost of selling each additional unit (i.e. marginal cost), which may include S&H, support, etc. Your actual profit is units_sold * (price_per_unit - marginal_cost). Plot your profits for different price points to figure out how to price your product.
You'll want to capture the consumer surplus from consumers who would spend more than your decided price point and sell to them for a higher price. You'll also want to email/call back and beg those consumers who were willing to spend at most some price under your asking price and offer them the product for cheaper.
Separating your customers into different groups according to how much they are willing to pay, and extracting the maximal consumer surplus from each customer is called segmented pricing.
different brands (e.g. Old Navy, Gap, Banana Republic. For software: "Home" vs "Professional" edition)
Be careful, segmenting pisses people off, they want to pay a fair price. It creates no loyalty. It's also difficult to pull off properly. Don't use segmented pricing if you want to avoid headaches.
The only way to determine how much someone will pay for something is to put it up for sale, and see how many people actually buy it. Seriously consider spending about $250 for a demographically targeted survey with 500 responses. If you genuinely can’t afford this, ask 10-20 of your friends how much they’d pay for different version of your product, or run a poll on Facebook. Any feedback on pricing and features, even biased, is better than none.
Once you feel that you have a market, you should design a mockup of your product’s website, also known as a wireframe. Your main goal is to produce sitemaps and detailed user flows.
Here's an example of wireframing a crowdfunding page.
Our crowdfunding site will use this basic layout.
Which can be made with the following HTML (which uses Bootstrap).
And it looks like this (not the final product of course).
Copywriting
High-level principles:
Homepage message
Don’t expect visitors to figure out what the product is about on the third page in;
your enemy is the back button. Go to a cafe and test your homepage message on people with the 5-10 sec rule.
Only spend energy on the homepage if it’s a significant source of customers.
If it isn’t (e.g. if your sales come through a salesforce),
you can leave the homepage alone for a surprisingly long time.
Testimonials and customers
People feel more at ease when they see other real people and companies using the product and recommending it.
Work backwards from the press release
Amazon writes the press release before they build the product.
Doing this, you will find yourself figuring out what features are news and which ones are noise.
Someone is wrong on the internet
Get a friend to pull up as many competitor webpages as possible.
Write down your immediate gut reaction as to why those companies are terrible and your company and product is different.
Put this into a feature matrix
and then determine whether your new features really differentiate your product substantially.
Simple and factual
Do your best to turn vague features (“PageRank provides better search quality”) into concrete facts and statistics
(“85% of searchers who used both Blekko and Google preferred Blekko. Find out why.”).
Use Oracle style marketing:
less is more, hammering one point above the fold (i.e. above the scroll line) and keeping the rest in the secondary copy.
Alternatively, use a carousel
to neatly hammer out multiple points above the fold (but be careful).
Check out Dropbox's minimalist landing page.
Call to action
You want someone to do something when they come to your page, like buy something or sign up on an email form.
Make sure you reiterate this “call to action” many times (at least at the top and bottom of page).
Make the call to action button cartoonishly large and in a different font.
Take a look at the landing pages of some of the current top startups for inspiration (for both what and what not to do).
Design
Wireframe goals:
Functionality and semantic meaning: what does the product do?
Marketing copy: how do we explain what the product does in words?
Consider using comics!
Design: how do we make the site and product look beautiful and function beautifully?
High-level principles:
Vector and Raster Graphics
Understand the distinction between vector (dynamic resolution) and raster (fixed resolution) graphics.
Whenever possible, work with vector images as they will scale well and are amenable to later manipulation.
Raster images are unavoidable if you truly need photos on your site, but strive to minimize them for your MVP.
Become familiar with the four principles,
CRAP,
as mentioned in the
Non-Designer’s Design Book.
A good strategy is to look at the examples, create your design without thinking too much about them,
and then re-apply them over the design at the end.
In terms of getting something reasonably nice together quickly, you should make heavy use of fonts and icons.
Because fonts are vector graphics specified by mathematical equations, they are infinitely manipulable with CSS transforms
built into every browser. The FontAwesome library also gives scalable vector icons, which are often useful for quick
mockups when enlarged in size. Also consider using Unicode characters for icons.
Often the key to a good presentation or webpage is to put an abstract concept into visual form.
Stock photographers have actually thought about these issues.
Don’t use stock photos in which people are looking at the camera!
That’s what makes a stock photo look cheap.
A good signal of a lower quality site is that it has inconsistent padding, doesn’t use https properly for checkout,
and/or uses stock photos of this kind. You might also consider reshooting a stock photo with your product so that
it looks custom.</dd>
When it comes to turning your wireframes into HTML/CSS/JS, don’t reinvent the wheel.
Design is information and is becoming commoditized. Use Bootstrap + Jetstrap.
Themeforest is a set of slightly more expensive ($9-12) templates.
99Designs is a few hundred to a few thousand bucks for a logo or webpage revision.
Dribbble is an excellent resource for finding a contract or full time designer.
You begin by typing a URL into address bar in your preferred browser or clicking a link.
The browser parses the URL to find the protocol, host, port, and path.
If HTTP was specified, it forms a HTTP request.
To reach the host, it first needs to translate the human readable host into an IP address,
and it does this by doing a DNS lookup on the host.
Then a socket needs to be opened from the user’s computer to that IP address,
on the port specified (usually port 80 for HTTP).
When a network connection is open, the HTTP request is sent to the host.
The details of this connection are specified in the 7-layer OSI model.
The host forwards the request to the server software (most often Apache) configured to listen on the specified port.
The server inspects the request (most often only the path), and the subsequent behaviour depends on the type of site.
• For static content:
– The HTTP response does not change as a function of the user, time of day, geographic location, or other parameters (such as HTTP Request headers).
– In this case a fast static web server like nginx can rapidly serve up the same HTML/CSS/JS and binary files (jpg, mp4, etc.) to each visitor.
– Academic webpages like http://startup.stanford.edu are good examples of static content: the experience is the same for each user and there is no login.
• For dynamic content:
– The HTTP response does change as a function of the user, time of day, geographical location, or the like.
– In this case you will usually forward dynamic requests from a web-server like nginx (or Apache) to a constantly running server-side daemon (like mod_wsgi hosting Django or node.js behind nginx), with the static requests intercepted and returned by nginx (or even before via caching layers).
– The server-side web framework you use (such as Python / Django, Ruby / Rails, or node.js / Express) gets access to the full request, and starts to prepare a HTTP response. A web framework is a collection of related libraries for working with HTTP responses and requests (and other things).
– To construct the HTTP response a relational database is often accessed.
– While sometimes raw SQL is used to access the database, modern web frameworks allow engineers to access data via so-called Object-Relational Mappers (ORMs), such as sequelize.js (for node.js) or the Django ORM (for Python). The ORM provides a high-level way of manipulating data within your language after defining some models.
– The specific data for the current HTTP request is often obtained via a database search using the ORM, based on parameters in the path (or data) of the request.
– The objects created via the ORM are then used to template an HTML page (server-side templating), to directly return JSON (for usage in APIs or client-side templating), or to otherwise populate the body of the HTTP Response. This body is then conceptually put in an envelope with HTTP Response headers as metadata labeling that envelope.
– The web framework then returns the HTTP response back to the browser.
The browser receives the response. Assuming for now that the web framework used server-side templating and returned HTML, this HTML is parsed. Importantly, the browser must be robust to handle broken or misformatted HTML.
A Document Object Model (DOM) tree is built out of the HTML. The DOM is a tree structure representation of a webpage. Think of a webpage as composed of chapter headings, subsections, and subsubsections.
All browsers provide a standard programmatic Javascript API for interacting with the DOM, though today most engineers manipulate the DOM through the cross-browser JQuery library or higher-level frameworks like Backbone.
New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
CSS is parsed, and used to annotate each node in the DOM tree with style information on how it should render.
Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly. That is, Javascript controls behavior, and the Javascript executed on page load can be used to move nodes around or change appearance (by updating or
setting CSS styles).
The browser renders the page on the screen according to the DOM tree and the final style information for each node.
You see the webpage and can interact with it by clicking on buttons or submitting forms. Every link you click or form you submit sends another HTTP request to a server, and the process repeats!
Separation of concerns
Any web app will include HTML, CSS, and JS files in addition to server-side code.
One of the advantages of node.js is that the server-side code is also in JS.
You should separate your HTML, CSS, and JS, such that you can change any of the three (or more) files that specify a webpage without worrying about the other two. In practice, you will need to develop all files (.html, .css. and .js) at the
same time as significant changes to the structure of a page will often remove id attributes or CSS styles that your JS code depends upon.
When in doubt, err on the side of separation of concerns: use HTML for structure, CSS for appearance, and JS for behaviour.
Tools
The single most important thing to learn are the Chrome Developer Tools. With these tools, you can do the following:
Edit the styles and DOM nodes live on a page.
Click an element on a page to find it in the markup, or vice versa.
Watch network connections and inspect HTTP requests and responses.
Initial idea doesn't need to be great, but it has to evolve into a great idea. Ideas for fast growing companies are so rare that the best way to find new ones is to discover those recently made viable by change. The majority of startups will be working on something that's never going to go anywhere.
Growth drives everything in this world. In technology, companies that grow slowly tend not to grow as big. The company's growth rate is the measure of a startup. If you don't know that number, you don't even know if you're doing well or badly. A constant number of new customers every month means you're in trouble, because your growth rate is decreasing.
Measure growth rate per week, but only after you've launched. A good growth rate (during YC) is 5-7% a week. If you can hit 10% a week you're doing exceptionally well. If you can only manage 1%, it's a sign you haven't yet figured out what you're doing.
Focus on just hitting a growth rate every week. This focus reduces the otherwise bewilderingly multifarious problem of starting a startup to a single problem. Use that target growth rate to make all your decisions for you. Having to hit a growth number every week forces founders to act. Nine times out of ten, sitting around strategizing is just a form of procrastination.
Best thing to measure growth rate of is revenue for startups that charge initially, and active users for startups that do not.
Startups early on need frequent feedback from their users to tweak what they're doing.
Be aggressive when recruiting new users. Manually and individually recruit your initial users; go out to a coffee shop and have people try your product. Go door-to-door. Have people sign up for your beta in person. The numbers will seem small at first, but don't be fooled by compound growth - it starts slow.
The question to ask about an early stage startup is not "is this company taking over the world?" but "how big could this company get if the founders did the right things?" And the right things often seem both laborious and inconsequential at the time.
You should take extraordinary measures not just to acquire users, but also to make them happy. Send them handwritten thank you notes. Give them free stuff (e.g. DropBox gives free space). Your first users should feel that signing up with you was one of the best choices they ever made. One advantage of being small: you can provide a level of service no big company can.
You can and should give users an insanely great experience with an early, incomplete, buggy product, if you make up the difference with attentiveness. The feedback you get from engaging directly with your earliest users will be the best you ever get.
Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly.
Like paying excessive attention to early customers, fabricating things yourself turns out to be valuable for hardware startups. You can tweak the design faster when you're the factory, and you learn things you'd never have known otherwise.
Pick a single user and act as if they were consultants building something just for that one user. The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too.
Another consulting-like technique for recruiting initially lukewarm users is to is to use your software yourselves on their behalf. They might not want to make and setup an account, so do it for them with their consent. It can teach you how it would feel to merchants to use your software. Sometimes the feedback loop is near instantaneous.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks.
The Big Launch tactic doesn't work. Launches matter very little.
Partnerships usually don't work either. They don't work for startups in general, but they especially don't work as a way to get growth started.
Any strategy that omits the effort—whether it's expecting a big launch to get you users, or a big partner—won't work.
TL;DR recruit users manually and give them an overwhelmingly good experience, and founders need to work hard
Convince investors with your startup, not your pitch.
Be formidable founders.
A formidable person is one who seems like they'll get what they want, regardless of whatever obstacles are in the way.
Formidable is close to confident, except that someone could be confident and mistaken.
Formidable is roughly justifiably confident.
To seem most formidable as an inexperienced founder is to stick to the truth.
Convince yourself that your startup is worth investing in (not that it'll succeed), and then when you explain this to investors they'll believe you. And by convince yourself, I don't mean play mind games with yourself to boost your confidence. I mean truly evaluate whether your startup is worth investing in. If it isn't, don't try to raise money and change what you're doing.
Know everything about your market.
To evaluate whether your startup is worth investing in, you have to be a domain expert. If you're not a domain expert, you can be as convinced as you like about your idea, and it will seem to investors no more than an instance of the Dunning-Kruger effect.
The time to raise money is not when you need it, or when you reach some artificial deadline like a Demo Day. It's when you can convince investors, and not before. Work on your startup up until a week before your pitch before switching focus.
Founders think of startups as ideas, but investors think of them as markets. If there are x number of customers who'd pay an average of $y per year for what you're making, then the total addressable market (TAM) of your company is $xy. Investors don't expect you to collect all that money, but it's an upper bound on how big you can get.
Your target market has to be big (eventually), and it also has to be capturable by you.
Identify some specific trend you'll benefit from.
Usually you can find this by asking "why now?" If this is such a great idea, why hasn't someone else already done it?
Ideally the answer is that it only recently became a good idea, because something changed, and no one else has noticed yet.
The best investors rarely care who else is investing, but mediocre investors almost all do. So you can use the question "Who else is investing?" as a test of investor quality. The best solution is to tackle the problem head-on, and to explain why investors have turned you down (make it clear when you ask that you're not trying to dispute their decision—just that if there is some weakness in your plans, you need to know about it) and why they're mistaken. The most common lie is that while no investors have committed yet, several are about to.
Don't use vague, grandiose marketing-speak in your pitch. It not only doesn't work on them, but seems a mark of incompetence. Be clear and concise, use the words that convinced yourself.
After the 1999 crash, people in Silicon Valley overreacted and learned you had to do things differently to survive.
Believe and practice incrementalism.
Grand visions and moving quickly fell out of favour.
Your startup has to be “lean.”
You should not, in fact, know what you’re going to do.
Instead, you should experiment, iterate, and figure it out as time goes on.
Zero advertising spend.
If your growth isn't viral, it’s fake.
Eg. PayPal paid new customers and paid for referrals, growth was exponential.
Anti-social was the new social.
People wanted to withdraw into a new antisocial modality.
Interact with computers rather than people.
Product needed elevation over business development.
Rapid monetization was to be distrusted.
Better is a more protracted growth phase and later IPO.
You shouldn’t discuss the future. That will just make you look weird and crazy.
Bubbles arise when there is (1) widespread, intense belief that’s (2) not true.
To understand businesses and startups in present day, you have to do the truly contrarian thing: you have to think for yourself. The question of what is valuable is a much better question than debating bubble or no bubble.
APIs make a product into a Platform. The platformized product will always beat the unplatformized product, all else being equal. They enable third-party developers to predict what users want, and it would happen automatically. You don't need to waste time and money predicting what users want and delivering it, leave that to others.
The most important thing is Accessibility. A product with zero accessibility is a non-existent product. Accessibility and Platforms are basically the same thing, because platforms solve accessibility. A platform is accessibility.
The Golden Rule of Platforms, "Eat Your Own Dogfood", can be rephrased as "Start with a Platform, and Then Use it for Everything."
A bad idea is still a bad idea. The idea doesn't matter as much as the execution, but is still a big factor. Pivot to find the right idea quicker.
Long term planning is a real advantage, as many startups don't think about it.
A good idea is also a business that's difficult to replicate.
If you have several ideas, work on the one you think most about when not working.
To get through the pain of a startup, the company should feel like an important mission.
Good ideas often look bad at the beginning. If they sound too good, too many people are already working on it.
You want to find a small market to quickly create a monopoly, and then expand.
You've found it when people depend on it even when it's still a crappy incomplete product.
Reply to criticism: "I know it sounds like a bad idea, but it's not. Here's why..."
Sounds like a bad idea, but is a good idea.
Find a market that's going to be big in 10 years. Investors are obsessed with current market.
Why now? Why is now the right time for this idea?
If it takes more than a sentence to explain, it's almost certainly a bad idea.
Niche clone companies usually fail.
More important than starting a startup, is finding potential cofounders.
Great Idea -> Great Product -> Great Company
Talk to users
Sleep
Stay healthy
Make something people love, then focus on user growth.
You'll know people love it when you see organic growth (e.g. word of mouth).
If you're waiting on something like a partnership, your product isn't loved and you're wasting time.
Users love simple. You can always make something with a smaller subset than you thought possible.
Worry about making it better later.
Recruit users by hand, not adwords. E.g. go to coffeeshops and ask to try product, set homepage in Apple stores, etc.
Ask them what they like and don't like. Ask them what they'd pay for. Ask if they'd be bummed if the company went away. Ask if they would recommend to their friends. Keep a tight feedback loop, super important in early days!
Don't hire sales and support people right away - you need to do this yourself first.
Dustin (FB)
Being a founder is incredibly stressful.
Fair of failure when an entrepreneur is enormous. You don't want to fail yourself, your employees, investors, etc.
Always on call
Fundraising
You're committed, can't leave easily
You're a role model
You have to report to everyone
There's always work to be done
Lecture 2 (wk 1)
Sam Altman
Choose cofounder extremely carefully (more careful than first hire)
School and innovative tech companies are good places to find them
2-3 cofounders works well
Be like James Bond: calm, decisive, relentless, resourceful, always know what to do
Do not hire (wait very long until you hire)
A single mediocre hire in the first 5 will kill a startup
Best source for hires is personal network (you or cofounders)
Experience usually doesn't matter too much, more about attitude
They may not scale, but a good person can always find another place in company
Must be smart, get things done, do you want to spend a lot of time around them?
If you do interview, ask about past experience (e.g. projects) and call references (e.g. In your top 5? Would you hire again?) . Do not ask brainteasers.
Must be a good communicator and should like a little bit of risk. Should be able to enjoy spending time with them socially and must enjoy reporting to them if roles reversed.
"Beast" test: each of your team members should be a beast at something they do
Be generous with equity to employees, very stingy with investors (unfortunately way too common to see the reverse)
Cofounders should decide on cofounder equity early on, and should be mostly equal
Employees should be happy and feel valued otherwise they will leave
Give team credit for anything good
Take responsibility for anything bad
Learn a bit of management skills; will go a long way
Do 1-on-1s and give clear feedback
Firing people is one of the worst parts of running a company
Fire fast when not working out
Fire if
bad at job
creates office politics
always negative
Don't start with remote cofounders
Communication and speed is vital which you get from working in the same room
CEO has five jobs
set the vision
raise money
evangelize
hire and manage
make sure the entire company executes
Focus is super important.
Ask a cofounder what they're spending their time and money on
