Iterate as fast as possible

Have an aptitude for serendipity

Get more parts on the table

Stay motivated with recurring small dopamine hits

Incremental correctness

Keep it simple, stupid

Measure output, not outcomes

Non-technical regrets at Spectrum

Solve your own problems

Design a process

 Make it easy to jump in

# Always be shipping

The more things I ship, the more chances serendipity has to strike one of them. ([[Have an aptitude for serendipity]])

If you never release that song you composed, how is a music label meant to discover you? If you never release that novel you wrote, how is a publisher meant to stumble upon you?

This doesn’t just apply to big projects, since I try to [[Iterate as fast as possible]] any small change counts, which also makes me [[Stay motivated with recurring small dopamine hits]].

> _”I like shipping things, and shipping consistently has helped put me at the forefront of a number of big shifts in technology over the past few decades." - Seth Godin_




# Design a process
The way I can achieve the outcomes I dream of is by having a process that guides me in the right direction. If I [[Measure output, not outcomes]] as following my process I have already done the hardest part.

This does not mean I will let it be up to chance whether or not I reach my dreams. I have to [[Always be shipping]] redesigns of my process that guide me towards the right outcomes.

People have put this many different ways:

- The journey is the goal
- Act like the person you want to be in the future, today
- Habits define a person

It’s all the same core idea. Have a good process, and work it. Every day.

The way Steven Pressfield phrased it in “The war of art” is that the differentiating factor between a professional and an amateur is that professionals sit down every day and work their process, no matter what.




Invest in force multipliers

Talk to people

Build a diverse network

Invent by combining things in new ways

Seek discomfort

Sketching exercises

# Get more parts on the table

> _“The trick to having good ideas is not to sit around in glorious isolation and try to think big thoughts. The trick is to get more parts on the table." — Where good ideas come from_

The more "parts you have on the table", the easier it is to [[Invent by combining things in new ways]] and explore the [[Adjacent possible]]. The more connections you make, the more good ideas you can have. The more good ideas you have, the more you [[Have an aptitude for serendipity]] and the more you [[Always be shipping]]!

[[Build a diverse network]] and [[Work in public]] are two ways to increase the amount of parts I have on the table. The bigger and more diverse my friend group and the more I [[Talk to people]], the higher the chance somebody has that unique part on their table that connects my ideas to their thoughts. A good way of knowing if you’re on the right track is to [[Seek discomfort]].




Always be shipping

Work in public

# Have an aptitude for serendipity

My career is almost entirely based on serendipitous connections. While they are random chance, of course, the one thing I take credit for is having (what I like to call) an “aptitude for serendipity”. I try to create as many opportunities for luck to strike me as possible.

Some ways I try to influence serendipity are:

* [[Iterate as fast as possible]] and [[Get more parts on the table]] so I have a higher chance of inventing something novel. ([[Invent by combining things in new ways]])
* [[Always be shipping]] so serendipity has as many chances as possible to strike one of them.
* [[Work in public]], [[Talk to people]] and [[Build a diverse network]] so more people have a chance of stumbling upon my ideas and connecting them with their own thoughts.

Personally, publishing open source projects has been a great way to do this. There is no downside, assuming you [[Solve your own problems]], and the upside could be career-defining. My career was defined by react-boilerplate being posted and upvoted to the HackerNews frontpage!




# Incremental correctness

