Matthew Moore

At CrowdMob, we’re thinking a lot about how people buy things.  We’re selling package deals of virtual goods alongside deals in order to help convert those users who wouldn’t otherwise buy the virtual goods.

What we’ve found is that mindset (mood + context) is the key factor whether or not users decide to convert at the current point in time.  The easiest example with which to understand this theory is the difference between impulse buys and logical buys.

When someone is thinking on impulse, their mindset is a focus on self-indulgence.  Logic plays very little role here; if you’re impulsively thinking about buying a snickers, your mind turns off the logical part of the brain that reminds you that snickers aren’t healthy for you.  If someone is thinking about buying snickers, you’re not going to sell them a productivity product.

On the other hand, if someone is thinking logically, their mindset is strictly focused on buying what makes sense.  Someone who is thinking about productivity products is not going to be able to be sold a snickers, even if they otherwise would love snickers. 

Simply put, different parts of the brain are firing, and you as a marketer can’t switch those parts of the brain on and off in the mind of your customer.  To extrapolate from this, it’s pretty clear that you have to market products in the context where potential customers are ready to convert; you’re not going to be able to change their minds.

More on this in the future, but I’ve recently become obsessed with mindset-oriented distribution and advertising, rather than behavioral advertising, which tends to ignore your current mindset. 

There’s not much to say about me, really.  I’m just a guy who was lucky enough to grow up in the Silicon Valley, and have a life-long interest in technology and business.  After helping to start Pogo Linux in 1999 with some friends, I left to study Computer Science at UCSD .  There I was fortunate enough to be involved in helping to start VentureForth, a student-run organization focused on helping others who were also interested in entrepreneurship.  After graduating, I couldn’t pass up an opportunity to work at Google  - and I can’t overly-express how thankful I am to have gotten the opportunity to do so.  In 2007, I felt it was time for me to take my own path, and start ThriveSmart with Jennifer Chen .  While ThriveSmart runs, I’m also one of the co-founders of CrowdMob and its CTO.

I keep a blog first and foremost for my own benefit: I want to track what I’ve learned and how my views change over time.  I’m also hopeful that by recording what I learn, I can help others avoid the same mistakes I made.  As Warren Buffett says, it’s better to learn from other people’s mistakes than your own.

Of course, there are a few people I consider my personal heros.  You’d do much better to learn from them than you would to learn from me: Steve Jobs , Warren Buffett , and Bill Gates .  My personal recommendation to you: learn everything you can about them.

You can also find me on Google Profiles, LinkedIn or Facebook , Twitter .

And that’s it! Onward.

Albuquerque, NM
April 2, 2009 

A group of my friends recently had a discussion about how to market our new slew of web products.  I was sad to say that in my perspective, there is absolutely no silver bullet, one size fits all approach to marketing an internet business.  This is mostly a result of the fact that the target users/customers think about and interact with every product in a different way.  So choosing a winning set of marketing strategies differs accordingly. 

What does seem to be valuable is to try to divide up the different marketing strategies for web products into different conceptual buckets.  The 4 buckets I came up with were: Invites, Poster Customer, Publicity (Including Stunts, Advertising and Blogging), and Word of Mouth.  Whenever you’re trying to determine what strategies are best for your business, it can be helpful to pick and choose from all four categories to start with (and see what sticks).  However in the end, devoting the majority of effort to the one or two conceptual buckets that work will likely pay off the most.

1. Intrinsically Viral (Invites)
Businesses like Facebook and YouTube can be classified as intrinsically viral because of 2 simple facts: because (1) a single user legitimately uses the web app often (multiple times a day) and (2) when someone invites another user, the invitee is immediately in the position to be a user from Minute One - before they forget about the app. Good examples are Massively Multiplayer games, Email, and Messaging apps. However, I don’t think that many web apps fall into this category because many web apps try to solve a semi-specific, non-every-day problem.  But if an app is intrinsically viral, they’ll explode like no one’s business, on invites alone.

2. Poster Customer
Other web apps can get to fame by having one single killer customer, because every other potential user is so intertwined with that customer. Ruby on Rails moving to GitHub made them, and that was pure genius (and incredibly useful to developers). I see this with Apture, too, when they integrated with the Washington Post.  In general, high-profile integrations can be big wins in the Poster Customer department.  If a huge base of your potential users are linked to a single product or organization, start imagining ways to convert that product or organization to your web app!

3. Publicity (Including Stunts, Advertising, and Blogging)
The publicity avenue his is where your average webapp (and average company) would fall. Most businesses need something that gets them into related media publications or videos which are important to their customers. Great examples from the past are when Taco Bell claimed they bought the Liberty Bell on April fools, to Jared the Subway guy getting the attention of Oprah. There’s no limit to the possibilities in ways to get publicity, but your company doesn’t directly get multiplicative benefits from each stunt thereafter - just additive effects.  Publicity can be an important place to start for any new product, but it doesn’t scale nearly as well, because you have to keep raising the bar.  

