Building a startup: beta stage (december – april 2012)

Last months were very busy at Cozy Cloud: we started our new beta program, we hired new members, we communicated more widely and we worked hard on the product. Here are the details of what happened.

beta stage

We previously started a beta stage that would be better called an alpha stage: only a few close friends were able to test our product (named Cozy). In december we decided to make things wider. This time we took hundreds mails from the list of people who subscribed on our website and we mount up a Cozy for each of them and send an email about what was happening. We were very excited by that and it was time to battle-hardened all our stack (infrastructure and product).

hard times

Unfortunately, four bad news happened to us after our beta launch:

• Things didn’t work as expected. We had very few feedbacks. Almost noone wrote to us. Some people didn’t even use their Cozy, despite the mails we sent to them. We learnt one thing : the capabilities of the product were too poor. Even if people knew the potential (it’s an extensible product) of our platform they didn’t get interested in it… except a very few ones who gave us some hints on what was wrong, what was not working.
• We met a lot of problems with our hosting infrastructure. Providing hosting services is not as easy as you could imagine. Even with 100 instances we had to set up automatic backup, precise monitoring and look for optimisations. And we are still working on the provisioning and logging aspects. It’s like we have to be able to scale early.
• We wanted to be part of Le Camping, a kind of YCombinator for French startups (we are located in France). We spent a lot of energy in our application material. We rewrite most part of the website, we changed our linkedin accounts, we spent days to record the required video. But that was not what they expected: we were busted in the first round.
• We also send applications to have a stand and talks at FOSDEM. Our application was refused too.

This clearly brought us some doubts about the value proposition of Cozy and the feasibility of providing clean hosting services. Fortunately, people that follows us since the beginning kept encouraging us and help us with bug reports, feedbacks or  developments. That maintain our faith in what we do. So we decided to go on and find more workforce to help us.

NB: The reasons of why we get rejected suprised us: The Camping said that we need an experienced marketer or a first round of fundraising. FOSDEM told us that we should have a fast growing community. For both, we candidate to them to find help to do what they ask for…

new team

We made several recruitments : 3 developers (interns) and one marketer. That was a great move : they all performed pretty well and fix broken things. Today, they are still improving the product,  and they are bringing a lot of new ideas.  Moreover, what we learnt from our previous intern session, made it easy to set up our new organization (see my recently posted slides). All the materials we wrote before (documentations, tutorials, public repository…) helped them to get operational very quickly.

marketing

Then we started to think marketing seriously. First we improved the overall aspect of the product : we redesigned the user interface. Second,we improved the tools provided to Cozy external contributors to help them to set up their development environment.

Then, we applied the principle of content marketing : you produce great content (blog and newsletters) to give a good reason to people to come. We  also contacted blogger in our field (self-hosting). That’s important to reach the community to let them know that we are doing something that could interest them. We learnt from that we should separate more the project aspect (Cozy is open source) from the corporate aspect. Then we get more feedbacks on our app and our installer. So we could figure on what to focus on. We also recieved a lot of encouragements which were very important for our moral.

conclusion

So we learned the hard way two things: that’s not because you are able to convince people of your field (self-hosting) that you will be able to convince people from another one even if it’s a close one (innovative people). The technical part should never be underestimated too. We had a lot of experience in IT and we get still astonished by the required amount of work. We also tried to think simple all the time, but adding a lot of simple things make a complex thing. We also learnt that bringing new people to the project and recieving positive feedbacks give a lot of energy. Building a startup is a long journey and moral must be kept on top all the time.

Next months for Cozy will be dedicated to our contract with our partner (FING), to growth hacking and to fund raising. We hope you will hear about us very soon and not only on this blog!

A startup with no office, hipster tools and open source products

Talk performed at LyonJS, April 2013

Building a startup: branding and community (september – november 2012)

