We’re looking for a front end engineer to join us in our SoHo, NYC office.

About You:
- You want to lead front-end development on new products
- You’re comfortable translating AI files into responsive front-ends
- You have experience with jQuery, SaSS and at least one front-end MVC
framework (backbone, ember, angular, etc…)
- Familiarity (but not necessarily expertise) with one server side programming language
- You understand tradeoffs between design and performance
- You’ve got a handle on cross-browser complexity and quirks
- You are more than just a “coder” you have some level of
product/business sensibility
- You are generally fun to be around
- You have interests outside of work.

To apply send us an email to: jobs [at] startupgiraffe [dot] com with examples of your work, salary expectations and favorite beverage.

This position will be a 3 month contract with the possibility of moving to full-time. We strongly prefer NYC based candidates but will consider working with remotely with exceptional candidates.

We don’t know you but we love you.

We often meet with folks who are at the earliest stages of their entrepreneurial ventures and are unsure how to go from idea to product.  After an initial meeting we send them the following recommendations on how to give us (or any other team members) enough context to get started.

1. Provide Background Info

• What’s the one sentence explanation of your product?
• Who are your target users?  We believe in tightly defining your initial target audience and expanding out once you have something that works for them.
• What are your business objectives for the first iteration of the product?  Are your goals related to outside financing, partnerships or revenue?  What metrics do you need to reach to attain those goals (i.e. x users, y% growth, $z sales)?
• What does success look like?  What metrics do you need to capture to know that you’re on the right path?
• A huge number of startups fail because of a lack of traction/distribution.  Acquiring customers is really, really hard.  What is your customer distribution strategy?  How will you get your first 100, 1,000 and 10,000 customers (or dollars in revenue)?  Here are some tips.
• What is the key hypothesis you are testing?
• What are your biggest questions/risks/concerns about this business?
• Who are your competitors?
• What are your core strengths and advantages?
• What’s your revenue model?  (hint: charge for it)
• What do you know that other people don’t?  Why now?  What wave are you riding?

2. “Problem Discovery“ (i.e. conduct 20+ user interviews)

Our natural tendency is too think of solutions first (wouldn’t it be cool if this existed?).  Oftentimes there are many different ways to tackle the same problem.  Fall in love with the problem space and not your particular way of solving it.  It may make sense to take a step back and let your target audience define patterns and validate the problem before addressing solutions. We’d recommend finding people in your target audience and asking questions like:

• How do you currently do [x]?  What tools do you use?  What do you love/hate about them?
• When do you do this (at home, at work, on the go)?  How often do you do this?
• In a perfect world how do you do [x]?
• What are the factors that influence your decisions?  Rank them based on priority.
• Where/how do you involve other people (experts and friends)?
• What are the most time consuming tasks? Where do you make mistakes? What are your biggest frustrations? Where does it get expensive?

etc…  I really like this post on conducting user interviews.

3. “Solution Discovery” (i.e. Fake it?)

After you’ve done a bunch of user interviews patterns will start to emerge.  Are there ways to validate that your solution is one that people would want to use / pay for (see Concierge Testing)?  Can you manually provide this as a service (not to make money but learn the in’s and out’s) before productizing?

4. Define Personas

You’ve now got a clear validated solution and it’s time to scale up with product.  Who are your target users (we’d suggest targeting 2 or 3 different types of users initially)?  What are their main motivations?  What pisses them off?  We’ve put together a light template document for a site like ridejoy.com  (see tab 2 of this doc).

5. Prioritize User Stories

For each of the users you described above, what are the main actions they want to accomplish using this product.  We believe it’s really important to bucket these into critical (you cannot get a customer without), nice to have (in a world of infinite time and money you would do) and things for the future (but not required for your v1).  See a sample on tab 1 of this gDoc.  Remember, you won’t “win” on features.  Building a simple product is hard.

