Adios. Aloha.

Today is my last day at Help Scout. It’s been a wonderful 2.5 years!

I’ve accomplished all of the things that I set out to accomplish when I first joined the company. Everything (the design team, the leadership team, the brand, the product, the company) is in a better spot, than when I first arrived.

I want to thank Nick, Jared, and Denny for allowing me to be a part of something so special. Help Scout has blessed me in so many ways.

I’ve learned so much in my time there, but it’s time for something new…


Monday is my first official day at Wildbit! I’m so excited! They’re a fun little company that offers a number of great products, including Postmark and Beanstalk.

I’ve admired Wildbit from a distance for over 10 years now! They’ve got an amazing culture, a small team (even though they’ve been in business for 17 years), a number of wonderful products, and loads of passionate users.

I’m bubbling with excitement right now… I can’t wait!


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Test Every Assumption

Let’s say I’m at work and we’re discussing a potential change that we’re thinking about making to our product (or even the marketing site). If the phrase “best practice” or “common knowledge” get’s tossed out, a little red flag always pops up in my head.

“common knowledge” is just an unproven assumption

It’s a mirage I tell you!

Just because a technique supposedly worked well some place else does not mean that it will work well for your app. Time and again I’ve seen instances where after testing something that felt like a “sure fire win”, we discovered that not only is it NOT a sure thing, it results in a shocking loss of signups or revenue.

But this is a no brainer! It’s obvious!


Test it. You’ll see. There’s generally a 50% chance that you’re wrong.

I get it… You’ve got a huge backlog of stuff that needs to get done. Taking the time to set up an A/B test for this feels like a big waste of time—time you could be spending on your big list of todo’s.

Is it much easier to side with the assumption that “loads of other apps do it this way”, push a deploy out the door, and move on to something else?

Of course.

But don’t be fooled

In what area of your life has the easy route ever been the best route? 😉 It’s no different here.

If a change that you’re making has the potential to affect any number that you care about (user happiness, signups, revenue, retention), you should find the time to test it.

There’s no safety in assumptions

In the end, it’s always best to test all “best practice” or “common knowledge”.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Complete Novice to Full-time Product Designer in 1-2 Years

In this post, I’ll talk about the path that I would take to go from a complete novice, to a full-time product designer—all within a year or two—and land a job that pays at least $90,000/yr.

A few disclaimers:

  1. This isn’t a life hack article. Below, you won’t find a list of hacks, but a list of real work that must commit to.
  2. I’m not trying to sell you anything. This post is not the intro to some paid course that I’m trying to up-sell you on. I don’t want/need anything from you in return. (That said, if you do end up becoming a product designer, I’d love to hear your story).
  3. The path outlined below offers the fastest way (that I know of), for anyone to change careers, and become a product designer. Follow these steps, and you’ll save a great deal of time, and money with your transition.
  4. This is obviously not the only path, but this is the path I would take if I were starting over from scratch, with zero experience as a designer.
  5. Paying for education to become a product designer is NEVER something that I’d recommend. This statement will likely offend some (especially those who have paid for design school), or those who sell expensive design courses, but please trust me when I say that you do not need a degree to become a product designer. We’ll talk about this in more detail below.

Why listen to me?

In short: I’m a seasoned designer. I’ve worked at a handful of successful startups. My experience runs the gamut:

  • I’ve worked as a design team of one.
  • I’ve been a full-time contributor within a larger team.
  • I’ve been a part-time manager, part-time contributor.
  • I’ve also been a full-time creative director, managing up to 34 other designers.

In total, I’ve been a designer in various positions, at various startups for over 18 years.

What are the responsibilities of a product designer?

Throughout any given day, a product designers responsibilities might include:

  • The need to understand who’s using your product
  • The need to understand what users are trying to do.
  • The need to understand what scenarios the UI will handle
  • The concept brainstorming stage
  • The concept fleshing out stage
  • Interactive prototyping
  • Usability testing
  • Feedback throughout the design process
  • Reviewing PR’s
  • Writing front-end code
  • Writing back-end code
  • Optimizing for speed
  • Visual design
  • UI design
  • UX design
  • Print design
  • Crafting the layout
  • Responsiveness
  • Writing product copy
  • Writing marketing copy
  • Typography
  • Colors
  • Page hierarchy
  • Interactions
  • Motion
  • Growth
  • A/B testing
  • White space
  • Adding personality
  • Telling a story
  • Communicating various feedback states
  • Accounting for error states
  • Accessibility
  • Small delightful details
  • Internationalization
  • Retina considerations
  • Writing specs
  • Decisions vs. options
  • QA
  • Browser testing
  • Device testing
  • Brand advocacy