When you build a startup, you define a product. Once the first iterations are done, you make it functional and verify some of your assumptions. Then you obtain a kind of  “first version”, a state that statisfy you enough to think “I would  buy it”. You could apply the same for your “pitch”, the way you introduce your product to people interested in what you do. Then you observe that things could be sexier, more engaging. When this feeling arises, this is time for branding: putting a logo on your company, dress your punchlines with a beautiful design, define your mantra and build partnerships that will rely your values.

Identity and website

We didn’t have the required skills to make an appealing logo and design properly our website. So we decided to hire someone good at this to make the job for us. After watching tons of portfolio from folyo.me, we selected the designers we prefered and contact them. We learnt the hard way that good designers are quite booked and required to be hired early. After a lot of researches and emails, we finally conclude to an agreement with Paykhan a Freelance designer.

He built the website with 4 iterations. The first one was a little bit messy but gave us a lot of ideas to explore. The second one was better structured but look a little bit sad. The third one was almost good and the fourth one consisted of adding small improvements to make things more beautiful. We grabbed feedbacks from different people we know to help us taking decisions. Finally, we integrated the result. Now, we can say that it does the job. Displaying our logo on all our materials and on our public accounts (github, twitter…) gives us credibility and the conversion rate of our website is really high: almost 50% of our visitors suscribed to Cozy Cloud.

Community

Our product get ready for technical people who would like to self-host their Cozy Cloud. At the same time we decided to start our interns hiring campain. So we advertized softly to French students about what we do and  get in touch with the French free software community.

Because Cozy Cloud is a platform on which people can build their own application, we worked on providing all necessary materials about where to start to build on : starting template, Getting Started Guide, and a little tool to make deployment easy.

That led us to three recruitments and a first contributor who built two Cozy apps for his own needs (bookmark and feed manager). By the way we are going to hire one our interns of from the last session for a one year contract.

Partners

Aside from that we built partnerships: we are getting closer to GnuSide a company that work on a similar project as Cozy Cloud, called FirstBrick, but more oriented on the hardware aspects. The FING, an organization that analyzes impacts of new technologies on our day-life will probably hire us to help them. They have a project called “Mes Infos” that could be compared to the MiData project. They want to make experimentations around personal data, so our personal cloud solutions could fit well with their project.

Communication

We sponsorized one event, JDLL, and held a stand there where we met a lot of new people and grabbed again a lot of feedbacks. We also made some contacts to sponsorize other events (JS community). Aside of that, we prepared the first series of blog posts that will define our mantra and that will serve us as references for all our communication materials.

Conclusion

Communicating about the product is mandatory for adoption. It takes a lot of time and should be thought since day one. What I learned too is that communication starts with yourself: giving a face to what you are building strenghten your motivation and make your ideas clearer. By the way, it made official the first steps of our mission: make the web a better place.

Building a startup: remote working (june – august 2012)

Context

The past three months had been quite busy and dedicated to build our MVP. For that we hired a team of interns. They were 9 but let’s consider they were only 6. 3 of them were working on a side project and didn’t work directly with us. About the product, we aim to provide personal cloud to our customer on which they can install apps as easily as on their smartphone, “self-hosting for everyone” if you prefer. To make it possible we had to meet three key milestones :

• a website on which people suscribed
• an hosting infrastructure to host instances of our product
• the product himself: a web application that can manage other web applications

To achieve this goal we hired only interns with a technical background. They had partial knowledge of our techno and some were totally beginners.

Organization

We wanted to let people working remotely if they desired it. They all wanted it. So we customized our organization:

• Daily meeting each afternoon where everyone tells what he did last day and what he is going to do (Skype).
• Weekly personal meeting to describe the sprint of the week (Skype)
• Virtual Kanban always up to date (Trello)
• Q&A forum to share the answer of common problems (OSQA)
• Founders acted as coordinators, product owners and developers
• Specialist organization : one man, one project (they just stayed for 3 months, no need to make them work on different projects)
• Regularly we did small workshops to resolve issues and make some formations and small demos (Mikogo)
• IRC channel for non work-related discutions
• Internal social networks for link exchange (Newebe)
• Code review through Github
• One corporate week-end where we climb up a mountain in South of France

 