Doing the steps can help you communicate and de-risk a lot of the steps of early stage product development.  Want more reading? Check out these additional links and this talk.  Want to talk about launching a new venture?  Get in touch.

Attention is expensive. Since most people think email is free, message proliferation has seen inboxes become progressively more noisy and difficult to manage. Most people err on the side of over-communicating and over-distributing despite that this incurs a cost to each recipient. Whether it’s extra time sorting through irrelevant message or even just taking the time to delete or archive unwanted messages, people increasingly spend more time in their inbox that isn’t actually centered around communication.

Many attempts have been made to address this problem. First and foremost, the spam filter, which attempts to separate out the most egregious of the unsolicited, irrelevant, and ignorable. Then, for non-spam, there’s sender-selected “priority.” The obvious problem with this is that it’s very subjective. A sender can only guess how important a message will be to the recipient, so they are more likely to use a value that is informed mostly by their own opinion and context. Furthermore, not having any way to curb demand for high priority status leads to rampant abuse. You know who those people are, consistently overstating priority in an attempt to stand out. This not only dilutes the value of the flag but can also create an arms race, forcing everyone to overstate priority to keep pace. Accepting that arbitrary sender-selected priority is not an effective solution, Google has attempted with the “priority inbox” to use heuristics to guess at a message’s value to the recipient, rather than to the sender, giving you an course grained “more important” vs. “less important” view of your messages. As a user of the priority inbox, I believe it really offers quite an improvement. But what it seems to be best at is separating mass emails, transactional messages, newsletters, and marketing blasts from emails sent directly to you by another person. Among emails that were sent to you individually or as part of a small distribution list, it doesn’t offer too much help. Lately Google, this time with Google Plus circles, is again attempting to help us sort our email, by letting us broadly categorize email based on who sent it. Useful again, no doubt, but still only helps us ignore more email rather than to help us get through it all. Even with all the improvements, you can still find skillshare classes on inbox management and “lifehacks” solely aimed at spending less time in your inbox.

Another, arguably less serious problem is knowing whether or not an email has been read on the other side. Email analytics tools almost universally require images to be enabled by the recipient’s client to reliably determine which are read and which aren’t. Read receipts are also imperfect, as they either may not be understood by the client, or simply chosen not to be returned. There’s rarely an incentive for the person to let you know only that they’ve read an email without responding.

Inspired by Facebook’s “pay to message” and a post by Esther Dyson describing that recipients, not Facebook, should be rewarded for their attention; today we’re unveiling a new side project: http://brib.in.

We’re trying this as a social experiment. How do sender and recipient behavior changes when you introduce one of the world’s best motivators: cold, hard cash. If you think your email is important, are you willing to pony up a dollar or two to attract attention to it and get a more reliable read/ignored indicator? As a recipient, are you willing to spend more time in your inbox if you’re compensated for that time? Can publicizing that you require a small bribe to read email effectively curb sender demand, leading to a more relevant — on average, anyway — inbox while simultaneously paying you for your eyeball time? The way the experiment works is that anyone can create and pre-pay a bribe targeted at a specific email address via Dwolla. This bribe (in the form of a bitly-esque short url) can then be included in an email to that address, and the user can attempt to call attention to the enclosed bribe in the subject line. If the recipient opens the email and follows the link, they’ll be given the opportunity to collect their money with one click. At that point, we will give the sender the equivalent of a read-receipt. Given the time sensitive nature of most emails, if the bribe isn’t accepted within a week, the bribe is returned to you and is no longer redeemable.

We imagine the most common bribe scenario will be sending email perceived to be important to someone who has a really noisy inbox. A couple of obvious examples are cold pitch emails sent by entrepreneurs to potential investors and favor/meeting requests to top influencers. If you happen to be one of those people who ignore a ton of email, we welcome you create a quick profile and publicize it so people will know you are more likely to read their message if they bribe you.

Thoughts, comments and feedback appreciated…