If you’ve stuck around this far, you’re probably thinking,

Wait… What!

That list is daunting. How on earth am I ever expected to learn all of that in a year or two?

This must just be a link-bait article… This Dave Martin guy is full of crap.

Just hang tight. I promise you, we’re getting to the good stuff!

It’s all about focused learning, and then specialization

The secret is to be strategic about what you learn first, and where you focus your time. Will you know half of the stuff in the list above when you land your first job? Nope. But don’t let that deter you.

Throughout the rest of this post, I’ll show you in detail, how you can get in the door of a startup as a Jr. designer. Once you’ve landed a job, you can then learn the rest of this stuff on the job (i.e. rather than pay to try and learn this stuff, I’m going to show you how you can get paid to learn most of this stuff).

Below, I’ll outline a step-by-step path you can take to short-circuit the system and land a product designer job as quickly as possible.

How do you get there?

Here’s what I suggest:

  1. Keep your existing job
  2. Start with just three basic skills
  3. Start waking up early to work on side projects
  4. Land your first jr. design job
  5. Choose a specialty
  6. Transition to a product designer role

Let’s talk about each one in detail:

1) Keep your existing job

Your current job—no matter how much it sucks—is your lifeline. Keeping your existing job buys you all the time you need to learn some new skills. If you’re just starting your career switch—with zero experience, and no portfolio—the chances of you landing even a jr. design job are close to zero.

But don’t let that deter you either!

The demand for product designers has never been greater

Don’t take my word for it. Have a quick peek for yourself:

Dribbble jobs
Linkedin jobs

At this point, you’re semi-convinced. You’re thinking to yourself:

Okay, I’m up for this grand career change, I guess I need to go back to school, right?


We’ve been trained as a society to think:

I’m starting a new career, I guess I’ve got to go back to school.

But if you want to become a product designer, it couldn’t be farther from the truth.

Side note: I’ve got a whole separate rant on this topic if you’d like to hear more of my thoughts.

Your next step is to try and learn a few skills.

2) Start with just three basic skills

Forget about that big long list of skills that I shared with you above. At this point, it’s irrelevant.

The only three skills that you need to focus on are:

– SketchApp

These three skills will form the foundation of your new design career.

There are loads of free resources out there to help you learn all three of these skills. Here are just a few examples:

Needless to say, you shouldn’t have to spend a dime to learn these three skills.

3) Start waking up early to work on side projects

The best way to learn how to be a designer is to practice, and the best way to practice is to work on side projects.

I don’t care what stage of your design career you’re in, I’m a firm believer that you should alway work on side projects.

Working on side projects is also the easiest way to start building a portfolio of work that you can share when you apply to your first design job.

But my life is already too busy, I don’t have time for side projects

Truth be told, I don’t know your circumstances, but I’m guessing that there is a block of time that you can carve out, if you just choose to prioritize it.

Personally, I’ve got a full-time, and a family with 3 young kids. I have every excuse to say that I don’t have enough time. But for the past year or so I’ve been in the habit of waking up between 3-5am each morning.

I typically work on my own side projects for a couple of hours before starting work (you can see a list of my side projects in the left nav of this blog). I used to do the late night thing, but the early morning thing works really well for me.

What on earth can I accomplish in just 2 hours per day?

Let’s take a look:

Say you worked on a side project for 2 hours every weekday, and took the weekends off.

Well, that’s:

  • 10 hrs in one week
  • 520 hrs in a year (or a total of thirteen 40 hr work weeks)
  • 2600 hrs in 5 years (or a total of sixty five 40 hr work weeks!) That’s over a years worth of work!

That’s insane. If you were able to commit to building side projects just 2 hours per day, 5 day per week for 5 years, what could you accomplish?

A whole heck of a lot, that’s what!

What side projects should I work on?

That’s the cool thing. It can be whatever you want. Work on stuff that interests you. Work on tiny projects. Work on big projects. But work on projects that help you polish up new skills, and expand your portfolio.

I’m entirely self taught. I studied Chemistry in college. The vast majority of new skills that I’ve picked up have come as the result of something that I needed to learn for a side project.