If you do go down this route, make sure you read Made to Stick.  While the first quarter of the book is mind-numbingly dull (they need to follow their own advice!), the latter quarters are totally worth it, and will change how you attack all forms of publicity.

4. Word of Mouth, Most Importantly! (Translation: Increase Per-User Usage)
The Word of Mouth is probably the holy grail for most products that don’t have any intrinsic ‘virality’. Word of mouth is multiplicative, so once you get some base set of users spreading the word, the tidal wave cannot be stopped.

The trickiness with word of mouth as a strategy is that it relies heavily on the amount of exposure (usage) that a single person has.  Very few people will talk about an app that they use once a month, but many will be happy to talk about apps that they use daily or multiple times a day.  As an app’s exposure rate to a user goes down, the usefulness has to go way up (reaching the level of being an absolutely necessity) for word of mouth to take place.  So while you might focus on making your app absolutely necessary for your users, you might just aggressively increase the amount of exposure every existing user has to your app. This in-turn means creating features which provide users a real incentive to return to your app every day on their own accord (as opposed to coercing them to).

If you look at almost every single sensational web application - or even business - you’ll find regular usage by each user. Google, any successful email site, YouTube, Facebook, World of Warcraft - heck, even Coca Cola (drunk multiple times a day) - every single one of these sensations had a reason to be used multiple, multiple times a day for real reasons that benefit the user.

~~~~~

Those are the 4 conceptual strategies I bucket marketing into, anyway, and I’d love to hear your insights as well.  Leave them in the comments!

And once again - if you have a new web app, try a little bit of everything to start with.  But sooner or later, you’re going to find that one or two of those types of strategies wins out for your particular product!

Albuquerque, NM
April 2, 2009

I want to know: how do you find the world’s best people? I’ve recently become borderline obsessed with trying to surround myself with the best people on the planet. If you want to live a great life, be a part of a great organization or cause, you have no choice but to do so. Steve Wozniak, Steve Jobs, Bill Gates, Warren Buffett - the list goes on and on - have ended up with the best possible people around them. Why? Nobody by themselves is great in all areas, so in order to “drift upwards”, you have to be immersed in group of people better than you. It’s impossible to drift upwards if you’re not.

But the “best people on the planet” is tricky to define, and I think most people get it wrong. Being in that group is not fully about experience, current skill-set, incredible intelligence, current wealth, popularity, a strong resume - although those can be strong indicators. The problem with measuring by those indicators alone (which many job interviews seem to focus around), is that you miss out on the people who are poised to have all of those qualities, but haven’t had the opportunity to achieve them yet.

The advantage of finding the best people on the planet before everyone else recognizes them as such, is that you actually have access to them. If you tried to surround yourself with Steve Jobs, Bill Gates, and Warren Buffett (other than by immersing yourselves in news about them), you might not be able to. But can you surround yourself today with the Steve Wozniak, Steve Jobs, Bill Gates, and Warren Buffetts of tomorrow? That’s much more likely.

You can find those super successful people of the future by looking for certain attributes, though. Even complex skills can be taught. Effective communication can be learned. Great ideas can be found. Money can be raised. But personality traits are almost impossible for anyone to truly change, and there are some that are so key to being wildly successful, that they all have to be present. If you want to surround yourself with the best people possible, here are 4 such traits that you should look for in your friends, employees, business partners, mentors, and more (for better or worse, you’re stuck with family!):

1. Inner Fire to Become The Best/Win in Their Domain
Incredibly successful people have done something that’s incredibly hard - otherwise, everyone would be incredibly successful. That means they’ve had to persevere through extremely tough times as well as in good in order to achieve their goal. So look for people who know what they love (or a few things that they love). What keeps them up at night out of excitement and passion? Bill Gates & Warren Buffett clearly wanted to win in business and money. Warren Buffett had an inner fire about business - of many sorts. Steve Wozniak, on the other hand, had an inner fire to create the best possible circuit board and computer.

What I’m not totally sure of is how to figure out what people have an inner fire about. I hope to revisit this section and add to it when I have some better ideas. And I welcome your feedback!

2. Talented in Their Domain
Talent is an obvious one - but it needs to be called out because it’s different than a skillset. Very few people can be extremely successful in their domain without some basic propensity in it.

You pinpoint talent in a domain by having an understanding in the domain, and realizing how far a person’s achievements stand out among the rest of their peers, in relation to how much time they’ve spent honing that talent. It was no doubt in anyone’s mind that Steve Jobs had a talent for persuasiveness - even before he was The Steve Jobs. Warren Buffett had a talent for money, numbers, and ratios - even before he was The Warren Buffett.