What was produced

We are really happy of what have been done so far. We were pleasantly surprised that young developers could do so much:

• All our internals tools are properly setup (we self-host most of our tools)
• Our website is ready to receive suscriptions and follow a good architecture (full django stack : nginx, gunicorn, mongo, celery, redis…)
• We can create personal clouds automatically from the admin UI of the website
• We built the first versions of three apps that are available on our platform: a note manager, a todolist manager and a mail aggregator
• The application manager of our product is ready
• We did some R&D on how to make our infrastructure more scalable
• We have a development process and a continuous integration woking on
• We studied a lot of technos
• We still keep doing interviews and making our network grows
• The administrative necessities to make our company official is on the good trajectory
• Our product is now up and running

 

Conclusion

We really enjoyed this working experience.  It made our life easier. Of course it requires passionate people and that founders stay close to help others to keep on progressing on their subjects.  Fortunately we hired great players. In addition, the sportive corporate week-end  was a great experience in strengthening our team spirit. Demos were really good too, we regret to not have settled them earlier !

Today we are still working in this mode but with a smaller team. To finish this post, you will find our list of pros and cons of this. If you have advice or similar experience like this one feel free to share it with me via email or in the comments.

Pro

• It works efficiently, the distance pushes to communicate more and better than if we were in the same place
• Less constraints for everyone
• Self organization resulted in less stress
• No need to track our employees, the shame to say that “I did nothing” at the daily meeting is enough
• It’s attractive for hiring, specially for developers
• Demos times are great

Cons

• We were surprised that our collaborators never used IRC and very few the social network
• Tools like Skype are good but frustrating when people have bad connection
• It is not for everyone, one of our interns didn’t enjoy the experience.
• It’s not the perfect case for people who needs long formation
• Sometimes it feels a little bit odd to spend so much time at home
• It was a challenge to make to everyone understand what others were doing

Newebe @ LSM

Hey, I will be at Libre Software Meeting 2012 (aka RMLL) where I will hold two ligthing talks!

• The first one will explain why Newebe is different from other social network, monday 12:15.
• The second one will be about my startup project, Cozy Cloud, and will give you some hints on how to make organic web apps, tuesday 12:05.

See you there !

Building a startup: the beginnings (march – may 2012)

Three months has passed since my last blog post about the startup I’m working on. This period started roughly with one of our partners depart. It reduces our founder team down to two people. We had to lower down our expectations and things moved in a slower pace. To deal with that, we hired a consultant to help us. We succeeded in building the required infrastructure to serve our minimum viable product. This small victory gave us courage and led us to find people that could help us in the launch of our project. More details in the following.

1. Infrastructure

Startup is a lot of fun but it is also a matter of money. Because our business will be based on hosting, most of our efforts these last months were focused on the infrastructure. We had quite rough time : system administration is not our specialty. Which led us to hire a consultant to help us in this quest. We discovered the joy of virtualization, isolation, automated deployments…  and met our goal by building a decent and simple starting infrastructure with perspective to build a more scalable one as soon as our customer base will grow.

What I learned from this  is that your infrastructure should be led by automatization. Once you understand what should be done, make script of everything you do. Another advice I would give is that you should virtualize every installation to avoid breaking things on your host box. This has other advantages: you can sandbox installations easily, duplicate them or move them to another box quickly. Take also a look at Vagrant  to experiment your script safely on your local machine.

2. Product

About the  product itself, we made profound progress. Our code base grows fast and main components are there. We also set up a simple continuous integration process and got familiar with our technology choices. Next month will be focused more on software development. We will start our beta program with close friends, so we will be able to make the right choice about feature development.

3. New tools

By the way we added new tools to our previous list :