Update: We’re in Forbes! http://www.forbes.com/sites/alextaub/2013/02/14/new-tool-bribin-you-allows-you-to-bribe-people-to-read-your-email-with-real-money/

Inspired by this post

Good software projects have clear business goals and objectives. Everyone on the team has an understanding of what metrics will be used to define success. i.e. Implementing these changes to the sign up flow will increase paid conversion rates. Bad software projects are driven by the loudest voice in the room and based on personal preferences. Success cannot be measured because it was never defined.

Good software projects are built initially for a specific target audience based on customer development and hypotheses. i.e. We interviewed 100 used car salesmen and found out their most time consuming task is following up with potential buyers after test drives. Let’s build a mobile web app to let them take notes and send follow-ups while they are still with customers. Good software projects start by doing one thing 10x better than anyone else. Bad software projects are built for everyone. These projects are incrementally better then their competitors and try to “out-feature” them. They are everything for everyone and fall short. They are built because they could, not because they should.

Good software projects have a plan to acquire users after launch. i.e. Through our landing page we’ve accumulated over 1000 emails. We also started a influencer campaign with the top bloggers and Klout scorers in this space. We’ve also set aside $2,500 to test Google Adwords and Facebook campaigns. Bad software projects rely on hope and a ”build it in and they will come” mentality.

Good software projects have a shared sense of ownership and are built with passion and love. Everyone is willing to step outside of their comfort zone to learn new things and attack new problems. Bad software projects have people finger pointing, and people who live within their title and place. “I can’t fix this, I’m just a junior developer. Ask Joanne, she wrote this.”

Good software projects have teams who pay attention to details without getting hung up on them. They are able to make decisions quickly and move on. Everyone working on the project has context. Bad software projects are built by teams without expertise.  They spend weeks arguing over the shade of green on a button.

Good software projects release software as frequently as possible and get constant customer feedback. They have product owners who have a deep understanding of their users and are able to prioritize features. Everyone tests and logs feedback. Bad software projects stay in a black box for weeks and when finally released are underwhelming. Everything is equally important.

Good software projects ship, measure and learn. Bad software projects don’t.

One of the most challenging things about running a software or design consultancy is managing expectations with clients. Many (if not all) programmers, like the late Boris Grishenko from Goldeneye, have a tendency to think they’re invincible. It’s tempting to want to get the product specs and then retreat to your code cave for a month and bang the entire thing out. If the specs were completely accurate, the genius programmer should deliver a perfect product, right?

Unfortunately for us neckbeards, this isn’t the case. With any project, but particularly with early-stage startups, products need to be able to evolve based on client feedback as quickly as possible. Clients change their minds about features when they actually see how they work. They also need to let you know when the specs weren’t exactly right. It puts a huge burden on an early stage founder to produce complete specs in a vacuum devoid of actual user feedback. Sure, the founder might have done low-fidelity tests or market research, but they don’t really know how people will respond to the product until they use it. By delaying showing clients early versions of your work, you’re setting yourself up for misaligned expectations when you finally do show them the product.

We’re a design and development shop, so in our business customer service is really about building a working, trusting relationship with someone in a relatively short period of time. From our experience, it’s critical to get feedback every step of the way, to keep the client involved in what you’re doing. Even though your early work on a project might not be pixel-perfect, getting a client to see it and use it as soon as possible will help you nip potential disagreements in the bud.

At StartupGiraffe, we try to show our clients our work as often as possible. In addition to iterating on mockups and graphic designs together, we try to get something in front of our clients after a few days of coding. Even if we can only show them signup and an unfinished page or two, we’ll do it to show the client our progress and get them used to giving feedback. Every few days throughout the rest of the project, we try to release a new build with notes about the features we’re working on. This gives them ample opportunities for feedback and small changes in product direction. We also timebox our products instead of tying them to stringent scopes of work to allow for corrections along the way and to ensure our clients get a quality product out in front of customers as soon as possible.