3. Quick to Figure Out, Fix, and Learn from Own Mistakes
Everyone starts out making a lot of mistakes. The only ones who can come out of that rut are the ones who seek to understand - and fix - what they’re not doing quite right. Figuring out how one could be successful otherwise is an exercise in futility, but it’s amazing how most human beings tend towards pride and saving face - and pridefulness is not something you can change about someone. One need look no further than many of the restauranteurs on Kitchen Nightmares to understand this.

Another way to think about this concept is whether or not the person aggressively, keeps trying to be qualified for “the job”. Do they keep improving, or are they satisfied with some level of accomplishment in their domain?

Yet another way to think about this, alá Warren Buffett? Someone who keeps an inner scorecard rather than an outer scorecard.

4. As Honest as Humanly Possible
If someone has all three of the prior attributes going for them, but is dishonest, they murder their success at any second, which at the end of the day makes them useless. Trust is the ally of anyone who’s going to be successful. Figuring out how honest someone is, however, just takes time. You can get a sense of their honesty by quality of their friends and peers, but you just can’t know for sure until you become friends with them.

~~~~~

Those are the four un-trainable qualities I seek out, at least, in future friends, employees, business partners, mentors, etc. I’m very curious if you know of more un-trainable qualities, so please leave them in the comments. I thoroughly enjoy opinionated, insightful commentary!

The next important and related topic for thought is: where do you find these future wildly-successful people to begin with? I don’t have a good answer for you yet - but what I can say is that while they’re randomly dispersed geographically, you probably are connected to them in closer ways than you think. Ask friends for tips, who are connected in a particular domain of interest, and who are spread across geographic regions. Meet as many people as possible, and don’t be shy to send someone a message or an email who you’re interested in getting to know! Dale Carnegie has some great tips on how to get started in that regard ;-)

Albuquerque, NM
April 2, 2009 

Warning: this is a quick and dirty post.  It’s designed to get some core ideas down and elicit insightful additions from you, the reader!

Before starting a software business, it’s important to be able to grade certain characteristics it has before you jump in - if not as a signal of whether or not to invest the time in it, then at least to set the expectations correctly.  There are so many things in this world that can still be improved by software, and so many things to get passionate about, it’s important for you to choose the right one.  But choosing the right one is hard - there are so many unknowns, among which may even be the financial model many times.  So it’s nearly impossible to analyze any idea on projected revenues or profits. 

What you can do to help estimate potential success, however, is pit your business ideas against each other, by grading them according to criteria that you can make educated guesses about.  The more experience you have in a particular area, the better your guesses will be.

The list I provide below is a few of the ways you can grade your software business ideas against one another.  Right now, it’s just a cursory list, but this page is where I will continue to add ideas of how you can score different potential ideas against one another, so you can make the educated choice about which idea to pursue.

• First, list the complete idea out into concrete deliverables, each one being something you can sell.  We’ll mostly be concerned with the first and the last.
  Example: our first deliverable is a website product that will only allow optometrists to add, remove, edit pages.  Our last deliverable will include contact lens ordering and online appointment scheduling, etc. etc. 
• How many times a day (or week) will the potential customer use the product (in its first deliverable)?
  All wildly successful webapps can be used multiple times a day, by an average user.  Google, Hotmail, YouTube, Facebook, the examples are endless! 
• How many potential people will be paying customers for the first deliverable?
  Example: our first website product targeted optometry offices, 25% of which would likely use deliverable 1 with no changes. 
• How about the last deliverable?
  Example: our last deliverable will be usable by all optometry offices with no changes, about 300,000 
• At what velocity do your first deliverable’s paying customers adopt new technology?
  Example: Optometrists don’t adopt new technology quickly
• How risk-averse are your users or customers to using (or purchasing) new, similar software in a similar domain?
  Example: Optometrists are generally risk averse, and this bleeds into website software.
• How well-connected is your market about your software’s domain?
  Example: optometrists don’t talk to each other very much, and when they do, it’s rarely about websites.  Web Designers, on the other hand, twitter to each other all the time, and they are excited to talk to each other about apps which can improve their own products/services.
• How much effort is the first deliverable?
  Example: it will take 3 developers and 1 designer 4 weeks to deliver the product
• How easy is it for your team to access the next potential customers?
  Example: in optometry, to really access potential customers, you really have to create a brand, and the only way to do so is by going to trade shows, aligning with partners, etc.  Direct (e)mailing doesn’t sell.

There will be more to this list, but that’s what we’re thinking about right now!

How do you grade your ideas against each other?

Emeryville, CA: September 16, 2008

In my experience, Ruby and Ruby on Rails has been one of the most difficult language/framework combinations to truly master .  For someone who grew up on C, C++ & Java in the majority of their training, Ruby has hugely different (and better!) ways of OO design, and the Rails framework has a lot of opinions to be understood and remembered.  As long as it’s taken to master them to the level I have - and I’m sure there’s still a long way to go - I love it and won’t be going back.

