I am extremely proud and happy to announce the launch of my latest project: Mozilla’s Community-Driven Accelerator Program Web FWD. Here’s the release blog post: Today we’re launching Web FWD (Web Forward), the community-driven innovation accelerator from Mozilla Labs. Web FWD supports Open Web innovators by providing a space at Mozilla where they can build their products. We are creating a workshop environment where bold ideas can be realized and bare-bones prototypes can develop and go forward as products.

How

We’ll host small teams at Mozilla’s global offices for four weeks at a time, giving them access to our people, tools and resources, so they can focus on building. We’re looking for playful, useful, original problem-solving applications and tools that make the Web a better place. During the four week program, teams will work in-house alongside the Mozilla crew. You’ll receive mentorship and guidance from some of the brightest people around, allowing you to focus on bringing your product idea to life . At the end of four weeks, you’ll have a minimum viable product ready to go out on the Open Web. And together we can decide on how to take this product forward.

What we offer

• The opportunity to work alongside the Mozilla crew in one of our offices
• Access to key Mozilla personnel, introductions to interesting people and industry leaders
• Regular mentorship sessions with experts on technology, scalability, security, marketing, community, and business strategy
• Financial support during the program
• Help with IT infrastructure (servers, software, etc.)
• A great coworking experience with plenty of fun & awesomeness!

What we look for

• The product fits into one of the predefined problem areas
• The product is developed with the traits that are important for the open Web
• The team has at least the kernel of a product (i.e. some working code, not only an idea)

The program runs on a rolling submission schedule with the first spots opening in August. Head over to the Mozilla Labs Web FWD site for more information and submit your application.

In a recent discussion I was asked which books I would recommend for an entrepreneur to read. My (current) shortlist is in no particular order:

• Guy Kawasaki's "The Art of the Start" - very practical advice for everything from building your product, marketing to fundraising. Pretty much a must-read.
• 37 Signal's "Rework" - tons of good, practical information for the post-BS area. Like.
• 37 Signal's "Getting Real" - For me the standard literature if you build a software/web-based product. And if not - still a great read.
• Ash Maurya's "Running Lean" - the fine folks at Pollenizer pointed this book out to me. It's Lean Startups done right. And if Pollenizer tells you to read it, you better do. They know what they do.
• Bo Peabody's "Lucky or Smart" - Bo knows.
• Al Ries' & Jack Trout's "Positioning" - You know nothing about marketing if you haven't read Positioning.

Bonus reads:

• Pretty much anything from Peter F. Drucker - It doesn't get any better than Drucker.
• Steven Pressfield's "Do the Work" - Get stuff done. Now. Don't procrastinate. Overcome resistance. Do the Work!
• For your monthly fix - read Inc. Magazine. 

Happy reading. :)

A little while ago I met with a rather large (as in “publicly traded” large) and (despite their size) innovative software company. One of their Senior Vice Presidents told me that they recently started to design all their products (which are mainly for PCs and increasingly for the Web) using the mantra of “Design for Mobile First”. This is an interesting point - during our discussion they pointed out that due to the specific limitations of mobile devices you often end up with less clutter (at least when carefully designed), more to-the-point interfaces (as you simply don’t have the space to mess around). Also - due to the nature of how you use these devices (text input for example comes at a premium) the designer avoids lengthy interactions which further leads to lightweight and simply useful interfaces. The example which was used in our discussion was the website, mobile website and iOS application from the airline Southwest. Instead of me going into details - check this out (it drives down the point pretty nicely): As an exercise - try to find the “Check In” button/link on the web version of Southwest’s site.

One of the many reasons why working at Mozilla is such a fun experience - you get to design your own business cards! (And yes - this is me wearing the Firefox costume at the “5 Years of Firefox” party)

The following is more a snippet / thought / exploration than anything else - just wanted to get this out and put it somewhere…

Hyperlinks allow you to seamlessly browse the Web - clicking on a link in an email inside your webmail client can transport you to an article on Wikipedia which can lead you to a reference on some other website. Hyperlinks provide the glue which keeps the Web together. They link the vast amounts of information the Web has to offer together and allow for one, seamless interaction.

