Elliot Nash

Builder of NZD.life, Co-founder of Croovies.com, CampusHero.com, 404engine.com and a few others. Dribbbler, fitness jabroni. Doing stuff with Fliptables.io. VP of Product Devlopment @ Aiera

Read this first

The fastest development process you’ve never heard of.

My favorite process for building a product (with a small team) is the “squeaky wheel.” It’s essentially no process at all, but might be the most effective process I’ve ever used.

Create a “squeaky wheel” process

  1. Weekly Monday morning meetings
    Discuss road mapped priorities, and what everyone will be working on for the week. Now is the opportunity to make changes to that plan.

    These meetings should include the dev team, but should have at least one person who can represent external interests and priorities, either through a prior meeting, or their own independent discussions.

  2. A team that uses the product, and feels ownership over everything. Everyone on your team is responsible for the final user experience (from first sales-touch to cancelling an account), and should feel empowered to speak up when something seems off, no matter how small. This is where the squeaky wheel begins...

Continue reading →

Your manager’s job is to make YOU more money.

Common sense shows that successful managers work for their direct reports

Here’s how.

If you work on planet earth, with other people, the most important thing you can have is a strong, cohesive, well-functioning team.

Sadly, wanting said dream team is usually not enough - the best managers will actively work to help turn a group of people into an effective team.

In my first 1:1 meetings with direct reports, I explain simply,
“my job is to make you more money.”

Isn’t that what we all want?
Someone whose goal is for you to be able to afford more guacamole toast?

Any manager’s primary responsibility is to help their team succeed and thrive, such that they create more value for the company.

So, when you do a good job for your company, your manager looks good too - obvious win-win.

Sometimes however, managers feel their sole management duties are to solve problems, or bestow...

Continue reading →

The first cut is the deepest.

When you have something new, you baby it. Preserving its state of “newness perfection” as long as possible. You polish it, park it far away, or have some expensive case for it.

And then it happens. A dent, scratch, blemish, whatever.

Your treasured possession is ruined in its purest sense. It works & looks fine, but the pristine quality is lost.

You care a little less. The next scratch, dent etc. doesn’t feel as bad. At this point its inevitable. More dents and scratches will come, and you’re no longer worried about it. You’ll get a new thing some day & replace what you have now, so who cares…

Framed over any dev project, there are glaring similarities.

You’re building an amazing product. You fucking love this thing. You’re working hard to ship things and make it even better, then it happens.

A poorly styled link, unformatted email, ugly error page, or some poorly written code, a...

Continue reading →

Shipping Projects.

You will never reach an unknown destination.

It’s that simple.

Shipping side projects is difficult. Really difficult.

You sacrifice a metric shit-ton of your free time, building a project you may never finish, never use, and never even ship. Its embarrassing when it happens, and it can happen a lot. It feels like you’ve failed yourself, and didn’t have enough brains to not start this thing to begin with (although, I do still see a huge benefit even in un-shipped side projects).

I’ve shipped plenty, and failed on a few. When I reflect on those failures, I have one strong conclusion (that applies to me personally, and probably some of you).

The projects that failed had at least one major thing in common, I had no finished product in mind.

You know how this happens…you have a great idea! You need to move fast! You just need to get something online! You start with a quick mockup, and...

Continue reading →

Products, not frameworks.

Almost everything I read about javascript right now seems to be framework related. Angular this, react that (I know - not a framework) , ember is the worst, meteor is the worst, and on and on.

Lots of frameworks are good and bad. But really, who the fuck cares what framework you use?

Anyone who is competent in javascript can learn to use a framework.

I, like most people, care about what you built - the tools you used are secondary.

Many people seem to feel that one framework or another is tied to some level of guaranteed success. “If only I could find the perfect framework, I could build the next snapchat!”


Execution is what creates success.

If you think a framework has problems, don’t use it. Shouting from the roof tops that anyone who uses it has their head up their own ass, only paints you as narrow minded and inexperienced.

Besides infinitely different use-cases, any...

Continue reading →

The Passive Income Myth

I love side projects, I’ve written post after post about how important they are. They build your portfolio, grow your skill-set, and make you a better shipper.

While following along with the “Stanford meets YC and has a How to Start a Startup baby” http://startupclass.samaltman.com, I had a miniature epiphany. A side epiphany, if you will.

If you’ve spent any time on hackernews, you’re aware most developers would love to build something that generates passive income. Its possible, but I think its mostly rare for the main reason that side projects, are just that, side projects.

Some things, like books and products you can sell (fonts, photoshop brushes etc.) probably can earn more & have a longer shelf-life, but are not really broad enough to relate to the point I’m making.

The generic idea of “passive income” is that you do some work, and when you’re finished, your work generates...

Continue reading →

Quit a job you love

I’m lucky. I’ve loved every place I’ve worked. I’ve made lifelong friends & mentors, growing tremendously at each position I’ve held.

So why quit a job you love?

The one resounding reason: growth.

Sometimes, even if you’re still crushing it - you’re not learning as much as you once were. Maybe you’re not trying new technologies as much, or meeting new people anymore… kind of running in some sort of “things are cool…” maintenance mode.

Maintenance mode is a trap, a non-growth purgatory, where you stop creating new awesome things. It makes any portfolio of work you have, increasingly more out of date, and less impressive. People who are still growing, are now passing you by.

When you beat a video game challenge, you level up. You don’t stick around admiring the work of what you’ve completed. You yearn to beat the next challenge and move forward. That’s how you win the game.

Continue reading →

Engage users less

Unless you’re making a game, something porn related, a blog, or any other type of entertaining time-sucking app, your goal is to get people to stop using it as quickly as possible.

Here’s why:

Whats our goal when designing an app? Fuck our goal.

Its their goal we’re concerned with:

  • Saving time
  • Saving money
  • Enjoyment (time-suckers mentioned above)

The crux of UX - Saving time, should refer to the person’s total available time in the day - not saving time relative to your app. Fuck your app.

Every screen, interaction, button, piece of text, invented term, icon etc. All requires space in your user’s “mental inventory”.

Navigating your app requires a “mental map” of how to use it - what each swipe/button press does - and what lives on the other side.

This mental processing takes time, and is the challenge while successfully following the “don’t make me think” mantra.

How many...

Continue reading →

Failing before you launch.

About 2 and a half years ago, I built something pretty cool, that I was intensely passionate about.

It’s called Cedarstack.

You can check it out here: http://staging.cedarstack.com

u: demo

Its an app for crowdfunding online startups, and creating a trading market around them.

I spent hundreds of hours planning this app, designing it, coding it, and then re-doing everything multiple times, and again and again.

I haven’t touched it in about a year and a half (so there are plenty of old bugs, and crufty new bugs)

I will never launch Cedarstack in it’s current incarnation though, and I’m really great with that.

The idea is too much for what it is, its too complicated, and its not solving a real enough need. As someone who launches their own apps all the time, its not a service I would use (even though I built it to solve my own need). I failed before I ever got it out the...

Continue reading →

The “build value” stage






That hilarious question mark is what I like to call, the “build value” stage.

A common example of this
is any product where you have two types of users (any kind of marketplace, social network, job board, community etc.).

There are product users who use what you built and become your product (think facebook or twitter users).

And there are customer users who pay you money to access the “product users” (think advertisers). These people aren’t buying a product or service, they’re buying a return on their investment.

Here are a few insights I’ve picked up from each of the times I’ve reached this stage.

Once you’ve identified your user groups, there is absolutely no chicken and egg dilemma - you must build value for the product users before your customers will arrive. This is the quintessential idea behind building your value.

So lets say your product is...

Continue reading →