• Jenkins for our continuous integration
• Osqa Q&A (question forum) for our beta users to have a feedback place
• Osqa Q&A for our team to make a dynamic FAQ of our tools.
• Newebe for our internal social network.
• Google apps for our mailing stuff.

Chosing and setuping tools take a long time, I wish I had a ready to go list and some magic stuff to set them up automatically (such as OpenVz templates for each common technologies).

4. Interns hiring

Benjamin, my partner, felt that we need more backup to deal with the amount of work. So we hired several people as interns from his former university to help us by doing technology studies and short developments. One of them will stay for a longer time and has great system administration skills. As you might guess, he arrived on time to consolidate our infrastructure and help us in a significant way on other system administration stuff.

As we have not yet an office space, for the moment every one will work from home. I hope it will be a great experience. I will provide feedback about that in my next startup blog posts.

5. Events

We were present at many great events and met a lot of people working in the same fields as us. What I learned, is that going to an event is always a hard choice. When you are there you don’t make direct production. The pros is that it provides opportunity to find collaborators and grab some feedback on what we are doing by explaining what we do. Moreover events can teach various helpful subjects and make you discover new technologies.

My advice would be to not go to all of them, and try to go there with a goal in mind (learn something, intensive networking…).

That’s all for now. In my next startup posts I will tell you how our beta program goes, what our product does and how we organize with our new development team.

Feel free to react in the comments section.

Building a startup : the beginnings (january – february 2012)

Two months ago, I joined my actual partners, Benjamin and Jonathan, for the long journey of a startup creation. Because, I like to share what I do and what I thought about software developments, I’m going to do the same about entrepreneurship and share my point of view on what we do. For this post, I won’t talk about the product and will focus more on the organisational aspects.

1. Thoughtland

Before meeting each other, we were in the wonderful world of thoughtland: we talk about ideas around self-hosting with our friends and we tried to anticipate the trends of the web. Worst, we were dispatched and did not know each other yet. The debate is wide and exciting and this phase is good to initiate our vision but the risk is to stay here too long and guessing too much on what does not exist. Fortunately, we like to get things done. First move: Benjamin hired partners.

NB: Thoughtland, I found this word from Pretotype It – The book

2. Hiring partners

After much reflection, Benjamin, who knows clearly what he wanted to build around self-hosting (he scratched his own itch and find a solution to a problem) decided to gather people to help him. First he used a classic and efficient technic : rely on people from his network. That led him to Jonathan, a brilliant developer  who graduated a year ago and had some experience with startup : one more builder for his team.

But finding the right people who are available and share your vision is not the easiest thing to do and sometimes network is not enough. To take things to the next level, Benjamin has several criterias: be interested in the web, desire for entrepreneurship, technical skills, availability, network… That’s a good start but then what’s next ? To make things happen Benjamin had a clever idea which costs almost nothing. On a blog post talking about cloud applications and  their privacy issues he left a comment telling approximately this: “Stop whining, do something. I’m building a company on self-hosting, if you are interested contact me.” Head shot: I answered.

By posting a comment on this blog post he knows that he will have very few answers but the conversion rate of his answers would be high: only people who are concerned by the problem and motivated to do something would answer to this kind of message.

NB: Head shot is a FPS video game reference, it means you did a risky, precise and efficient shot.

3. Organize

One of our problem is that we don’t have an office. Moreover we don’t know each other very well. So, how do we deal with that ? One solution, meetings :

• One 4 hour meeting each monday in a coworking place : that is not a very productive meeting, but it is a way to learn to interact and work together.
• One online daily meeting where people report what they do and what they are planning to do. Ideally we say no more unless we had a serious issue to deal with.

For the rest, we send emails without expecting fast answers to not force others to check their mailboxes too often.

4. Tools

To do all of our tasks, we studied several kind of tools. We tested a lot of them quickly and looked for two characteristics : simplicity and cost efficient. I started with a short list. Then I gave it to my partners who reduced it. We chosed our tools as in an agile way : use the easier to start with so we will be able to modify it easily when needed. Then we finally decided to use the following ones :