Once you have a small portfolio of side projects, and after you’ve started feeling comfortable with some beginner HTML/CSS, and Sketch skills, it’s time to look for your first design role.

4) Land your first jr. design job

For your very first design job you can probably expect to pull down anywhere between $45-75K/yr.

There are two things that you can do to help yourself stand out when applying for any job:

1) Go above and beyond with your application. The more effort you put into it, the better chance you’ll have of standing out from the rest of the applicants.

2) The other thing that can drastically increase your chances is to know someone who can give you a positive referral. Sometimes you have to get creative, but a positive review from someone who already works at a company, or from someone who knows the hiring manager can go a long way towards at least getting you an interview.

What do design managers look for in applicants?

In all of my time managing designers, I never once cared about education. That may come as a shocker, but when reviewing resumes, I wouldn’t even look at the education section of peoples resumes. Honest! The one thing that matters more than anything else is your portfolio. And what’s the best way to build a portfolio from scratch?

Side Projects!!!

Great. You’re getting the hang of this. 😉

Now that you’ve got your first design job, it’s time to figure out where you want to shine!

5) Choose a specialty

After you’ve landed your first jr. design position, you’ll rapidly start learning a bunch of new things.

The key to making the leap from a jr. design role to a product design role is to avoid being a generalist. It’s time to focus and get really good at one specific skill.

There are loads of specialties to choose from. It’s really up to you on which you choose. But here are some of the ones with the highest demand:

  • Visual design – If you decide to become a rock solid visual designer, you’ll always have a good paying job, and you’ll alway be in high demand
  • Growth designer – Most designers want nothing to do with data informed design. As such, you can do very well for yourself making this your specialty.
  • Interaction design – Animation and interaction design are here to stay, and they are in high demand
  • Design manager – If you’re an extrovert, and you thrive in an environment where you’re helping other designers shine, you’ll always be able to find a great job
  • User research – A lot of startups preach being user focused, but when the rubber hits the road, and features just need to ship (yesterday), this is often one of the first things that gets put on the back burner. If you can learn to excel at speaking with users, and interpreting their needs, you’ll do well here.
  • Design engineer – If you love the code side of things, you can do well by picking up JavaScript and being a bit of a cross between a designer, and a front-end engineer.

Again, there are a ton of other areas where you could specialize, but these are just a few of the areas that I’d recommend looking first.

6) Transition to a product designer role

You’re almost there!

Frankly at this point, you probably no longer need my help. 😛

If you’ve made it this far, congrats! What an exciting time!

Now is the point where you can start being picky about the companies you choose to join.

From this point on you can expect to make anywhere between $75k/yr, all the way up to $180k/yr depending on where you live, and the skills that you bring to the table.

I hope you found this article helpful. If you did, please share the love via the social links below. 😻


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Laravel + MongoDB (via locally

I’m working on a new side project called Howdy (I’ll be sharing more about this project in the coming months).

A couple of the technical requirements that I set for this project were to learn some new technologies along the way.

I’d never built anything with Laravel prior to this project. I had never used Vue.js, or MongoDB either. I wanted to utilize all three of them for this project.

Two weekends ago I set out to get MongoDB working with Laravel locally. I decided to use mLab to host my MongoDB database remotely. I figured it would be pretty straight forward.

Boy was I wrong! 😛

It took me a solid 6 hours to get everything working. As a result, I figured I’d save my future self the trouble of having to ever go through that pain again, and I decided to jot down some notes:

Step 1) Set up Laravel, and your mLab account

I’m not going to walk through either of these – they’re pretty self explanatory.

Step 2) SSH into your local server

I use Homestead with vagrant up & vagrant ssh instead of homestead up & homestead ssh. I feel like there is a difference, but I may be wrong.

Set up your MongoDB Driver

The next few instructions come directly from this article, but I’m just going to repeat them here. You’ll run each of these in your SSH shell:

Step 3) Import the public key used by the package management system

sudo apt-key adv --keyserver hkp:// --recv 2930ADAE8CAF5059EE73BB4B58712A2291FA4AD5

Step 4) Create a list file for MongoDB on Ubuntu 16.04

echo "deb [ arch=amd64,arm64 ] xenial/mongodb-org/3.6 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.6.list

Step 5) Reload local package database

sudo apt-get update

Step 6) Install the latest stable version of MongoDB

sudo apt-get install -y mongodb-org

Step 7) Pin a specific version of MongoDB

Run each of these in your command line:

echo "mongodb-org hold" | sudo dpkg --set-selections
echo "mongodb-org-server hold" | sudo dpkg --set-selections
echo "mongodb-org-shell hold" | sudo dpkg --set-selections
echo "mongodb-org-mongos hold" | sudo dpkg --set-selections
echo "mongodb-org-tools hold" | sudo dpkg --set-selections

Step 8) Start MongoDB

sudo service mongod start

Technically you could just use the mLab Data API to connect, but the native MongoDB driver which you just set up will be much more performant & secure.

Set up Moloquent

Step 9) Import Moloquent

Moloquent is a MongoDB based Eloquent model and Query builder for Laravel. You can import it with composer:

composer require jenssegers/mongodb

You’ll also need to add the following service provider to config/app.php within Laravel:


Update PHP internals

The following code is borrowed from this shell script, but updated for PHP 7.2:

Step 10) Fix pecl errors list

sudo sed -i -e 's/-C -n -q/-C -q/g' `which pecl`;

Step 11) Install OpenSSl Libraries

sudo apt-get install -y autoconf g++ make openssl libssl-dev libcurl4-openssl-dev;
sudo apt-get install -y libcurl4-openssl-dev pkg-config;
sudo apt-get install -y libsasl2-dev;

Step 12) Install PHP7 mongoDb extension

sudo pecl install mongodb;

Step 13) Add extension to your php.ini file

sudo touch /etc/php/7.2/mods-available/mongodb.ini
sudo echo "; configuration for php mongo module\n; priority=30\" >> /etc/php/7.2/mods-available/mongodb.ini
sudo ln -s /etc/php/7.2/mods-available/mongodb.ini 30-mongodb.ini

Step 14) Add the following to /etc/systemd/system/mongodb.service

Description=High-performance, schema-free document-oriented database

ExecStart=/usr/bin/mongod --quiet --config /etc/mongod.conf


Step 15) Enable Mongo

sudo systemctl start mongodb
sudo systemctl status mongodb
sudo systemctl enable mongodb

Step 16) Restart Nginx & PHP fpm

sudo service nginx restart && sudo service php7.2-fpm restart

Update your Laravel files

Step 17) Add a new database config connection

'mongodb' => array(
            'driver'   => 'mongodb',
            'host'     => env('MONGODB_HOST'),
            'port'     => env('MONGODB_PORT'),
            'username' => env('MONGODB_USERNAME'),
            'password' => env('MONGODB_PASSWORD'),
            'database' => env('MONGODB_DATABASE'),
            'options' => [
                'database' =>  env('MONGODB_DATABASE') // sets the authentication database required by mongo 3

Be sure to also update your .env file:

Step 18) Add a new route to web.php

Route::get('/mongo/', 'MongoController@index');

Step 19) Add your controller

namespace App\Http\Controllers;

use App\Mongo;

class MongoController extends Controller
    public function index() {

Step 20) Add your Mongo model

namespace App;

use Jenssegers\Mongodb\Eloquent\Model as Eloquent;

class Mongo extends Eloquent
    protected $collection = 'users';
    protected $connection = 'mongodb';

    public function scopeTestCall()
    	$user = new Mongo;
	    $user->name = 'Dave';

And that should do it!

Hope that ends up being helpful to someone else who is in the same boat! 😘


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Test Your Designs

Every public facing design you push live – which has the potential to affect core metrics – should be A/B tested. Period.

But, why?

A couple of reasons:

  • Data helps you make informed decisions.
  • You test to learn. You’ll find out what works, and what doesn’t. You can then share what you’ve learned with others, and apply what you’ve learned to future hypotheses.
  • As much as you’d like to think that you can predict success, humans are terrible at it. There are no exceptions to this statement. That’s not to say that you don’t have a wealth of knowledge and experience that you can leverage. You’re always going to be fairly confident that each test you run will lead to an increase in your core metrics (else why would you run the test in the first place). But just understand up front that half of the designs you release are going to be a bust. That’s just the nature of the game, and if you’re not testing, you won’t know which half.
  • If you launch 6 new features in a month, and as a result, a month later you start to see a slump in your core metrics, which of the 6 features do you attribute the slump to? Or is it something else completely? If you don’t test everything, you’ll be in the dark.

While testing may seem burdensome (and perhaps pointless), I promise that as you start doing it, it will get easier. Eventually, you’ll be able to launch tests in a matter of minutes, and you’ll begin to see with absolute certainty what is working, and what isn’t. It actually becomes very addicting, and can be very fun.

