The $20 Starbucks Test

A couple of weeks ago I had the good fortune to meet Hugh Crean, the ex-CEO of Farecast, ex-Microsoft executive (they acquired Farecast) and current Entrepreneur in Residence at General Catalyst. A group of us talked to Hugh for close to an hour, and I learned more about the travel industry in that short span than I’ve learned in a lifetime of flying, hoteling and using Kayak, Priceline and the like.

The purpose of our chat with Hugh was to get some feedback on a project we are working on, and Hugh shared a cool $20 technique for validating your new product, service or startup idea that I’d like to pass on. Here is how it works:

1. Get yourself a nice crisp $20 from an ATM
2. Go down to your neighborhood Starbucks
3. Walk up to strangers with empty coffee mugs and tell them you are worried about your brother, need some advice, and can you buy them a cup of coffee in exchange for a quick 5 minutes of their time. (This will be awkward for most of you to do. Get over it. The “worried about my brother” line is a bit of psychology that means most people won’t turn you down. If they do turn you down, you just got a point in the Rejection Therapy Game anyway, so consider yourself lucky).
4. Buy them a simple coffee, not a mocha-whippa-frappa-latta-chino; you want your $20 to last.
5. Explain that your brother has a crazy business/product idea, and that he’s about to get a 2nd mortgage on his house, raid his 401k and quit his job. His wife is a nervous wreck, afraid that they’ll lose their house and retirement fund, and he’s hit your parents up for seed money that they really can’t afford to lose. Your parents and your sister-in-law have come to you for help to try to talk him out of his hair-brained scheme.
6. Explain that this is where they come in, your brother is a very logical and reasonable guy, and can be convinced by good reasons, but he has been blinded by thinking this is a really good idea. The problem is, you sort of agree with him, so you need some really solid reasons to give him as to why his idea won’t work, and why he shouldn’t proceed with his plan. Then… pitch your idea! Sell it the best way you can. Respect their time (you asked for 5 minutes), but give the best 2-3 minute pitch you can.
7. Now, ask for their reasons the idea won’t work. Keep them focused on the idea, not the backstory (they may want you to convince your brother of the merits of retirement savings or the dangers of 2nd mortgages), and really listen. Resist the temptation to argue against their objections. Then thank them heartily for their time.
8. Repeat until your $20 runs out.

What will you learn from the experiment?

The most likely outcome is you’ll hear mostly the same obvious rejections of your idea that you yourself have and have come to believe are surmountable. Your $20 didn’t generate any great new insight, but was an inexpensive check that you aren’t blind to an obvious shortcoming.

A good outcome, is that you hear lots of interesting and sound new objections that you never thought of before. This should give you real pause about your idea. Both its merits, if the objections are good ones, and the extent that you’ve sufficiently thought through your idea and are being realistic about it.

A not so likely outcome is that your strangers will find themselves agreeing with you and your “brother” that it is a great idea. They themselves will want to buy the product or service and they’ll start naming other people that need it. They’ll also probably apologetically offer up a few lame objections, because that’s what you asked for. In the unlikely event this happens with your idea, you probably have a real hit on your hands. Run with it!

Two quick caveats… this works best for a consumer product or service. If your idea is for a better steel retracting refluxerator for pediatric heart surgeons, then the man on the street in the coffee shop might not be a great source of insight. Also you have to get comfortable with the white lie you’ll be telling about your “brother”. If you can’t get comfortable with that, it’s understandable, but it is an important part of the technique. The negative priming and the distancing of yourself from the idea gives your coffee companion free reign to trash your idea so find some other way to provide some distance from the idea. If instead you say it’s your idea, then even when you invite criticism and honesty, people will candy-coat their feedback. Luckily our social norms will not stand in the way of them trashing your brother who’s not in the room.

Always Be Building Your Own Products

Like many small technology companies, Snooty Monkey makes the mortgage and the payroll through work for clients while carving off time to build products. It’s not ideal, but it beats the alternatives: working a corporate job for years to save up a financial runway, or ceding autonomy to outside investors, who of course get a say in how their money is spent.

Once you have built a successful services business in a niche that matches your passions and interests (in the case of Snooty Monkey, building brand new products for entrepreneurs), you can start to ask yourself: this is profitable; this is fun; why not just do this forever?

Even if your long term goal is to have a services business (or be a freelancer) and build products for other people, you should never stop building your own products. There are important professional obligations that client work brings. Being free at times from those obligations is critical for long term success.

#1 Learn radically new stuff

When working for a client, you have an obligation to manage technical risk and to properly represent your experience and skills. Both of these work to prevent you from learning radically new stuff “on the clock”.