Enter Apps

With apps we are silo’ed - none of the apps on my phone, my tablet and for the most part on my computer link together in this seamless way. If a photo app on my iPhone wants to share the picture I just took on Twitter it needs to implement this functionality internally - regardless if I have the Twitter app installed on my phone or not. Developers are forced to reinvent the wheel all the time. Users can’t easily link their preferred apps together (what if I don’t use Twitter but Identi.ca or store my photos on SmugMug and not flickr?)

APIs provide this capability - but they strongly favor a highly concentrated distribution model: As every developer needs to implement each API again and again, developers only integrate with the biggest players in the market.

The future should consists of a simple, unified API (let’s call it - for lack of a better word - the “API-to-Me”) which provides a way for each of your apps to announce which data and functionality it can provide – and consequently consume these services from your other apps. The user agent (your browser) acts as the intermediary - putting you (the user) squarely into the middle of this exchange: At all times do you stay in full control over which apps shares data & services with any other app.

Last week I was lucky enough to be invited to speak at NASA’s Open Source Summit (the first of its kind) about “Lessons from Mozilla”. Now - if you follow this blog you will realize that I give this talk quite often. Mainly because I think that the talk is highly relevant for so many organizations (and please note - the slide deck was developed by Mozilla’s former CEO John Lilly - I am merely the messenger) and secondly because I am really, really passionate about the content. To keep the deck fresh I trimmed the text on most slides, put the whole thing into a new template and made some other edits. Enjoy.

[Update - April 10th, 2011] Here’s the video from my talk.

Most organizations build products. Only some build platforms. Even fewer turn their platform into an ecosystem. The ones who are successful in doing so are the ones who create thriving spaces for innovation and (economic) opportunity. And sometimes you see those organizations starting to compete with their own ecosystem. Which turns out to be a bad idea. Always.

Let me tell you a story

When I was at eBay (back in the day) we decided to open up our API to allow outside developers access to the eBay system. We wrote documentation, we went on road tours to show the world what is possible with our API, we worked with and helped developers to build their ideas on top of the API. Within months we created a thriving, growing, innovative ecosystem of individual developers & companies who created tools which fulfilled a huge need - tools to allow larger eBay sellers stay on top of their sales, inventory, accounting and their customer relationships. Within a short two years this ecosystem grew so fast that a significant amount of eBay items were listed using these 3rd party tools. Then eBay decided to compete. eBay built their own tools - albeit not very good ones, but eBay had the advantage of controlling the access to the customer (which happens to be the same customer our API partners sold their products to - eBay sellers). After a while eBay decided to lower the price of their tools to essentially zero - because they could (eBay made their money by the listing fees, not from selling tools). What happened then was that the market for lower-end seller tools dried up - nobody could effectively compete with eBay. eBay could push their products to their customers - both from a marketing as well as pricing perspective. The result was that innovation in this space effectively disappeared - the tool vendors either went upmarket (i.e. they produced tools which had more functionality and were more expensive) or simply disappeared. eBay sellers were either forced to live with the rather mediocre eBay tools (which they got for free - hooray!) or had to spend significantly more to use the high-end tools. All in all pretty much nobody won.

The moral of the tale

I don’t know a single case where competing with your own ecosystem proved to be a good idea. Not unless you didn’t have much of an ecosystem to begin with. Sometimes organizations think they have an ecosystem - but really, what they have is a platform which nobody cares about. Then it might be a good idea to build your own products on top of this. But only then.

And why does this matter?

Simply because I see this happen again and again: Twitter buying and building their own Twitter clients and giving them away for free. Android building an open system with an open market; theoretically allowing anyone to build their own store, but effectively locking people into their own store as it is preinstalled on every Android phone being sold. The list goes on. So - if you find yourself ever in the situation that you have a successful platform which spawned an ecosystem: Don’t kill it by feeling the urge to play in your own ecosystem. You are the platform. Not the player. P.S. Point in case: Twitter tells developers - Stop making Twitter clients [added on March 11th]

