All startup and entrepreneurial spirits have them, the so called 'pet project'. That idea that struck you at friday afternoon after some beers. You immediatly started coding, wrote some blogposts and a bunch of users are now using it. A year later, usage declined to zero.

There is tons of other stuff that needed to be done on other projects. So it happened you didn't released something new. People didn't complain, because they actually didn't care. And now they found another startup that solves they're problem better.

That sounds and feels like failure. But is it?

I think there is another take on this. All those tiny little products that one day die are the 'small badges' for you as a person. In the world of innovation and product development you and your team are the 'production line' (sound awful if you put it like this). The only actual road to progress.

Every time you run a quick pet project you will learn. At every step you take you could uncover a broken part of your 'production line'. The improvements in your marketing, interviewing, support and coding skills will help you to build that massively awesome and successful startup one day.

It doesn't matter that it takes time or that you only reached 25 users. What matters is that you actually ran a test with yourself and your team to build and launch something.

Should you never care to be successful? Of course not. Improvement is something you can measure and act on. But in order to start improving, start producing. It provides so much inside that it might even be stupid, as a startup or tech company, not to have pet projects.

It's the by-product of learning in the world of startups.

This weekend I was fortunate enough to attent to LeanCamp London. An unconference around topics like Lean Startup, Business Model Generation and Customer Development (and actually anything you can think of).

I have been to some conferences and I haven't encountered anything like this. The format makes it an amazing engaging experience and really helps you to get deep understanding with your peers.

After walking in, you'll see an empty schedule in the room. There is no content, yet. After the room was warmed up, every attendee got a chance to pitch his session and add it to the session.

Seeing the program shape up in about 45 minutes in a collective effort, is really something you should experience. It's awesome. Interesting enough the program will balance out. So a lot of topics get covered.

I can't really think of events where you learn to draw, get familiar with other peoples kanban's layout and see Alexander Osterwalder bravely live sketch his session on stage, in one day?

LeanCamp is like having baddass entrepreneurial spirits thrown into a room for a big party. It just keeps going and when it's over you'd want to travel back in time to attend again.

In the coming days a lot of the content will be posted. I'll probably blog about some sessions I went to, but you can monitor for the release of new content at the LeanCamp Lanyrd page.

This year LeanCamp will go all around the world and I encourage you to try and attend to one. For the experience, seeking inspiration, knowledge and helping your fellow startup junkies by sharing your knowledge.

It's time. Take that pink pill. Stay in the loop through the site of LeanCamp.

Great short discussion with Salim Virani today on twitter. Started by this blogpost by Seth Godin. It's about testing the viability of products that need scale to work. Could you test big projects on small scale?

It daunted me that it's very easy to misinterpret the term ’minimum’ in the term ’minimum viable product’.

Minimum is something I quickly connect to 'less' and in some way this nails the term. It's about speed. But your goal is learning, not releasing.

The question you need to ask yourself: ’what do we need to do in our first learning activities?’. The combination of these activities is a version of your minimum viable product. And it's different for every product.

A startup that has to do with the financial or legal space could have significant higher up front cost than a simple solution you can provide to developers.

While a MVP of another startup might not look minimal to us, it could be to them and the market they are after. If it looks or feel bloated, it doesn't mean it is not the minimum they need to start learning.

What will be build and when will we call it finished. The best MVP's I've seen weren't coded in the first learning cycles at all. Design practices play a significant role to reach your MVP.

One of the MVP models I particularly like is the so called 'concierge' model. This is where the founders of the company directly work with their first customers without the most important parts of their product being build.

The inner works of the product is provided to the customers by hand. This could be any aspect of the service you want to test.

I like this because you turn your first actions in a big qualitative research process. And it connects with a lot of the 'lean thinking' principles. Like reviewing where value is lost in the processes your customers use your product.

Look for the best ’touch points’ with your customers. Where are they experiencing the most pain? When are they interested in hearing about your solution?