I have a sneaking suspicion that as Ruby on Rails keeps rising in popularity, there will be lots of developers stuck in the Java-style OO mentality, lots of developers who are just learning; and that’s a Very Good Thing.  It’s also a bad thing, because poor code begets other poor code, when published and viewed by others.

As ThriveSmart hires more developers - not all of them Ruby or Ruby on Rails experts - there’s a growing need to ensure that code and design strategies maintain an extremely high level of quality across different projects.  My good friend Dan and I assembled this checklist that all of our teams are expected to sign off on for each of their projects.  It’s an evolving list, but here’s a snapshot of it. 

Ruby on Rails Code Quality Checklist

1. Each controller action only calls one model method other than an initial find or new.  
     (Make custom .new or .update methods in the model with all necessary). …
2. Only one or two instance variables are shared between each controller and view. …
3. All model and variable names are both immediately obvious (to a new developer) and as short as possible without using abbreviations. …
4. All custom “finds” accessed from more than one place in the code use named_scope instead of a custom method. …
5. A .find or .find_by_ is never called in a view or view helper. …
6. There is zero custom code that duplicates functionality of a built-in function in rails. …
7. Code has been aggressively DRYed during development. …
8. All functionality used in two or more models has been turned into a library/module. …
9. All logic duplicated between two or more apps has been turned into a gemified plugin. …
10. STI is not used anywhere …
11. Every design choice should yield the most simplistic design possible for the need of users at the current time.  
      No guesses for future functionality were designed into the application. …
12. Close to full test coverage exists at the highest level of the application: on and between controller actions.  
      Coverage is highest for code used by the most number of end users. …
13. All tests pass before code is merged into a shared repository. …
14. Every fixed defect on a deployed product has tests added to prevent regression. …
15. Every plugin installed has been code reviewed. …

I certify that all of the above is true for my project.
      [Printed Name]               Signature     

Explanations

The hope is that every item on the checklist is so obviousto the more experienced Ruby on Rails developer, that it’s not worth mentioning - but that to new Ruby on Rails developers, the items on the list are non-obvious, and require some explanation.  So here goes:

Each controller action only calls one model method other than an initial find or new. Make custom .new or .update methods in the model with all necessary.

Fat models and skinny controllers  is the expected methodology of coding in Rails - but that term is too open to interpretation for my taste.  In almost all circumstances, you can actually push all of the logic into your models, so your controllers look identical to the controllers generated by script/generate - you just change the generic .new calls and .update_attributes calls to similar but custom methods in your models.  A simple example is when there’s additional logic when the attributes are updated by a particular user: @foo.update_attributes_by_user(params[:foo], current_user).

The only time extra logic should be in the controller and not in the model is if it leads to rendering a different action or redirects differently.

Only one or two instance variables are shared between each controller and view.

Instance variable hell - when a lot of instance variables are shared between a controller and a view - is easy to do in Rails.  It’s also potentially dangerous to performance, because you can end up making duplicate calls on associations unknowingly.  Instead, your controller should only manage one instance variable - and perhaps a second for the current_user.  That way, all calls to associations are loaded “on demand”, and can be instance-variable-cached in a single place.

This methodology also works out well for fragment caching, because you can check caches in views before actually loading associations.

For example, instead of having your Blog controller create an instance variable for both @post and @related_posts, just make a single method, @post, and give your Post model a related_posts method, so you can just call @post.related_posts in your views.

All model and variable names are both immediately obvious (to a new developer) and as short as possible without using abbreviations.

Naming is hard.  Particularly for developers who are immersed in an application - what’s obvious to you when you’ve loaded the entire context of the application into your brain, will not be obvious to you later or to a new set of eyes.

One of the greatest things about Ruby and Ruby on Rails is that names are short and obvious, and readable to a fresh set of eyes.  Don’t ruin this immense strength!

If you can’t think of an ingenious, clear, and short name immediately, finish coding your method, and then try to unload all the context you have while deep in coding.  Put a TODO in and rename your variable or method name at the end of the day.

All custom “finds” accessed from more than one place in the code use named_scope instead of a custom method.

If you don’t fully understand the power of named_scope , you aren’t allowed to do development for us.  Named_scope should change how you write any and all of your .find code. 

If it’s not obvious why this rule is here, you need to go back and fully understand the power  of named_scope .  Really. Chained named_scopes are the most readable way of doing any finds with conditions, so you must use them.

A .find or .find_by_ is never called in a view or view helper.

If you’re using a .find or .find_by_xyz on the base of a model in a view, there’s a 99% chance there’s a better way to do it - and you should do it.  

At the very least, you should be using a named_scope, and calling that from the base of the model.   More likely, you should be calling an association or custom method from your model (on which you can chain a named_scope).

For example, if you want to find all recent articles for listing in a view of a blog post (@post) you might have done: Articles.find(:all, :conditions => …).  You should be doing: Articles.recent (named_scope) - or even better, @post.related.recent (chained named_scope).

There is zero custom code that duplicates functionality of a built-in function in rails.