It’s a common fear (and myth, really) that showing a client something too early will give them a bad impression of your work. “I can’t even go to my account page or post a comment!” they’ll exclaim and then cancel the contract. In our experience, this is extremely far from the truth. Clients are usually thrilled to see their product come to life and watch its evolution. The challenge is just making sure that the client understands what they’re looking at, what works and what doesn’t, and what they should expect.

Debates rage on whether companies who outsource all or parts of their development can be successful or not. In a perfect world you would have a brilliant in-house team that crushes features faster then you can think them up and has previous experience building similar systems. In reality this almost never happens. While long-term reliance on a development shop probably isn’t a great strategy there are a few situations where short-term engagements make sense.

You need help getting to that next major milestone

The appetite for great technical talent is at an all time high.  Good technologists can get multiple offers for market rates + equity in a startup.  Maybe you can’t afford the superstar you want or your company just doesn’t have the same cachet as competitors.  Having an outside team help you with your next major release could allow you demonstrate the traction you need to get investment or attract that elusive hotshot developer.

You need outside expertise

Sometimes your in house team just doesn’t have the right sort of skills.  Need a Facebook app or help optimizing your Mongo cluster?  Finding a team that has done this before could save you time, money and heartache.  Ideally you can have this outside team mentor and bring your insiders up to speed.

You have significant time contraints

Want to get in the App Store before the new iPhone hits stores?  Have a competitor launching a new product?  Have an external deadline by a partner?  Hiring takes time.  Augmenting your team with outside talent in short bursts can be effective.

What should you look for in a dev shop?

So you’ve decided to take the plunge and hire a team.   How do you know which team is the right one?  What do you look for?  What questions should you ask?  Here are some things to look for:

Rapport

The most important thing when choosing a partner is finding someone you feel comfortable with who understands your vision.  Do they “get” what you are trying to do?  Do they listen (really listen)?  Do they ask the right questions?  Do they speak your language?  Do they have the right “context” for the business you are trying to build?  Do you have a clear understanding of their process?  Many times it’s hard to get this level of comfort with an offshore team.  Even though local teams will probably be more expensive, the end results are usually better because of easier communication and shared context.

Portfolio

Is their work awesome?  Do you see multiple examples of projects they’ve done that you are impressed by?  Have they worked on projects similar to yours?  If not, have they worked with clients similar to you (in terms of size/stage/industry)?

References

Always ask for references.  The company will probably send you the three clients that love them the most, but dig a little deeper when speaking with them.  Ask tougher questions.  What were you surprised about when working with AwesomeDevShop?  How did they do compared to your initial expectations?  Where were they strongest?  Where were they weakest?  If you could do it over again what would you do differently?  Was the timing or pricing different from what you initially agreed upon?  Did you need to go back to them after the project was over for more work?  How was that interaction?  Would you work with them again?  Not everything will be glowing but you should have a realistic expectation of what you are getting yourself into.

Finally always remember that software is never complete.  While a dev shop can be a great stop gap solution, you’ll be responsible for owning the code once they leave.  Make sure you have a clear exit strategy and an understanding of how you will handle ongoing maintenance and support.

Some quick highlights of our accomplishments from our first year:

• We’ve grown our team from two to four full time giraffes plus a partnership with an awesome design agency.
• We’ve launched 11 companies and empowered 25 entrepreneurs to take the leap from idea to starting their own company.
• We’ve proved that partnering with the giraffes to jumpstart your initial development can lead to traction, revenue, significant business development partnerships, outside financing, and full-time job creation (including recruiting in-house technical teams).
• Our portfolio companies have been featured in the NYTimes, Mashable, Forbes, Huffington Post, Fashionista, Business Insider, WWD and other major publications.
• By being smarter about how we build product we’re able to do more with less.  We’re now able to launch a thin slice of any idea in 6 weeks while maintaining lives and relationships outside of the office and working at a sustainable pace.
• We’ve bought hundreds of dollars worth of giraffe gear including a giant stuffed giraffe, hats, dope t-shirts and cute mittens.

