#BuildInPublic 🇫🇷
Un échec: Lancement d’un service de tests techniques
Jeanro Krupa
Jeanro Krupa
4 min read
La génèse
Il y a maintenant 1 mois m’était venu l’idée de lancer un service de préparation aux tests techniques.
L’idée était simple: pour éviter aux devs Juniors de fail leurs premiers tests techniques. Je les fait passer par un “faux” process de recrutement. Call avec le recruteur, test en livecode puis test asynchrone, code review, feedbacks… Étant donné le temps que cela me prends de faire le process complet le pricing est de 150 €.
Pour tester ce service ne sachant pas trop ce que cela allait donner, j’ai créer une landing page que je vais garder pour la prospérité 😅. La page assez simple détaillant le service avec un email caption pour qu’en le service sera lancé.
Résultats
J’ai pu récolter une soixantaine d’emails. Ce qui n’est pas si mal compte tenu de la niche Ruby + Junior. Après avoir préparé quelques tests maisons j’ai pu faire ma campagne email en mode: “C’est bon c’est prêt! il n’y a plus qu’à payé et c’est parti”
Sur 60 emails, 0 clients 🤯. Je ne m’attendais pas à 50% de conversion mais quand même 😂. Du coup j’ai essayé de comprendre pourquoi voici les 3 raisons majeures:
- C’est beaucoup trop cher.
- Tu demandes de payer sans qu’on puisse tester
- Finalement je m’entraine sur codewars
Les choix possibles quand tu constates ton échec ?
option 1: Persister 💪
Persister voudrait dans ce cas passer 1 à 2 semaines à coder un système de tests complet: Création d’un compte, paiements, créer les tests, créer les corrections…
option 2: Passer en gratuit pour voir 💰
Cela fonctionnerait tout de suite beaucoup mieux mais demande beaucoup de temps. Temps que je ne passe pas à faire autre chose.
option 3: Laisser tomber 😢
Cela fait toujours mal de laisser tomber, cela touche à la fierté, l’ego et on a toujours une petit voix dans la tête nous disant mais si ça peut marcher.
Je suis sûre que pleins d’entrepreneurs sont passés par là avec ces 3 options. Dans beaucoup de cas je conseillerais de persister un peu plus, itérer, faire plus de discussions avec des users… Mais dans mon cas j’ai abandonné pour opérer un refocus et comprendre (enfin) une évidence la loi de Pareto de RubyOnRailsJobs.
La loi de Pareto de RubyOnRailsJobs
Tous les projets ont une ou 2 “feature” de Pareto (80 % du traffic, des ventes, inscriptions… générés par 20% des features du produit). Hunter.io chopper des mails à partir d’un nom de domaine, Oqoro comme Boursorama la digitalisation d’une agence en ligne, Enerfip crowfunding de la transition énergétique, WedressFair vendre des fringues éthiques.
Le fait d’avoir lancé ce nouveau “service” m’a fait me (re)rendre que 80% des utilisateurs viennent sur RoRJobs pour le job board dédié à Ruby que ce soit pour publier un job / une mission freelance ou consulter les offres.
Le problème quand on est dev et qu’on lance un side project c’est qu’on préfère coder de nouvelles features qu’optimiser ou marketer les existantes 😅
Dorénavant 80% de mon temps consacré au projet doit servir à optimiser le job board et sa mission: matcher des devs Ruby avec des boites cool. Cela semble super évident mais lorsqu’on entreprend prendre du recul n’est pas toujours simple, se prendre une claque fait parfois du bien…
Donc les features sur lesquelles je devrais bossé sont:
- Optimiser le SEO du Job board
- Améliorer la recherche de job et les alertes emails
- Permettre d’apply via la plateforme (pour les entreprises)
- Communiquer plus sur les Devs en recherche
- Aller plus loin dans la description des boites
- Optimiser la recherche sur Mobile
- Publier sur Google Jobs
- Finir de tester l'app pour intégrer d'autres dev au projets