or: Talking about Lessons from Mozilla at NASA

Last week I was fortunate to have had the chance to talk about Mozilla and the way we do Open Innovation in a community centric environment at NASA’s Human Health and Performance Center in Houston, TX. My talk centered around seven insights we learned over the years, two problems which stem from the way we do things and ended with a couple of observations of topics which Mozilla Labs finds particularly interesting in 2011 and beyond.

(Please note that the slides and overall concept were originally developed and presented by John Lilly, Mozilla’s former CEO) While being in Houston the NASA folks gave me a tour of Mission Control and their training/mock-up facilities. Which brought up an interesting analogy - the way we run operations at Mozilla Labs is much more Soyuz than Space Shuttle - i.e. we have a solid base, make things up as we need to, generally fly by the seats of our pants and simply make it work (as opposed to a highly engineered and planned effort - aka the Space Shuttle). ;) P.S.: I will update this post with a video from my talk as soon as it becomes available.

Intro

I can be quite obsessive when it comes to getting more productive, efficient and effective (I guess it must be my German heritage - Vorsprung durch Technik and all that). Since my early days at university I have been pondering with numerous systems to get me there. David Allen’s Getting Things Done was like crack cocaine to me - unfortunately with similar side-effects: It promised bliss but didn’t really work (for me). Too much effort in keeping the system up and going. Too many things which I needed to think about. Too many processes. Too much complexity (ironically). It just didn’t work. I read the book when it came out in 2001. Since then I have been on a quest to find the perfect system - which in my eyes is combination of a process and a piece of technology (anything from Moleskins to iPhone apps). After churning through at least five variations of GTD-inspired processes and numerous analog and digital solutions (notebooks, text files, Mac apps, iPhone apps, Mac apps which sync with my iPhone), I believe I have found a system which works for me.

Enter Autofocus

Lifehacker recently published an article on a system dubbed Autofocus. Autofocus is described as “a Single, Paper-Based List Organization System” and Lifehacker titled “The Autofocus Productivity Method: Stop Maintaining To-Do Lists and Start Getting Stuff Done” (article). I was intrigued - and started playing with the system. The general process is to write down all your todos in a single list and maintain a system with only four categories (new, recurring, unfinished and old). This sounded simple enough - personally I didn’t like the prescribed way of maintaining your list on paper. In the past I have somewhat fallen in love with the user interface of Things for Mac and wanted to see how I could apply this system to the specific UI and UX flow of Things.

Things meets Autofocus

So here’s my current setup: During the day I enter all todos into Things’ Inbox (which is the natural place for them to be). Every morning I move all the todos from the Inbox to the Today section (Command-T). I then go through the list of todos in my Today section and mark them off as I go through them. Todos I don’t complete throughout the day are moved to the Someday section (Command-Y). The next day I repeat the process - and also go through the Someday section and move all the todos I want to tackle that particular day into the Today section (which means that I effectively cull two lists into the Today section every day: All todos from the day before which are lingering in the Inbox and a couple selected items from the Someday box). Todos which are recurring are entered with the appropriate information (which automatically moves them into the recurring section and Things puts them into my Today list on the appropriate day). The one addition I made to the Autofocus system is that I created an “Area of Responsibility” in Things which I call “Waiting” - todos which serve as reminders that I’m waiting for input or feedback from someone else on, are put into that section which I review every couple of days. Note that todos which I jot down during the day are entered into the Inbox - thus they don’t pile up in my Today section for that particular day. Here’s a screenshot of my current setup: As mentioned above - this system works extremely well for me. I tried to use a bunch of the more advanced features in Things in the past (such as tags and projects) but they just add complexity and don’t provide value to me. So I kept it as simple as possible - which seems to work best for me personally. Give it a try if you are intrigued (you can get a trial version of Things which is fully functional for two weeks or so - enough time to try this out). And let me know how it works for you.

