Think it. Build it. Ship it. Tweak it.

This is a concept that companies often can't get their head around. Too often so much time and love is spent on trying to get something just right before launching. To switch to the mindset of:

"Fail fast. Learn fast"

is difficult for us humans to get our head around. Because who wants to fail right?

You will fail if you keep this up because online things are moving at a million miles an hour and if you don't keep up you will be left behind. Guaranteed.

I listened to a presentation by Bill Scott at Web directions today and really enjoyed his insights.

Working at Netflix he said they were manic about data and analytics - its all about measuring the experience and making it better for the user. (By the way they know Australian's use proxy servers to get onto Netflix and they don't care). They were lean, fast and agile. At Netflix they have a saying:

"every feature is a barnacle. As soon as it goes in its impossible to remove."

Netflix launch themselves into the latest technologies because as a start-up they have to. They have to get to market before their competitors and they have to iterate and test. While Netflix are deploying HTML5 their competitors are beholden to old technology and crappy UX teams (Sony!). Netflix launched 4 experiences for browsing movies and 16 variations all in the same day. They assume nothing. They learnt that people don't care about fancy tools for filtering and brain dead simple usually wins. People aren't as smart or willing to interact as we may think. They engineer for throwawability with majority of work thrown own within a year.

So then he moved to Paypal. Paypal were the opposite, they had grown so big they couldn't move. The designs were old, the code was old and a copy change took 4-6 weeks to be reflected on the website.

Paypal were carrying such technical debt that any new developer had to attend a 21 day training course before even looking at the code. No measurement of analytics was done and the smallest project would take 8 months to get out the door, by which point it was outdated. They were flying blind.

This isn't a unique situation, so often companies find themselves in this predicament. Carrying technical debt is a huge risk, particularly around proprietary code. Bill identified that changes needed to be made.

The theory was executed that all technology should be googleable, if you can't find the answer on google then the technology shouldn't be used.

"the code you write today is the legacy of tomorrow".

Collaboration was bought in and teams were small and consisted of engineers and designers. In one room days would be spend whiteboarding and sharing ideas within these small select teams. Collaboration was the key.

Prototypes were not done in Azure they were done on paper and on whiteboards and taken to users every week. The more users they could talk to the better and they did this every week without stopping. They followed the principles of open source software. It is still a work in progress but the feedback on the UI of Paypal has changed considerably. They re-invented the checkout process that was responsible for 2 billion in revenue and they continue to iterate.

Changing the mindset of the team is the key, instead of "defending the solution" you need to "embrace the problem" this means looking at data and identifying where users are struggling and fixing it. This leaves you hungry to find and fix the next problem. 

Ultimately it's all about the user so let's not forget this.

There are 4 principles that you can follow to do this:

1. Enable learning. Use analytics and monitoring to learn from users and continue to grow because of it. Make the delivery or "launch" of a product a non-event because it will be continuously delivered. Start small and learn and grow. 
2. Design for experimentation. Design to test and then test again. Assume that things will be thrown out and things will fail but design with this in mind.
3. Democratize innovation. "If you can't feed a team with two pizzas its too large". Keep teams small and allow them to innovate. Use open source software everywhere you can.
4. Give agile a brain. Don't say "as a user I want to" because you don’t know, you should be saying "I think a user would want to". Agile is a machine and you need to adapt it to best suit you. You need to be lean to be agile.

He used an analogy similar to the below. When deployments are frequent and small there is less fight and pressure to get everything included, not to mention less risk. They use Github for this reason. The same can be said for trains, when they are frequent and fast there is always less build up. People jamming on a train are equivalent to features being jammed on a site.