• Skype : for our online meeting
• Github : code repositories and ticket issues
• Gollum : our wiki, integrated to github and easily movable if we want to host it.
• Trello : kanban tools that we use with one board of three columns (to do, doing, done) for our daily meetings .
• Jekyll : lightweight blog engine

5. Find an incubator

To be introduced to the French startup world, to meet more people and be visible to VCs, a good start is to be selected for incubation. It offers also us a small office, workshops and better access to public funds. Incubator is not mandatory but it helps a lot. Moreover, preparing the presentation to be selected, push you to think your company under the main aspects. This is really a good exercise. The only bad point is that they ask silly things like 3 years business plan. Wake up, this is a tech startup !

6. Action

Thinking and preparing good work conditions is a good thing, but he does not lead you to a viable product. So we started to focus on that. We had a great workshop with Stéphane Bagnier which explores the fundamentals of lean method. That motivated us to interview potential users and build a pretotype. Which is what we are working on right now. We also built a fake door (not online yet) to grab some emails and validate our message.

NB: Fake door is also a word from Pretotype It – The book, it is a website where you can suscribe like on any other web application, but after you suscribe a message tells you that te product is not ready yet.

Conclusion

I also didn’t mention administrative stuff and analyses/discutions like “bootstraping or not”, technology choices, vision, etc. Both are time consuming too but it fills up our wiki with a lot of useful informations. Finally, I am glad we arrived at that point after two months. We put the rails on our path to the minimum viable product : now we can focus on it.

Making a choice : what about building a startup ?

Two months ago, the company that employed me closed. It leads me to make a choice on what to do next. Being unemployed for a software developer of my age is not a big issue. I have a good working experience and developer skills interest a lot of people. So I am lucky enough to chose between several ways. I list what are those ones and why I decided to chose the last one.

1. Finding a job as a developer

With Newebe and my last job, now I can tell that I have a decent portfolio. So, finding a job in an exciting company is a possibility. I can say I like to deal with technical problematics, so working on another project is a nice path. But It requires to come back in recruitment process, something I don’t like at all. Moreover it is a little bit the lottery and I am not sure to find people that trust the same principles as me.

2. Finding a job as a project manager

I have both an experience as a business analyst and developer and I work since 6 years. So it could have been a good idea to look for a promotion as a project manager. It would be a good carrier choice. On the opposite, being hired would be harder.

3. Finding a job in another field

With BeBurlesque, I met a lot of people from other fields : event organization, fashion, edition, press relation… To get hired in one of those would be really harder but not impossible. They have some interests and could offer a great new experience. Unfortunately they require a lot of energy and a lot of communication skills and I’m not sure that I feel enough passion to struggle to get in one of them.

4. Travelling

Toughest choice from far. I really enjoyed my trip in Laos and met a lot of travellers who explained me how they can travel for so long without having a lot of money. I have enough cash now to travel for several months very comfortably. By the way, when I was in Laos my health improved a lot : no more back problems, no more insomnia, no more skin problems, a better physic condition and overall, my moral rose from under the ground to the sky.
I could also do some coding stuff while traveling, so Newebe could be improved during that time and my dev skills stay up to date.
The bad part is that when I will come back, things won’t be easy. Whatever solution 1 would still be available.

5. Start a new company

This is also a good opportunity. First I am available. Second I have enough cash to not be paid during several months. Thanks to our unemployment insurance, I will have additional funds. This added to my own funds gives me the equivalent of 1 year and a half of a decent salary to survive until this company earned enough money to pay me.
The other good part is that I met two partners who wants to make something about self hosting through a startup. If you read this blog, you know how far I am concerned by the subject.
I am also still young (29) and have no children. So, if it fails I still could go to choice 1 or maybe choice 4.

As you understand I have a big opportunity to build something new about web and self-hosting. My last startup experience was hard emotionally, but I have very good memories too. So I think I want a litte more. And because when things sounds good, they should be listened, I will try this path, hoping it is the best one.