Although this is a general programming rule to live by, I see it the most with Rails.  Unlike other frameworks and languages, Ruby on Rails provides many, many helper functions for displaying things readably, and doing common tasks.  But they are typically tucked away (as they should be) into a bunch of different files - modules that are mixed in at the appropriate time.

Thankfully, the Rails code base is VERY well coded - even where it lacks documentation.  To help find methods that you can use, I suggest keeping a copy of the rails source in your text editor or IDE - and at any time, you can do a full-text search on the entire rails source.  Of course, just download the archive version from github .

Code has been aggressively DRYed during development.

The way Ruby has been designed, it’s overly easy to DRY your code continuously as you do development.  Make helpers.  Make modules. Make plugins.  

Just keep doing it.

All functionality used in two or more models has been turned into a library/module.

Perhaps the biggest advantage of Ruby over Java-style languages are mixins (modules).  Don’t ignore that - use it to it’s full advantage. 

In Java-style OO, to get shared functionality between classes, you usually have to sub-class.  This is not the case.  In Ruby, you can mixin functionality from many different modules into any class or object - even at runtime.  Understand modules well , and use them to share duplicate code between models (and controllers)!

All logic duplicated between two or more apps has been turned into a gemified plugin.  

Now that plugins can be gemified , there’s no reason not to make plugins.  They’re easy to make, and now very easy to re-use and manage across deployments.

Unlike other frameworks, Ruby on Rails plugins are extremely light-weight and easy to code.  It’s worth making a plugin, even if it’s just a 5 or 6 line module.

And most likely it makes your code easy to migrate if you move to other Ruby frameworks, like Merb.

STI is not used anywhere. At all.

I’ve seen my fair share of rails apps.  I have never seen a Rails app where using STI (Single Table Inheritance) was the correct design decision.  Ever.  I’ve seen them most often when someone is new, and thinks STI is a great way to share code.

But in rails, it’s so easy to add columns to tables, and share code between models without STI.

Instead you should be generating different models, and using a module or two to any correct logic between them.  Use common partials to share view code.  If you use STI, you will forever bind the two+ models together in ways that can be very hard to undo - a data migration is never fun.

Polymorphic associations, however, are encouraged!

Every design choice should yield the most simplistic design possible for the need of users at the current time.  
  No guesses for future functionality were designed into the application.

Another way to put this is The Rails Way.  And this paradigm is just as much for Project Managers as it is for Developers - but both types of people on a project have a responsibility to ensure that this is followed.  

Although Chapter 4 of Getting Real explains it better than I ever could - to sum it up.  If you make guesses, rather than designing to facts, invariably, some of those guesses will be wrong.  Some might be right, but any designing and development that are for wrong guesses make things more complex, harder to fix, and harder to improve.

Instead, code to what you know is true, launch early, watch users, and iterate quickly.  That’s on of the major benefits of hosted software (web apps) over distributed software (desktop apps) - so use it to its full advantage.

Close to full test coverage exists at the highest level of the application: on and between controller actions.  
  Coverage is highest for code used by the most number of end users.

Although unit tests can be important for iterating features, for most young Rails apps, models are more simplistic.  What you should make sure of is that all points of interaction for users are well tested, and stay un-broken from release to release.  

The easiest way to prioritize coverage of tests?  By the portion of your end users that will use a piece of code.

All tests pass before code is merged into a shared repository.

This should have been true at your last job or on your last project.  If it wasn’t, it is now.  

We encourage you to keep your own local repository/branches for backup purposes - that’s what git is great for.  But as soon as we have a launched product, never merge your code from your branch, into a branch that other developers use before all tests are passing.

Every fixed defect on a deployed product has tests added to prevent regression.

The worst thing you can do in this business is to have the same problem twice.  Prevent it - our clients and users will usually understand if a bug happens the first time.  Not ever, if it happens again.

Every plugin installed has been code reviewed.

Most plugins in the Ruby on Rails community are at least good, if not great.  However, the number of poorly designed plugins will increase.  Always review the actual code of the plugin.  In general, the simpler/smaller its code base is, the better.  The more well-tested it is, the better.   The easier its code is to understand, the better.  

Do you understand how it works? 
Do you understand its rough performance?

That’s it!  Please keep in mind that this is an evolving list.  It will change, especially as Ruby and Rails changes.  

Emeryville, CA: March 12, 2008

Having worked at Google and now working in my own business, I’ve noticed that some days I’m just a rockstar at getting everything done, and others I can barely get a few lines of code out, or accomplish anything on my todo list.  Of course, now that I’m in a really small business, every single day counts, for each person in the business. 

After looking back and trying to figure out what separates one day from the next, here are some commonalities I’ve noticed.  All of these are obvious with a little bit of thought, and I’m certainly not the first one to come up with these ideas.  But a reminder of them can go a long way. Also, some of these only apply when you’re in Marathon mode (like when you’re trying to be effective over the course of a year or two), and not in Sprint mode (like when you have a major, major deadline in 2 weeks).