Managing technical risk involves choosing a sound technology that’s suited for the task at hand, that’s robust and relatively bug free, and where you have a reasonable assurance that they’ll be future development to fix bugs, fix security issues and adapt to new operating systems and language versions. You also are obliged to choose technologies that are readily picked up by someone else should you get hit by a bus. If you are the only Logtalk programmer in a 4 state radius from your client, it’s probably not a great idea to build your client’s project in Logtalk without their informed buy in.

Representing your experience and skills is all about communication and honesty. If you literally wrote the book on a given technology, say so. If you are waiting for your copy of the book to arrive from Amazon, and will know more next week once you get to chapter 2, say so! When hiring freelancers or project teams, clients are usually paying for more than your raw intelligence. Part of your rate derives from your skills and experience with a technology. If you don’t have said skills and experience, many clients won’t be interested in you learning them on the job, and others may expect a break in your usual rate until you come up to speed. This is a reasonable position for your client to take if your usual rate properly reflects the skills and experience you bring to the table.

That’s not to say a given client might excuse you from all these obligations and give you free reign to learn a risky new technology that you have no experience with on the job. But that’s a double rainbow client. Don’t expect to have them.

None of this precludes trying new things and continual improvement. You also do your clients a disservice by never learning, adapting and improving. Each project should be better than the last. Always been a  Test::Unit user but want to use RSpec for the next project? Want to switch from your tried and true restful-authentication to the new hotness, authlogic? These evolutionary improvements are not what I’m cautioning against in client work. It’s the big disruptive changes that make you suck for a long time until you “get it” and that you have a good chance of deciding are a mistake and abandoning.

So how do you make those big leaps forward that require a huge step back first? Do them on your own time of course. And rather than building the blog sample from the book or some other toy project, you might as well try building a useful product. You’re going to invest the time in the new technology anyway, if it turns out to be great stuff, it’d be great if you got a fantastic new product out of it along the way.

In that vein, Snooty Monkey kicked off the development of a new product last week; the idea for it has been kicking around since Summer. Some weeks we’ll spend no time on it, some weeks we’ll be able to carve out a few hours or a whole day. Our “rule” (admittedly arbitrary) is, everything has to be new. The main purpose of the project is learning and having fun. The secondary goal is creating the product (if it was the primary goal, we’d use the tried and true technology stack).

Out: MySQL In: CouchDB

Out: Ruby In: Erlang (the 1 tiny exception to the rule, it’s new for all but 1 of us)

Out: Rails In: Nitrogen

Out: XHTML In: HTML5

Out: JavaScript In: CoffeeScript

Out: AJAX interval polling In: Comet and Web Sockets

Out: CSS In: LESS

Reader’s imaginary Socratic dialog section:

Q: Is this choice of technology driven by the needs of the project or is it a bit gratuitous? A: Uhh… the tail is wagging the dog.

Q: Will you be able to build the new product as fast as you would if you used a tech. stack in your comfort zone? A: No.

Q: Will you be able build a successful product with it? A: Dunno.

Q: Will you learn a lot? A: Hell yeah!

Q from a Geek: Is it going to work well to combine CoffeeScript with all the JavaScript generated by Nitrogen. A: Dunno, waiting for that CoffeeScript book to get here from Amazon. We’ll find out. But I think you missed the point. Go back to the top and re-read the post.

#2 Reconnect with your inner customer

The other great reason to not stop building your products is empathy. Being a “customer” of your own services stokes the flames of empathy. It’s important to walk in your customers shoes, to put yourself in the position to care about the same things they care about. Are you sitting your customer down for the three legged stool  talk (“Sorry Jack, scope, time or resources; only 2 can be fixed…”)  yet again? When was the last time you sat yourself down for the same talk?

Treat yourself like you treat your customers. Don’t give yourself special breaks and exceptions you wouldn’t give them. Make a budget (in time, not dollars) and try to stick to it as they have to. How easy do you make sticking to the budget? Are there things you are doing, such as lots of tangential work on the project that’s not core, or a lack of timely visibility and tracking that make it hard to stick to it? Or are you so fixated on the budget that you sacrifice the other goals of the project?

Most important to rebuilding the empathy with your clients is to scratch your own itch with the product. Build something that you are madly passionate about, and that you are the customer for. It’s easy to slip into a calloused, distanced, assembly-line mode of working when building product after product for customers. You need to rekindle the spark that comes when you are building something that you are truly obsessed with. By reminding yourself what it’s like to care so much about the outcome, you’ll be better able to empathize with your clients.

The Erlang Shell

One option to running the Erlang shell when your code is in ./src, including files in ./include, and building to ./ebin is to run erl from ./src as such.

erl -pa ../ebin

All your modules are then local and can be accessed. You can include records with rr(module).

Thanks MononcQc on #erlang.

Erlang