Again, by all means, please leverage your instinct and your experience as a designer to come up with the best design possible. But then please test each design, as a safety mechanism to make sure your assumptions were correct.

If the test succeeds, celebrate! Great job.

If the test fails, celebrate! You just learned something new about what doesn’t work, and you avoided launching it to your users! Now share what you learned and use your new found knowledge to keep iterating.

The important bits

Eliminate ego – In order for any of this to work, you’ve got to drop your ego. You’re going to instinctively want to mask every test you run as winning in some way. Don’t do it. Just know that 50% of your designs are going to be flops, and less than 5% of your designs are going to be major improvements.

Get in the habit of testing everything – When you launch designs without measuring them, you learn very little about which designs work and which don’t. That’s a shame, and a waste of your time/resources.

Focus on learning – Whether a test is a success or a failure is unimportant. The important part is that you learn something new with every design you ship, and that you keep on iterating.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Embrace Process, Avoid Ego

This chart shows the level of “process” a typical designer will incorporate into their designs over time.

As a designer, you’ll start off with very little process. (beginning of the wavy line)

Over time, you’ll pick up some process here and there, mostly out of necessity (that’s that first hump).

Then, after you’ve got some experience under your belt, you’ll almost certainly start abandoning process (what I call “the slump”).

This pattern happens like clockwork. The actual timeline may differ from designer to designer, but I see the same pattern all the time.

So… what exactly is “the slump”, what causes it, and what can you do to avoid it?

The Slump

The slump is a naturally occurring phenomenon that I see in most, if not all designers. It almost always creeps in soon after you start getting comfortable with your craft. It’s a subtle thing. Probably something you won’t have even recognized in yourself until someone calls you out on it.

It’s a deterioration of design process.

  • It’s an “Ive been doing this a while now, I’m a good designer, I know what the user needs” false narrative.
  • It’s starting a new design project and going with the first idea that comes to you, instead of first spending time to sketch out a bunch of ideas.
  • It’s jumping straight to pixel perfect mockups, or straight to code without putting much thought into who the design is for, and what they’re trying to accomplish.

It’s laziness, and it’s driven by ego.

As your design skills increase, your ego will inflate along with it. If you produce good work, your ego will constantly be stroked. Likes on Dribbble, positive comments at work, from friends, or from clients all add to the problem.

An inflated ego leads you to believe that you can do no wrong. That you instinctively know what is best for your users. That you can skip all of that boring process, and jump straight to later stages of the design process.

But unfortunately your ego is wrong.

How to avoid The Slump

Great designers eventually recognize the power of process in their designs, and pull out of it.

It’s not easy. It means that you’ve got to admit that you don’t have all of the answers. You’ve got to admit that you don’t know what is best for your users. You’ve got to deflate your ego.

“But process just stifles creativity” you might say

Quite the opposite actually. Process frees you. It allows you to consistently create great designs.

In an interview, Steve Jobs once said:

Making insanely great products has a lot to do with THE PROCESS of making that product.

I wholeheartedly agree.

If you’re new to design, why not just bypass The Slump altogether. You can do this by learning to embracing process early on, and by not allowing your ego to get in the way.

If you’re an old-timer, and you find yourself in the slump, no worries. Now is the time to change. Decide today that you’ll no longer be held back by your ego.

Now is the time to drop your ego. Do this, and you’ll be well on your way to great designs.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

“Creativity Inc.” notes

“Creativity Inc” is a book that I absolutely adore. It’s written by Ed Catmull, president of Pixar and Disney animation. I highly recommend grabbing a copy. Here are a few of my favorite highlights:


  • What makes Pixar special is that we acknowledge we will always have problems, many of them hidden from our view; that we work hard to uncover these problems, even if doing so means making ourselves uncomfortable; and that, when we come across a problem, we marshal all our energies to solve it.


  • Ultimately what we are after is authenticity.
  • Originality is fragile. And, in its first moments, it’s often far from pretty. I call early mockups of our films “ugly babies”. Our job is to protect our babies from being judged too quickly. Our job is to protect the new.
  • The chaotic nature of the creative process needs to be chaotic. If we put too much structure on it, we will kill it.
  • In order for a period of greatness to emerge, there must be phases of not-so-greatness.
  • Ideas come from people. Therefore, people are more important than ideas. Find, develop, and support good people, and they in turn will find, develop, and own good ideas.
  • Since everyone at Pixar shows incomplete work, and everyone is free to make suggestions the embarrassment goes away. Once the embarrassment goes away, people become more creative.