While we still have a lot of questions and there is a lot we don’t know, we’re thrilled about the path we are on.  Final thought… giraffes are awesome:

Congratulations to you, budding entrepreneur! You’ve successfully navigated the difficult, even emotional process of slimming down your grand product vision into a lean, focused MVP, and more importantly have gotten it built and launched. While you haven’t yet gone full tilt on marketing and customer acquisition, you are starting to see some traction, maybe some organic growth, or other evidence supporting your product hypothesis. Mazeltov!

Understandably this is an exciting and extremely busy time for you. You’re gathering feedback, establishing a plan for growth, figuring out the rubric of marketing, monetization strategies, pricing models, and all that. There are still bugs to be fixed and basic maintenance to be performed, analytics to be gathered and, well — analyzed. But for the most part, the storm of technical execution has died down. You want to be sufficiently armed with data before coming up with too many drastic changes or new features. Sounds like you’re doing everything right.

But is your app really ready to handle the growth you’re striving for?

Understandably, you probably haven’t spent much time yet obsessing over average request processing times, total request throughput, or doing load testing on your young MVP. You knowingly and rationally incurred some technical debt by not spending valuable development time on fully optimizing an app that will take time to accrue users.

But now you need to accrue users. Hopefully loads of them. I think people in this situation tend to think “OK I’ll just need to get more stuff.” But the truth is, horizontally scaling isn’t always the solution. Sure, at some point, most successful apps will need to do it. There’s a theoretical limit, after all, in how much work one unit of computing can do at any given time. And in certain scenarios (Heroku comes to mind) scaling horizontally can be a quick, temporary solution to unpredicted traffic spikes. But it isn’t a magic bullet; it comes with its own set of caveats. For one, increasing the number or size of one type of resource might not make any difference in overall performance — a “bottleneck” effect. And sometimes scaling one layer in the stack can actually be deleterious. More concurrency can mean more contention for resources, and synchronizing access to those resources can be expensive. I’ve worked on systems where increasing the number of processes concurrently writing to a content store actually decreases data throughput into it. So much time is spent managing who can write, and when, that performance degrades overall.

There’s good news, though. There are likely massive improvements to be made in app performance post-MVP with a relatively low amount of development and architectural effort. Focusing on this vertical scalability now means that when you do scale horizontally, you’ll get much more bang for your buck as each unit you add on is capable of doing much more work. But before running headlong into your codebase to hack, you should spend some time identifying problem areas. Scour your logs for types of requests that have high average or extremely variable response times. What’s high? It depends on who you ask, but anything that on average is taking hundreds of milliseconds, instead of tens, is a good place to start. Chances are those operations have the most room for improvement. Once problem areas are identified, here are some things you may find that, once addressed, might confer huge benefits.

1) Serving static content

I know what you’re thinking: “I already have apache or nginx serving my static assets, so it doesn’t affect my app performance.” Nonsense! Why is your app bothering with static content at all? Add a memory based reverse proxy cache (like Varnish) or use a CDN. Apache and nginx spool assets from disk. In a typical LAMP configuration, this is the same disk that your datastore is reading and writing to. And even though disks and operating systems do their own caching, performance will never approach what Varnish can muster. A CDN goes a step further and keeps static asset requests away from your application almost entirely, and has the added benefit of responding from geographically variable locations based on where the client is. There may also be requests that are handled by your app server, but change infrequently. Obviously, these too can — and should — be cached in the same way as static assets.

2) 100% synchronous database writes

In your app there are likely places where you are doing synchronous database writes on the responder thread, even though it is perfectly fine if the data isn’t written until later. Why is your user waiting for your system to do something that doesn’t affect their experience? Send the data to a memory, memcache, or redis based asynchronous queue for processing. In fact, any operation that is non-critical to responding adequately to a request should be processed asynchronously, especially sending transactional emails or doing data aggregation.