I wrote this article originally for the 24 Ways to Start blog - I encourage you to check out the other articles on this “advent calendar for entrepreneurs”, they are well worth the read.

“I use LinkedIn to keep track of my professional network, and would like to add you.”

Let me start this with a true story: Two years ago I mentored startups at Seedcamp. My group of mentors consisted of VCs from the largest European firms and top-notch technologist from companies such as Amazon and Microsoft. We ended up talking to at least 20 entrepreneurs from all over Europe. We gave each and every one our business cards. None of them followed up, nor at best send out a LinkedIn invite with the standard invite text. First I thought “…it’s just me”, but after asking my fellow co-mentors, it turned out this was true for them as well. I was baffled – as an entrepreneur you are in the business of relationship-building (and if you think otherwise, you better rethink your approach). You should see every interaction with someone who might be helpful to you and your business as a golden opportunity. Not making use of this opportunity in the best possible way is not only wasteful, it might be the make-or-brake moment of your company. So here it goes – my personal tips on how to properly followup.

The Why

I guess by now I don’t need to tell you that you should always follow up. No exception. If someone spends time with you, listens to you, probably gives you some advice or helps you in any other way, you follow up. A follow up is not only an act of courtesy, but your opportunity to build a long-term relationship, ask for a favor or simply say thank you. Its the good manners that your Mom taught you. There is a ton of research which shows that people are very inclined to help you if you just ask. It’s engrained in our nature. We want to help. It makes us feel better and boosts our own ego. And on the flip-side – who wants to be the Scrooge who didn’t help someone (if asked nicely)? Finally – don’t hesitate to followup just because you think the person is too busy or too important. We are all humans – we all work the same.

The How

Now that we’ve established that you always follow up – make sure you follow up properly. Send a short email thanking the other person for his/her time, and do ask for something specific. Yet think about keeping your early demand small, you don’t want to overburden your newly established contact. Remember, always ask – it’s your golden opportunity to build a working long-term relationship. This is all pretty much a no-brainer, right? And people seem to grok it when it comes to email (minus the “ask for something” part). But once you get into the wonderful world of social networks, all this seems to fall apart. Never (and I mean never) send out an invite on a network such as LinkedIn using the standard invite text. The signal you are sending me by doing this is: You are not worth the time for me to change this text and I just want to connect with you to add you to my collection. In my eyes this is one of the biggest mistakes you can make, and a surefire way for me to permanently ignore you. Here’s how you do this properly – don’t leave the standard text in there, write a short, personal message which sells the other person on the idea to connect with you. This is usually best achieved with a small ask – e.g. “I would love to stay in touch with you and ask you every once in a while (not more than once every couple of months) for your advice on XYZ”.

The What’s Next

Don’t trick yourself into believing that it ends here and all will be good. This is only the beginning – granted you got it of a good start, but now you want to mature your relationship (think long term, not short term again — no-one likes to feel used). Send an email every once in a while, pointing out some interesting news or research which is relevant for your contact. Ask for the occasional coffee to compare notes. Get creative and add value for the other person – trust me, it will pay back twice over. With that being said – go and network. Make new friends, allies and partners. Don’t be shy. Ask for help. And always follow up!

With the increasing discussion about (Open) Web Apps and how to distribute them, we seem to run into an interesting confusion about the meaning and use of the term “open”.

For starters the term “open” broadly speaking can mean two different things when we refer to Open Web Apps or Open Web App stores/marketplaces/ecosystem:  On one hand we have the use of Open Web technologies such as HTML, CSS and JavaScript to build these apps - which means that the apps (mostly) run in all modern browsers.  On the other hand we have openness in the way the market is architected - this ranges from single, vertically integrated stores (not open) to completely free markets which allow for many stores and the self-publication of apps (very open).