Candid feedback

  • The key is to look at the viewpoints being offered, in any successful feedback group, as additive, not competitive. A competitive approach measures other ideas against your own, turning the discussion into a debate to be won or lost. An additive approach, on the other hand, starts with the understanding that each participant contributes something.
  • Candor could not be more crucial to our creative process. Why? Because early on, all of our movies suck. That’s a blunt assessment, I know, but I make a point of repeating it often.
  • We are true believers in the power of bracing candid feedback and the iterative process — reworking, reworking, and reworking again, until a flawed story finds it’s throughline or hollow character finds its soul.
  • Candor must override hierarchy for a any creative company to succeed in the long-term.
  • Candor isn’t cruel. It does not destroy. On the contrary, any successful feedback system is built on empathy, on the idea that we are all in this together.
  • Seek out people who are willing to level with you, and when you find them, hold them close.

Company Structure

  • When it comes to creative inspiration, job titles and hierarchy are meaningless… Unhindered communication is key.
  • The responsibility for finding and fixing problems should be assigned to every employee. You don’t have to ask permission to take responsibility.
  • If the crew is confused, then the leaders are too.
  • If we allow more people to solve problems without permission, and if we tolerate and don’t vilify their mistakes, then we enable a much larger set of problems to be addressed.

Fear and Failure

  • Mistakes aren’t a necessary evil. They aren’t evil at all. They are an inevitable consequence of doing something new.
  • The antidote for fear is trust.
  • Experiments are fact-finding missions that, over time, inch scientist towards greater understanding. That means any outcome is a good outcome, because it yields new information.
  • While experimentation is scary to many, I would argue that we should be far more terrified of the opposite approach. Being too risk-averse causes many companies to stop innovating and to reject new ideas, which is the first step on the path to irrelevance.
  • Fear of change, innate, stubborn, and resistant to reason, is a powerful force. In many ways, it reminds me of musical chairs: we cling as long as possible to the perceived “safe place” that we are ready know, refusing to loosen our grip until we feel sure another safe place awaits.
  • Deep down, even though we might wish it weren’t true: change is going to happen, whether we like it or not.


  • My job as a manager is to create a fertile environment, keep it healthy, and watch for the things that undermined it.
  • I believe that managers must loosen the controls, not tighten them. They must accept risk; they must trust the people they work with and strive to clear the path for them; and always, they must pay attention to and engage with anything that creates fear.
  • In many organizations, managers tend to err on the side of secrecy, keeping things hidden from employees. I believe this is the wrong instinct.
  • Good leaders don’t dictate from on high. They reach out, they listen, they wrangle, coax, and cajole.


At Pixar they’ll frequently bring a director (and his or her in progress film) in with a group of other experienced storytellers. They call this a braintrust. The purpose of the braintrust is not to tell the director what to do, but to highlight areas that may be weak, and to spark ideas for moving forward.

  • To understand what the braintrust does and why it is so crucial to Pixar, you have to start with the basic truth: people who take on complicated creative projects become lost at some point in the process.
  • The braintrust has no authority. This is crucial. The director does not have to follow any of the specific suggestions given. Braintrust meetings are not top-down, do-this-or-else affairs.
  • The braintrust sets the tone for everything we do.
  • The process of coming to clarity takes patience and candor.
  • Notably, participants do not prescribe how to fix the problems they diagnose. They test weak points, they make suggestions, but it is up to the director to settle on a path forward.
  • Moreover, we don’t want the braintrust to solve the directors problem because we believe that, in all likelihood, our solution won’t be as good as the one the director and his or her creative team comes up with.
  • Each of the braintrust participants focus on the film at hand and not on some hidden personal agenda. They are not motivated by the kinds of things — getting credit for an idea, pleasing their supervisors, winning a point just to say you did — that too often lurk beneath the surface of work related interactions. The film itself, not the filmmaker, is under the microscope.
  • The most important characteristic was an ability to analyze the emotional beats of the movie without any of its members themselves getting emotional or defensive.
  • To make a great film, it’s makers must pivot, at some point, from creating the story for themselves to creating it for others. The braintrust provides that pivot and it is necessarily painful.
  • Even the most experienced braintrust can’t help people who don’t understand it’s philosophies, who refuse to hear criticism without getting defensive, or who don’t have the talent to digest feedback, reset, and start again.