If you execute the concierge MVP well you will be able to: 1. Learn which other loss of value you might be able to prevent with your solution 2. Learn when and where people are best perceivable for your product 3. Quickly adapt your assumptions based upon these loose signals 4. Built your first close relations with potential customers, if you do it right you will be able to keep in touch with them 5. Learn which parts of your product are most important and need to be build first

Executed correctly, the concierge approach will keep you flexible and brings you important information to learn from.

It helps to keep your 'MVP' minimal as possible.

I just recently started exploring 'The Connected Company'. A topic which is being explored by Dave Gray and others. It evolves around the notion that company building based upon 'machinery design' isn't sustainable. Basically it's one of the reasons that today a the average life expectancy of a company is less than 15 years. Around 1937, that was 75 years!

So clearly our world is evolving (no shit sherlock..) and company building needs to adapt in order to cope with these changes.

Luckily most of us are living in the most adaptable systems ourselves. Called nature and your city.

The difference on an abstract level is pretty easy. Machines only work with active humanized input and control. Whereas organisms are unpredictable and complex systems constantly adapting and reacting on what's happening around them.

A city doesn't have a central planning like most companies have. But cities are more complex and way more productive than most of the companies we know. Research has shown that when people are added to a city it actually becomes more productive and lively. However when we add people to a company, productivity drops.

I'm happy to see that this topic looks to be closely related to the lean startup philosophy as it embraces change and agility in big companies. The forthcoming knowledge on this topic will be interesting to all current startups.

My forthcoming posts on this topic will be about the charactaristics of existing companies, what it means for startups and above all what we can learn from it.

For now take the time to watch this promotional item from the BBC for the series 'The Secret Life of Chaos'. It gives a good sense on how chaos and order are unpredictable and both live right within the same systems.

It blew my mind.

On Thursday last week I've attended to the Amazon Startup Tour in Amsterdam. The day was about the services Amazon is providing to run webapplications and websites. Amazon Web Services (AWS) range from computing power, data storage to database services (and more). Two important reasons to use the services are scalability and uptime.

At the event a few dutch startups presented their great applications and how they use Amazon to run them. Afterwards there was time to ask questions to the starups and later on to Werner Vogels, CTO of Amazon. One of the most interesting questions was about the data that startups store at Amazon. Martijn de Kuijper of Qash asked:

How do we tell our users that we don’t know where their data is, except that it is “in the cloud?.

The answer to the question is that all data from Europe on AWS is stored in Ireland, guaranteed. Therefore the data will be under the jurisdiction of Ireland. So another question came to mind. In essence, AWS is 'controlling' the data of our clients. For example what will happen when a client decides to delete his account. What will happen to his data? We asked this to Simon Brunozzi (European Envangelist of AWS). He told me that they always have been executing audits on the data of Amazon.com and also AWS. Recently a security whitepaper is published about this.

I think cloud computing is providing great advantages when you're building a web application or starting an online business.

No let me rephrase that.

Using the cloud for your applications will remove a lot of constraints and will break some traditional rules of business development and IT management. Starting your online business will be cheap and above all will provide infinite resources at a click of a button. You can build web applications very agile, but the business wasn't that agile yet. AWS and other cloud services make running your infrastructure and business very agile.

Martijn de Kuijper mentions this in a recent blogpost:

Again, I personally believe that Amazon offers a great service and I do trust them in such a way that I wouldn’t mind “sending” them personal data, but I think for a customer it’s a big step to know that I if they took the first step of uploading their data to for example our server, their data is then stored on external servers.

First of all, I believe that a customer always is putting his data external. For example we're running Tweetburner on our own server. For us it feels as an internal server (we can drive to Haarlem and put our hands on it!!). But for the users it is as much an external server as if we would use AWS.

Probably they would even prefer AWS above us running our own servers. Not only has AWS more security, more experience and more resources. They run their own multi-billion dollar webshop on there. If AWS fully breaks down, their webshop is down too. That probably is the biggest devotion a single hosting company is doing to it's own services.

Cloud computing won't 'fog' our business, it will strengthen by allowing to use external infrastructure and resources with a click on the button. Something I couldn't wish for more as a business developer.