1. Limit News Intake to twice a day, Including Google Reader & News Sites

Straight from the four hour workweek.  Let’s be real: Your minute-to-minute life isn’t affected by anything you read in your blogs unless you’re a news reporter.  Reading the news is an enjoyable way to procrastinate under the veil of being important.  I have 2 times of the day when I read news: google reader in the morning, and news in the evening.  Anything more is a distraction which lowers my effectiveness.

2. Leave Yourself a Place to Start (or: Leave work with something small broken)

Programming effectively (at least, for me) requires me to have a lot in my brain at one time - which I ‘load’ when I start, and which rapidly dissipates when I get distracted or stop.  That means that getting started and ‘into the zone’ is the hardest part.  What makes it easier to get started is if I have a simple task to complete that gets me in the zone.  

So, any time I stop (lunch, or in the evening), I intentionally break something so I can get right back and fix it - when I get back to work, I’m not only anxious to fix it, but I’m in the zone after I’m done fixing it.  

There was a famous sculptor (or ten) who, before he’d leave for the night, would smash a sizable dent into his sculpture - so in the morning, he’d know where to start.  Many programmers I know have a problem with this - but seriously.  Try it a few times, and see if it gets you up and running faster, more consistently.

3. Draw it Out & Research First

I can’t really explain it, but I’m so much more productive whenever I use a pen and paper to draw out what I need to do.  I don’t know if it gives me time to sort out all the details in my mind, or if it’s just giving me a road map so I don’t get distracted.  But paper and pen is my favorite, whether it’s a flow chart or a UI mockup.  I know others love their whiteboards.  But for some reason, doing it in OmniGraffle or PPT just doesn’t have the same effect.

Also, if I know I’m going to need some algorithms that require knowledge I don’t currently have, I spend 30 minutes researching the answers to them.  That way I don’t get distracted or have to redo anything.

4. Architect Your Perfect Distraction-Eliminating Work Environment

Unfortunately in big companies, you don’t necessarily have control over your designated workspace.  However, you can probably control your home work environment, or find an area at the office building that you can make your own.  My work environment includes:

• Big computer monitor, big desk (for when I want to work at a desk)
• A recliner chair (for when I want to work in a relaxing posture)
• Conducive Work Music (my mood is a bit different each day, but I have to know the song well, otherwise I end up listening to the words!)
• Good sound system
• Well-Lit with natural light
• Wide-open space
• Very few people (or no one) walking by
• Well ventilated, preferably with outside air
• Modern feel
• Calm pets I get along with

5. Eliminate IM during productive hours

Other people don’t usually spend the time to think whether or not something is urgent AND important when they IM you.  Chances are if they think about it for 15 seconds after their initial impulse to IM you, most IMs can be done over email, and can be answered in non-productive hours.

The same goes for you.  Before you ask someone on IM for something, see if it’s actually urgent and important.  If it’s not, send them an email and ask for the answer by the end of the day, or week.  Then you won’t get distracted, either.

6. Only Respond to Emergency Emails during productive hours

This goes hand in hand with the tip above.  You can lose a few hours just in the context switching between programming and doing other things.  If you can, make a label, with a rule to filter out emergency emails and bring them to your attention.  Otherwise, answer all other types of emails after productive hours.

7. Limit Meetings to once a week (or less)!

I saw this at the big company I worked at the most, but if your team runs effectively, and is an effective size, you should only have to have meetings once a week, to get everyone back on the same track.  If you have meetings more than once a week, there’s most likely a serious problem with how your project is managed, or how your team is structured.

In our small team, we meet once a week to prioritize the next 3 features being built - mostly because each feature takes a week to build (or two).

8. Get out, and be social every 2 weeks

It might just be me, but I think it’s universal - I need human contact other than my work friends at least every two weeks, and go somewhere other than home and work.  Otherwise something inside me starts to get distracted easily.  I have a need to talk about myself to friends, and listen to my friends; and doing so regularly keeps me from getting too antsy & feeing couped up.  I’m sure the rest of you experience some similar phenomenon, perhaps on a different timescale.  Tailor your routine to your own emotional needs!

And on a related note, even playing video games on weekends doesn’t really keep me from feeling antsy - I really have to leave my normal environment and interact with other people.

9. Take evenings off most days

This is worse at a startup - the inertia of working 24x7, as well as anxiety (or being anxious and excited) can keep you glued to doing work for far too long.  I’ve found that if I take evenings off, I’m more likely to need less sleep, and less likely to get caught up in reading the news or getting distracted on IM.  Each evening, unless there’s a problem, I’ll take at least a few hours to enjoy the companionship of my girlfriend, pets, some TV, or a book - and just let my brain unwind and refresh.  I think you’ll find your creativity improve, too.

10. Get 20 minutes of exercise in the morning, 3 times a week - but use that time!