The Lean Startup, revue de livre

Voilà un livre que j’étais très enthousiaste de recevoir. En effet, en ce moment que ce soit en bien ou en mal, on entend parler de la méthode Lean un peu partout. Dans le monde des startups informatiques ce thème revient même très souvent. Mais qu’a cette méthode de particulier ? Elle repose sur les principes suivant : il faut éliminer toute action inutile, chaque réalisation doit prouver son efficacité et permettre de progresser vers le succès (validation par l’apprentissage) et il faut se poser régulièrement la question de changer d’orientation ou de persévérer. Voilà en très résumé ce que raconte ce livre de 300 pages. Oui 300 pages pour expliquer ça c’est un peu beaucoup, l’auteur aurait pu faire plus concis. Heureusement il n’y a pas que du blabla, Eric Ries, l’auteur, nous expose beaucoup d’exemples concrets (expérience personnelle ou cas rencontrés en tant que consultant). Ce qui a tout de même pour avantage de rendre le livre assez convaincant.

Revenons à la méthode Lean. Pour que les choses soient claires, Eric Ries, ne recherche que la croissance maximum. On est donc pas dans le “Why grow ?” de 37signals. Pour cela il faut commencer de petit avec un produit minimum (MVP, Minimum Viable Product) afin d’avoir au plus vite des retours utilisateurs . On commence ainsi au plus tôt l’apprentissage. Comme pour lui les utilisateurs ne savent pas toujours ce qu’ils veulent, il ne va pas se contenter de leur poser des question, il va aussi analyser leurs réactions. En créant des indicateurs pertinents (évolution du taux de conversion par exemple) et en mettant de côté les indicateurs vantards (nombre de visites par exemple pour un site de produit payant) il va valider ou non l’ajout d’une feature, la modification d’un design, etc… Il conduit clairement des expérimentations pour définir la marche à suivre et n’hésite pas à revenir en arrière si ça n’a pas fonctionné. Pour que cela soit possible, il préconise de n’avancer que par petits pas et de travailler en petite équipe. Ainsi le retour en arrière est moins douloureux s’il doit avoir lieu. Après ça il continue sa progression jusqu’à ce que ça commence à coincer (croissance ralentie). Là il se pose la question, doit on continuer à améliorer l’existant ou doit on changer de positionnement ? Là il compte plus ou moins sur son instinct et ses résultats précédents pour faire son choix, puis il recommence le cycle.

NB : Pour les logiciels cloud, il prône la méthode du déploiement continu. Chaque modification passe en production rapidement. Il ne juge pas ça risqué car si un bug est mis en prod (malgré les tests automatiques) il sera facilement identifiable et corrigé rapidement car on peut relivrer tout de suite après.

Le concept n’est pas idiot même si je trouve ça gênant de prendre ses utilisateurs pour des rats de laboratoires. Autre point qui me pose problème, c’est qu’il prétend que c’est comme cela qu’on obtient de l’innovation. Alors que pour ma part, je ne trouve pas ce concept vraiment compatible avec l’innovation. Innover c’est parfois changer les habitudes et je ne suis pas sûr que les réalisations impliquant du changement soient “validées” par sa méthode. A l’inverse le bon côté de ce qu’il propose est que ça permet de diminuer les risques d’échec puisqu’on est sûr de développer ce que les gens veulent.