3) Using SQL databases for everything

There are a range of persistence options available to your app. Don’t assume you can only use one at a time, or that it has to be a SQL database. Take high frequency, transient, non relational, non transactional data interactions and move them to Redis, Memcache, Mongo, or any other such store that crushes Postgres and MySQL in terms of write and/or query performance.

4) Not properly indexing tables/collections

This should go without saying, but properly designed database indexes drastically increase performance in large data tables/collections. You may not notice it at first, but as your data grows indexes can keep query performance mostly constant. Of course care should be taken not to over-index a particular table or collection as it can negatively impact write performance.

5) Not using application level memory caches

You should use memcache to cache any data your app uses that does not need to be 100% real time. This is especially important if the data is stored in SQL databases. MongoDB query performance is more in the same ballpark as memcache key retrieval, but is still not quite as fast. Rails — and I’m sure other stacks as well — can also cache action/template output whole hog, if you need to do request filtering even when content doesn’t change frequently.

6) Serving model/information heavy pages

Why are you responding to a request for a page with all the information that may possibly ever be presented on it? For heavy pages, respond with enough to present the UI to the user, and wait until the user intends to interact with a specific set of data before retrieving it via AJAX.

7) Doing operations on your server that you could do on the client (especially third party API requests)

While sometimes it is necessary for your app to sign or otherwise provide authentication for an API request, generally it’s the client who is the authorized, trusted party, not your app. Facebook, google, youtube, and twitter APIs can all be interacted directly with by the client once authorized. Oftentimes, no authorization is even required. Proxying these services is a waste of your app server’s time. There are many other operations that clients can capably perform, too. Sorting, file processing using HTML5′s File Api, you name it. Client computing power scales naturally: more clients means more available resources.

Once you’ve gotten your app nicely tuned with respect to these kinds of items, you should have some breathing room within your current architectural configuration for increases in load. Eventually, when you’re well funded and have full time, dedicated technical resources, you’ll probably want to move off of managed hosts like Heroku and on to your own infrastructure, where you can get substantially more computing resources for the money. Until then, I hope I’ve convinced you that there are many tools at your disposal to help bridge the gap when you are beginning to scale.

Get paid to launch startups, become the tech co-founder of your favorite one

StartupGiraffe.com helps entrepreneurs refine, design and build the first version of their startups. Our typical project takes 6 weeks from idea to beta. We’ve launched 10 startups in the last 10 months including stereogrid.com, therunthrough.com, undergroundeats.com, vestorly.com and eatdrinkjobs.com.

We’re looking for a ruby on rails engineer to join us in our SoHo, NYC office.

About You:
- You want to join a startup in a lead engineering position but you also like eating and getting paid.
- You are interested in launching a new startup with us each month and potentially joining your favorite one as a tech co-founder
- You are more than just a “coder” you have some level of product/business sensibility
- You have experience with web architecture design, RESTful architectural principles, Ruby on Rails, MongoDB, HTML5, CSS3, Javascript, JQuery, TDD
- You are generally fun to be around

Bonus points if you like giraffes, whiskey, chipotle and seltzer.

To apply send us an email to: jobs [at] startupgiraffe [dot] com

Below are some examples of how successful companies smoke / ghetto / wizard of oz tested their ideas:

Zappos

In 2000 it wasn’t clear that purchasing shoes online was a great business.  Shoes have different fits and comfort levels and many thought they needed to be worn before they were sold.  The riskiest question for founder Nick Swinmurn’s fledgling company was:  ”Will people buy shoes online?”  One way to answer this would be to go out and raise millions of dollars in financing, build a huge warehouse, fill it up with shoes, build a comprehensive ecommerce system, hire a bunch of folks, cross your fingers and pray people placed orders.

Nick realized there has to be an easier way to de-risk his business.  Instead he went to Foot Locker and took pictures of their inventory.  He put photos of the shoes online.  Every time someone placed an order, he went to Foot Locker purchased the shoes and mailed them to the buyer.