I don’t know about you, but I used to think exercise was a complete waste of time - but I knew it was important.  However, what I’ve found is that when I exercise regularly, I need less sleep - which is crucial in a startup!  I also bring along a great podcast I can listen to on an iPod.  Typically they’re a perfect length - 30-40 minutes, and I can get in my exercise while I’m getting a new perspective on things.

I suggest: Stanford Technology Ventures Podcasts (my favorite),  Ruby on Rails Envy (and other technical podcasts)

Bonus. Make/Use Better Tools

This isn’t concrete enough to be an actual method (plus, 11 just isn’t a good number), but I’ve found it incredibly valuable. 

The best time savers from a coding perspective for ThriveSmart is when we’ve made plugins out of repetitive code - or when we’ve found plugins for things we thought we’d have to do ourselves.   Take a look: can you write any tools that would automate parts of your life or drudge tasks?  Perhaps you can even outsource parts of your life, like in 4 hour workweek.  Just something to revisit every few months, to see if you can work smarter, instead of harder! 

Berkeley, CA: November 18, 2007

Jenn, Dan, and I just got back from our Monterey Symposium optometry conference. It was an absolute blast! What was most interesting for me was that we really had to sell our website builder to prospects and potential partners to a large audience for the first time. Watching other exhibitors and analyzing our own behavior brought back many memories from Google when I worked with some amazing sales (and business development) people - three of whom were named Andy (not really). As I watched Jenn , Dan , myself , and others, I started to notice a real differences in how they approached selling to prospective and existing clients. Everyone had something that worked for them (probably), but they tended to fall into spectrum of two main strategies, from what I noticed. And these two strategies were personified so well, and in such contrast in two of the Andys I was lucky enough to work with at Google. Andy One was what I’ll call a connection/relationship-first sales person, whereas Andy Two was what I’m calling a process/product-first sales person. I personally fall towards Andy Two, but I wish I fell more towards Andy One. I’ll tell you more about what I mean.

Connection/Relationship-First Salesperson

Andy One worked purely on his connection and relationship to his prospects - it was amazing. He almost never talked about the actual product he was selling. He wouldn’t worry about whether or not the projector was remembered.What he would spend his energy on was going to conferences and saying hi to all of his friends that he knew. He knew what they did, he would play golf with them. Andy One would go to the casino and stay late until he left with the last person there. He would know all their kids names and what year they were in school (roughly).What was most surprising to me is that up until a handshake agreement was made, the actual product he was selling or deal terms he was making was an afterthought. Instead what would happen is he would ask them for a lunch or dinner meeting (or just drinks or a round of golf), and after he asked them how they were doing and what they were working on, they would ask him the same thing. And when it came around to asking him what he was working on, he would casually mention it, mention how passionate he was about it, and they would want to join him.Of course, after the handshake was made, Andy would follow up on the deals and the due diligence, but the actual selling just seemed like a piece of cake. Even more importantly, he could bring his contacts with him from project to project, and company to company (if he hadn’t retired at 33 or something like that ;-)).

Process/Product-First Salesperson

Andy Two was at the other end of the spectrum. He was also really effective at closing deals, but in a completely different way. Andy Two was always about refining his process and refining his pitch. He’d have a list of clients neatly organized with a status on each of them. When he’d go to a potential partner or client, there would be some small talk at the beginning about how things were going - usually work related - and when the meeting really started he was all about making a solid presentation that touched all the points, and explained the product and the benefits really well.What Andy Two was really incredible at, however, was follow-up. One way or another he was always so organized that a warm lead wouldn’t go more than a week and a half without a reminder email or a how-are-you phone call. His pitches were very convincing from a product point of view (and always correct, never overly salesy), and with aggressive follow up, it was a winning combination.Andy Two did end up forming relationships with his clients and partners, but it was always a result of focusing on the product and offer, rather than the other way around. If a client offered to go out for beers afterwards, he wouldn’t always partake, as I recall, whereas I doubt Andy One would have turned it down. Simply different styles, but both are effective.

Me (Engineer) Salesperson, And the Other Andy

In case you’re wondering, Andy Three fell somewhere in between. He was very cool, and probably had a personal style more similar to Andy One (and he wouldn’t turn down a good beer!). However, he still was a little more process driven like Andy Two. And most people probably do fit between these category.

As for me, I’m still more like Andy Two, but am trying to be more like Andy One. The thing is, I’m an engineer by training, and have been for a long time - my instinct is to cut to the chase, cut the fluff, and work through the details. Perhaps I’m also a bit excited about the actual product, because I helped build it. But unless I work my buns off at aggressive follow-up, this is not the easiest strategy.

Of Course Relationships - But Why?