Ce livre présente aussi quelques trucs et astuces, comme la technique des 5 pourquoi. C’est un principe qui vient de Toyota (oui j’oubliais la plupart des principes Lean prennent leur source dans les manufactures Toyota qui avait pour principe de faire des voitures d’un seul coup et non par étapes. Cela leur permettait de mieux gérer leur stock de pièces et de se rendre compte plus vite s’il y avait un problème dans la chaine de production). Les 5 pourquoi qui consiste à analyser les problèmes en profondeur plutôt que de les attribuer à leur cause direct. Pour cela on réunit toutes les personnes impliquées depuis le début jusqu’à la fin de la chaine, management compris et on se pose 5 fois la question pourquoi. Ex : Jhon déploie une feature buggé. Pourquoi la feature est buggée ? parce que Jhon l’a déployée. Pourquoi Jhon a pu déployer une feature buggée ? parcequ’il n’avait pas fait les bons tests. Pourquoi n’a-t-il pas fait les bons tests ? Parcequ’il n’avait pas les bons outils, etc…

En résumé, c’est un livre très intéressant à lire (ok un peu chiant par moment) qui propose une méthode qui se tient avec comme bémol le côté expérimentation sur les utilisateurs.

Je me permettrai aussi une remarque : le principe de travailler avec des petites tâches et en permanence peut être assez épuisant pour les employés. En effet il n’y a plus jamais de pause comme on peut en trouver à la fin des projets ni même d’objectif conséquent à atteindre. A mon avis, il faut donc penser à aménager l’organisation du travail en conséquence : congés forcés, pas d’heures sup et petites victoires régulières me semblent obligatoires pour éviter manque de créativité, burnout ou lassement prématuré.

Start Small, Stay Small

Start Small, Stay Small,  un titre qui s’annonce bien, qui fleure bon le 37signals. Ca se confirme avec la couverture toute noire et son titre en blanc : on croirait presqu’un remake de Getting Real. Alors oui il y a des similitudes : notamment sur l’objectif qui est de vous apprendre à monter un business en vous passant d’investisseur, de “bootstrapper”. Par contre le but ici n’est pas de monter une boite conséquente, ni même d’embaucher quelqu’un (en fait rien n’empêche de le faire mais là le bouquin n’offre plus de conseils pour cela). L’idée cette fois consiste à monter une ou plusieurs micro entreprises vendeuses de logiciels et d’en gagner sa vie.

Là ou c’est intéressant c’est que l’auteur fournit plein de trucs pratiques pour arriver à ses fins. Un exemple : il fait de la publicité pour un produit qui n’existe pas. La pub renvoie sur une page de lancement où on peut laisser son mail. En fonction du nombre de gens qui laisse leur adresse et du nombre de visites, il en déduit si le logiciel en vaut la peine.

Là ou c’est trompeur c’est que ce guide pour développeur parle essentiellement de marketing. L’auteur juge qu’il n’a rien à apprendre à ses lecteurs dans le domaine du développement, donc il ne se concentre pratiquement que sur les moyens de ramener des visiteurs. Ca se tient. Il en résulte de bons tuyaux, il est assez convaincant sur la nécessité des newsletters par exemple mais à un moment ça devient exagéré. Par exemple, avec son blog et sa newsletter, il va cumuler des petites techniques pour attirer du monde : envoyer des contenus réguliers, faire intervenir des experts… Présenter comme il le présente ça donne l’impression qu’il essaye de gratter partout, alors qu’en prenant un peu de recul, il fait juste quelquechose de naturel : apporter des informations autour de son produit afin que ses utilisateurs puissent réagir et apprendre des nouvelles choses, un peu le “Build an audience” de Rework. C’est un peu dommage que ce soit fait dans cet état d’esprit.

Là ou c’est dérangeant c’est que pour couronner le tout, l’auteur fait l’éloge des Virtual Assistants ou VA. C’est quoi ? me direz vous. Un VA est simplement un type, qui n’a rien de virtuel au passage, à l’autre bout de la planète qui accepte de faire des tâches ingrates pour pas cher, comme saisir un listing par exemple. D’un point de vue totalement pragmatique c’est assez intelligent : pour peu d’argent on économise de nombreuses heures de travail. Mais éthiquement, on est à peu près à 20 000 lieux sous les mers.

Bref ce livre comporte pleins d’astuces utiles, mais son obsession marketale en fond un tout assez triste. A manipuler avec précaution.