Is this model scalable? Nope.  Did he make money on each order? Nuh uh.  Was he able to prove that people would by shoes online and get some early traction?  Yes.  (source: The Lean Startup)

TheLadders

In 2003, Marc Cenedella saw the difficulty executives were having finding new jobs online.  Wouldn’t it be great if there was one place that listed only high end (in this case $100k+) jobs?  Is that a service that job seekers would pay for?

Marc’s initial “prototype” involved going out once a week and browsing HotJobs, Monster and other job boards to manually collect $100k+ jobs.  On Monday mornings he would send a newsletter to job seekers containing only these 6-figure jobs.  He charged $25 to subscribe to the newsletter and his audience quickly grew through craigslist postings and word of mouth.

After we had been doing that for about nine weeks, I missed the 9 a.m. Monday deadline… At around 9:10 I started getting e-mails from people asking where the newsletters were. Those e-mails kept coming. That’s when I really knew I was onto something. That was the moment of validation.

Having passionate users who care when you mess up is an awesome sign of product-market fit.  Once a manual approach no longer scales you are in a great position to start automating these pieces with software.  (source: Sramana Mitra)

Aardvark

Google is really bad at answering questions like: Where should I grab a drink in SoHo after work?  Should I go to business school?  Which DSLR camera should I buy?  On the other hand, people are really good at answering these questions.  Aardvark was started as a social Q&A service.  You would send Aardvark a question over instant messager.  Aardvark would do some magic and get 3 people to answer your question and send it back over IM.

The most technically complex piece was the algorithm to find the right 3 people to answer your question.  The folks at Aardvark realized that although there was a large technical hurdle, the riskiest question to the success of their business was not can we build it, but will people use it. Rather then spending time initially to build out the algorithm they used a Wizard of Oz approach:

Aardvark employees would get the questions from beta test users and route them to users who were online and would have the answer to the question…  While it used humans “behind the curtain,” it gained the benefit of learning from all the questions, including how to route the questions and the entire process with users.

(source: Dean Eckles)

Zynga

Taken from my previous post on: 8 Lessons Learned from Zynga about Virality

In the last 5 minutes of the video below Zynga’s founder Mark Pincus is asked what’s the best way to do market research. His answer – “Ghetto Test”. If someone wants to build, let’s say, a hospital simulator he creates an FB ad that says, “Ever wanted to run your own hospital?” which leads to a survey (or if it’s really ghetto a 404 page).

All Zynga has to do is track CTR and compare it to previous historical rates to get a pretty good idea of demand.

This works great if you are comparing multiple game concepts, product ideas, taglines, names, etc… though isn’t a good fit for testing out a new concept (without a comparison).

Seamless

The folks at seamless allegedly spent their first few months without a web product.  They called up law firms in NYC and asked what they wanted for lunch.  They called the restaurant, placed an order, managed delivery and billed the firms at the end of the month. (source: anecdotal)

Groupon

Andrew Mason and the team at Groupon launched the first version as a wordpress site.  Besides posting a deal, everything else was manual.

It was totally ghetto. We would sell t-shirts on the first version of Groupon. We’d say in the [write] up, ‘This t-shirt will come in the color red, size large. If you want a different color or size, email that to us.’ We didn’t have a form to add that stuff… It was enough to prove the concept and show that it was something that people really liked… It got to the point where we’d sell 500 sushi coupons in a day and we’d send 500 PDFs to people with Apple Mail at the same time.

(source: Weblogtoolscollection)

Conclusion

There are obviously situations where a lean approach doesn’t apply (i.e. google the search engine or an iPad).  For the large majority of startups today the biggest question is not can we build it, but should we.  Before you go ahead and spend a ton of time and money building complex technology, try to manually execute parts of your business for a small target audience.  Once things are working and you are unable to scale, then invest in technology to automate.

Any other good examples that we missed?