Incremental correctness is a concept I first heard from [Guillermo Rauch](https://twitter.com/rauchg) and internalised after [Max Schoening](https://twitter.com/mschoening) repeated it often enough. Essentially, start off with a minimum-viable product and then [[Always be shipping]] small, incremental updates. In theory, if you [[Iterate as fast as possible]] this the fastest way to build something great from scratch.




Be as cross-functional as necessary

# Iterate as fast as possible

The more iterations cycles I can go through the faster I will arrive at a great result. ([[Incremental correctness]]) It also helps with [[Always be shipping]], if you have lots of iterations you have lots to ship. Iteration cycle speed is a force multiplier, and keeping it as fast as possible is crucial. ([[Invest in force multipliers]]) 

Some ways I improve my iteration speed are [[Invest in force multipliers]], [[Keep it simple, stupid]] and [[Be as cross-functional as necessary]].

For example at the micro level, I make sure my build setups are fast enough that I never have to wait to see changes in development. For example at the macro level, I try to give my users a quick and easy way to submit feedback and for me to see it.

Hunch: Anecdotally, I think the 80/20 rule applies to iteration speed bottlenecks. There seems to be bottlenecks which will speed up iteration cycles 80% without a lot of work, the hard part is figuring out where they are.

> _“Speed of developer iteration is the single most important factor in how quickly a technology company can move." — Paul Biggar, founder of Darklang and CircleCI_




# Keep it simple, stupid

Complexity is the root evil that makes it difficult to [[Iterate as fast as possible]] and thus [[Always be shipping]] in the long run. See [KISS principle - Wikipedia](https://en.wikipedia.org/wiki/KISS_principle).

- Fill this out




# Measure output, not outcomes
I have always measured myself based on out_comes_ (e.g. being featured in Forbes), not my out_put_. As [@chantastic points out](https://chan.dev/blog/outputs-and-outcomes/), I am probably hurting myself by doing that: I have zero influence over eventual outcomes, but I can control my output.

I should celebrate myself whenever I am as productive and creative as I want to be, not when some random outcome occurs. That would help me [[Stay motivated with recurring small dopamine hits]] as long as I [[Iterate as fast as possible]] and [[Always be shipping]].

For example, at the moment I want to improve my endurance, so I added a 5km run to [[My morning routine]]. I do not measure myself based on outcomes (e.g. I can run 5km in 30 mins), I measure myself based on whether I run every single day. Whatever endurance improvements come from that are incidental.

Of course, I do eventually want to get somewhere, so I have direct my outputs to where they _could_ help me achieve the outcomes I want. I don’t know how I can ensure that is the case, however so far it’s worked out fine.




Spectrum

# Non-technical regrets at Spectrum
In hindsight, these are the things I wish we had done differently at [[Spectrum]].

## We should have focused on our niche
- Wanted to build for our use case, open knowledge communities (e.g. open source)
- Needed to make money, so built business features
- Businesses were not interested, and had we focused on our core niche use case we would have grown much faster
- Easier to raise money if necessary, more satisfying, ultimately more momentum and higher chance at success

**It's better to have 100 true fans who love the product than 10,000 barely interested users.**

## We should have done way more marketing
- Spend too much time on building new, shiny features
- Should have spent more time on marketing, typical engineering mistake
- Not just social media, but also in-product growth marketing, marketing pages on the website, etc.

**Do way more marketing and sales than you think you need to do.**

## We should have told our story
- Branding was good and unique
- Brand did not have minimum viable personality https://avc.com/2011/09/minimum-viable-personality/
- It differentiates you from the "big guys" as they cannot have a story as personal as you in most cases
- For example, The Practical Dev (dev.to) is doing a great job at this

**Tell your story, it differentiates you from the big players in a crowded market**

[[Sell your story]]

## We should have launched all the time
- Launches are great for marketing, every new release excites customers
- Shipped tons of stuff without ever announcing it
- Missed opportunity to showcase a new feature and get more users at the same time

**Launch before you think you are ready and then again and again and again.**

[[Always be shipping]]  [[Iterate as fast as possible]]

## We should have stuck with the MVP technology
- Had an early MVP built with minimal technology (Firebase)
- Saw some tiny traction, thought we needed proper setup for custom functionality

**Stick with the minimum viable technology setup until you feel product-market fit. You will know in your heart if you have it.**

## We Did Not Talk Enough With Users
- Went into a hole and built a shiny feature for months (e.g. WYSIWYG editing) without talking to users about their priorities
- Ended up wasting valuable time and adding a lot of unnessary tech debt

**Talk with your users, they should be your guiding star.**




My filters for potential business ideas

My life’s mission

# Solve your own problems

Publishing solutions to your own problems has a great /worst/ case scenario great: you never have to solve that problem again.

It also has a great /best/ case scenario: your solution could be discovered by other people and it could propel your career forward.

You have to solve your own problems anyway, so it's a great way to [[Have an aptitude for serendipity]]. Might as well share your solutions and have the option of getting lucky! It also makes [[Always be shipping]] (and thus [[Stay motivated with recurring small dopamine hits]]) much easier.




How I overcome the Resistance

2020-03-24

# Stay motivated with recurring small dopamine hits

The best way I have found to stay motivated once I have started working is to get constantly give myself small dopamine hits. I try to [[Always be shipping]] tiny changes, to [[Iterate as fast as possible]] and to [[Measure output, not outcomes]] to make that happen.

The idea is from the great book “The Motivation Myth”, which I thoroughly enjoyed. Here are some quotes from the book itself about this:

> _“Motivation isn’t something you have. Motivation is something you get, from yourself, automatically, from feeling good about achieving small successes.”_
> _“If you want to stay motivated, if you want to stay on track, if you want to keep making progress toward the things you hope to achieve, the key is to enjoy small, seemingly minor successes—but on a regular basis.”_




@mxstbr's working notes

Always be shipping

Links to this note

What do you think?