These two aspects are fundamentally different and not interlinked:  You can have a tightly controlled single marketplace for apps built using Open Web technology which only run on one particular device, operating system or browser based on the distribution scheme of the market.  On the other hand you can have a multitude of markets/stores for apps which are built to run on a single device/operating system.  Both might be referred to as open - the first is open in the sense that it distributes apps which are built using open technologies (though the market is not open), the other provides choice on the store side, which is an open market - but distributes closed apps.

Obviously the most open approach is an open market (many stores) for apps built using open technology (no device/OS lock-in).  This is what we are building at Mozilla at the moment.

So be careful when you talk about open - open doesn’t always equal open… [Photo Credit: wiccked on flickr]

Ever wondered if apps are really here to stay? Well, if 6.5bn downloads don’t convince you - having made it into Sesame Street surely made this point clear. Enjoy and sing along! :)

Smartphone users currently live (mostly) in a world with only one app store - the app store which is provided by their operating system provider. Having a single app store makes life easy - no choice means you don’t have to battle with the paradox of choice.  Tight integration into the OS layer makes purchasing apps a cinch (though I still wonder why I can’t pay for my iPhone apps through the already established billing relationship with my cellphone provider).  A heavily curated store ensures that I don’t download software which might contain unwanted content (e.g. porn) or is not authentic (e.g. content from Disney which doesn’t come from or is not authorized by Disney).  A single source for all apps also means that I don’t need to look anywhere else - there is only one place to find apps. But all this comes with a very high price. Most of us have heard the stories of developers who are grappling with the approval process of app stores (and sometimes even Pulitzer price winners can’t get their app listed).  More importantly than the simple fact that the rules made up by a store don’t allow an app to be distributed is the fact that in this world, the author of the app doesn’t have any other choice:  Choice of a different app store with different rules and choice of simply putting the app up on his own site and distributing it through his own means. Further the lack of competition in app stores means that as a developer you have to accept the economics of the deal.  No negotiation, no competition for content between stores and no competition between stores for the customer (and stores might choose to compete on other dimensions than price alone - think service for example). From an end-user perspective a single store nearly always results in limited innovation - there is simply no strong economic incentive for the store operator to go out of his way to provide a great user experience for the customer.  Current stores nearly unisono suffer from poor search functionality, lack of social discovery features, lack of pricing features (bundles, buy one get one free, etc)…  In a world where stores compete with each other, one can be confident that these problems will be solved (either by the established players or by new entrants who use this as a way into the market). Don’t get me wrong - all this comes also with a prize: This world is just a bit messier than the squeaky clean world of single, tightly-controlled app stores.  But it’s a price well worth paying as this world is a more vibrant, more dynamic, more innovative place - and it’s a better place for both the developer and the user. In summary - it’s a somewhat bizarre artifact of the times we are living in, that we accept an app economy which is flawed on so many levels.  We wouldn’t accept this world when buying shoes, books or our entertainment products. So let’s not accept it - let’s build something better.

A few days ago I spoke at Berkeleys >play conference on app stores, why and how they are broken and how HTML 5 and the Open Web app platform Mozilla is currently building will fix them (hint: The Web has won before and will win again). You find a short summary and the slides from my talk here.  Realizing that the slides pretty much only work if you also have the audio track, I decided to record a video version of my talk.  Please note that this is a recording which was done after the fact - so my voice might sound a bit less dynamic and enthusiastic than in the original auditorium (turns out that the built-in microphone in my Mac is really bad at picking up a loud, dynamic voice).

If you prefer to watch the video directly on Vimeo, click here.

Today I gave a talk at the >play conference (Berkeley Digital Media Conference) on app stores, why the current model is inherently broken and how to fix them (hint: check out Mozilla’s work on an Open Web App Ecosystem). Here’s the synopsis of my talk: “Today, apps are extremely popular -  they’re easy to use, easy to find and attractive. However, this new world of apps is extremely flawed - and the growth and potential innovation of the current app system is held back by closed development models, vertically integrated experiences without competition and obscure approval procedures for developers .  There is a better future - it’s called the Web, it won before and it will win again.” And the slides (note that most of the important bits are lost on you if you don’t have the audio track):

You can also see the slides directly on Scribd