Loved, loved, loved this book. I cannot recommend it highly enough.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Avoid Bandwagon Wisdom

Bandwagon Wisdom
Strongly held, one-sided opinions on complex issues, often openly communicated with very little reason, personal research, experimentation or data to back them up.

The power of the mind to think, understand, and form judgments by a process of logic.

The problem

Bandwagon wisdom is a plague in our society. It’s unhealthy, and it appears to be growing in popularity.

I see it in subjects related to parenthood, in preconceived ideas at work, and obviously in controversial topics like politics, and religion. It’s everywhere.

I admittedly catch myself doing it occasionally.

I honestly think we do it most times without even thinking. It’s so easy to “jump on the bandwagon” and share that great one-liner quip, without really comprehending anything about the subject. We do it in person, via blogs, FaceBook, Twitter, and through a myriad of other channels.

Why is this a problem?

Bandwagon wisdom is a tool of manipulation. Topics are carefully crafted to be spread without much thought, but in doing so, we only perpetuate the problem. By “jumping on the bandwagon” we essentially fall prey to these manipulative campaigns, and unfortunately show our ignorance in the process.

The solution

The next time you think about retweeting that highly opinionated, controversial, one-sided statement, perhaps stop and take a moment to consider how much you really comprehend about this topic. Have you spent ANY time trying to understand both side of the issue? If someone called you out on your retweet, would you even know the least bit about the issue at all? Until your answer to both of these questions is, “yes”, why not just hold off on taking a firm public stand?

If you’re going to take an opinionated stance on complex issue, that’s great. I actually applaud informed opinions being shared on complex issues. But if you’re going to take a stand publicly, please start by doing a bit of research first.

The vast majority of times you retweet something, no one will even know whether you’ve invested any time researching the issue beforehand. But you’ll know, and to me, that personal integrity is what matters most. Let’s stop falling prey to the manipulation. Let’s please stop with all of the bandwagon wisdom.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at

Don’t “Growth Hack”

Can we lay this term to rest? It just feels… tainted.

To be clear, growth in and of itself isn’t a bad thing. But somehow “growth hacking” has earned itself a bad reputation. Why is that?

To figure this out, let’s journey back to the very beginning.

Doomed by definition

When Sean Ellis coined the term growth hacker in 2010, he stated that:

A growth hacker is a person whose true north is growth.

And therein lies the problem…

Growth for the sake of growth has never been a good LONG-TERM business strategy. Growth for the sake of growth may appear to work wonders in the short-term, but long-term it’s a wolf in sheep’s clothing. Long-term, growth should be centered around people not numbers or percentages.

The simple truth:

Everything that a “growth hacker” fights tooth and nail to optimize can be improved across the board by focusing on one thing:

Just focus on making your users lives better

Instead of having your north star be growth, what if instead you focused on the success of your users as your primary objective? Once your primary focus shifts to making your users lives better, everything else that you used to wrestle with as a “growth hacker” will begin to fall into place:

  • Activation – By focusing on your users, and their needs, you’ll have less friction in your new user flow, so more people will stick around.
  • Revenue – With more people sticking around, chances are you’ll make more money.
  • Retention – By definition, if more people stick around, your churn decreases.
  • Referrals – If people find your app remarkable, they’ll spread the word.
  • Acquisition – As people tell others, you’ll acquire more users.

By focusing 100% on users you likely won’t see as many short-term benefits as you would if you continued growth hacking. Unfortunately, one side effect of aggressively optimized short-term growth is that it often comes at the expense of long-term losses. Only, you won’t see the long-term effects for years to come, and by then it’s often too late to do anything about it.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at


I loved What separates Peter Pans from the pros by @jkglei

Here’s an excerpt:

When the going gets rough in any creative or entrepreneurial project, what we require isn’t reason or rationality, it’s sheer tenacity—commitment to our abilities, commitment to our process, commitment to finishing even in the face of the inevitable setbacks. This is what separates children from the adults, and the Peter Pans from the Pros.

If being grown up means being committed—to a business, a project, a person—then it’s impossible to peak. And the deeper the commitment, the deeper the meaning that can emerge.

It reminds me of the classic War of Art, and Turning Pro (both HIGHLY recommended) by Steven Pressfield.


I don’t do comments on this site, but if you have thoughts, I’d love to hear them. You can email me at