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

Advertisements

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 !

Image

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.