Instead, I need to focus on building relationships first - and I think most engineers probably have to work, and work, and work on this. There are a couple reasons relationships first is so powerful. It’s been said so much it’s a cliche, but it’s really true. When someone buys something from you, it’s usually because they’re buying you - not the product; and this is especially true in partnerships.Nobody can completely understand a product and its implications before they buy it and start using it; so most of the time when they buy from you or close a deal with you, they’re just making an educated guess. And that guess is based on a combination of the reputation of your company (which they might not even know), and how much they trust you. And where does trust come from?It comes from them understanding your character. And that will not completely come through when you’re only talking about your product. It will come through, however, when you build a relationship with them.

PS - They’re probably not as passionate as you about what your product does.

Another reason that relationships are so important, is because chances are, your prospective partner or client probably isn’t nearly as excited about your product like you are. You’re lucky if you’re in an industry where they are, but it’s not very likely. If they were as passionate as you, they would be working for the same company or one of your competitors.For example, optometrists do want a website and think they’re a great idea, but at the end of the day it’s the care they provide to their patients that they’re super passionate about. Instead, they rely on who they trust to be passionate about websites for them.

What you can do if you’re like me

To be up front, my end goal is simply to close as many win-win deals and customers with as little effort as possible. And when I analyze which part of the spectrum to be on to accomplish this, I have to be as close as possible to Andy One. But of course, as of now that goes against my instincts a bit. There are a few things I know about that I can try to do to change - although I welcome all of your ideas on this in the comments. The first thing is to fight the urge to be shy when saying hi to someone new. Be bold! Be daring. It’s either you, or them. And you’re the one with something at stake.Second, is smile and laugh a lot. Perhaps it’s personal style, but a smile can disarm people with their guard up more easily than anything else. And third, and lastly, ask them three questions before you tell them more than a sentence about your product. Dale Carnegie said the best way to seem interesting and intelligent to people, is to get them talking about themselves (and saying their name) - because people’s favorite word is their own name, and people’s favorite topic is something having to do with them and their passions. And if you get them talking about themselves, they’ll think you’re the most interesting person they’ve met in awhile - and along with that, comes trust.That’s all I’ve got for now - I welcome your ideas too, as always. I did notice that when Jenn started to talk to the optometrists at our conference about patient care and how they got their start in optometry, they opened up. And naturally they started to ask what we did, what our product was. And *then* they learned how cool it was - precisely in that order.

Berkeley, CA: November 13, 2007

I’ve been thinking for a long time which is more powerful: having a cyclical network behind your product versus creating a platform for other companies to develop on top of.

Well it turns out they are both incredibly powerful and necessary for a successful product — but you always need to build a powerful, cyclical network first and then-and only then-should you spend effort building a platform.

Let me quickly explain the difference. A cyclical network is the virtuous circle of a strong ecosystem where new users are almost forced to use the product because everyone else is, and for the same reason existing users are kept from switching. On the other hand a platform is the ability for 3rd party businesses to adapt and expand the functionality of the product to specialized uses that they would otherwise not build themselves, or build as well.

There are strong examples of both cases being executed independently. Apple has created this with the iPod and iTunes. The more iPods that sell, the more record and video businesses will sign with iTunes, which again drives more iPod sales. This in turn drives more production of quality iPod accessories, which also keeps ipod’s at the top when people decide what music player to buy.

Google did the same with their ad network. More advertisers meant more publishers, and around the cycle goes. Then ad agencies start providing tuned creatives for google so more advertisers join. Blog companies offer google ads on their sites meaning more publishers.

The pure platform example is a bit harder for me because of the space I’m in, but sap comes to mind. There is just no way they would ever build the products their customers have built on sap, but it has been extremely powerful for their company.

What this Means for Us

So what does this mean for the entrepreneur? You need to build both: the network keeps driving the core business and protects your lead. Having a platform keeps niche competitors from sneaking up behind you. And they both drive each other . If you have a strong network and a good platform, people will keep joining and developing for you.

Take Google’s ad network: it has an incredible ecosystem of advertisers, publishers, and ad agencies. However their contextual targeting engine doesn’t work for every scenario, particularly in social networks. Imagine what would happen if they created a platform for companies who can target ads to their users better than them - not many other companies want to spend the effort to create an entire ecosystem of advertisers themselves. You might see places like Facebook and LinkedIn using Google Ads, building an even stronger ecosystem for Google. Instead, what you have now is places like Facebook building their own ad platforms AND building their own network and ecosystems - and they might become a big competitor to Google.

What IS important is the order that you build them in. In fact, it’s almost impossible to get people to develop on the platform you’ve built unless you’ve built a network first. Developers and 3rd parties always have too much to do, like anyone else. They’re only going to pick and choose less risky, easy, and high growth opportunities. And they find those projects on platforms that are backed by an incredibly strong ecosystem. That’s a prime reason that the Facebook platform is so popular: the real prospect of quickly distributing an application that they make to millions of users. If your platform can be perceived as risky, difficult, with limited opportunities for usage, developers won’t want your platform.

So build your network and ecosystem! Then build a platform to prevent real competition.