On est combien déjà ?

Sur une plaquette commerciale, une entreprise peut avoir l'air parfaitement organisée.

Il y a des services. Des compétences. Une méthode. Parfois même une présentation qui ressemble à celle d'un grand groupe.

Puis on retourne dans les coulisses.

Et on se pose une question assez drôle : on est combien, exactement ? 😄

Quand on lance une petite activité numérique, une même personne peut se retrouver à discuter avec le client, concevoir l'interface, développer l'application, envoyer la facture et répondre au message « ça ne marche pas ».

Je connais bien ce mélange. Il fait partie de ce que j'essaie de construire avec KAMIT.

Une entreprise ne commence pas forcément avec une équipe

On imagine parfois l'entrepreneuriat à travers des bureaux, des réunions, des collaborateurs et un organigramme.

Mais au départ, il peut surtout y avoir une compétence, un ordinateur et un problème qu'on pense pouvoir résoudre pour quelqu'un.

Les premières étapes sont loin d'être glamour : présenter son offre, écouter un prospect, rédiger une proposition, tenir ses engagements.

Puis il faut faire le travail.

Et quand c'est fini, il faut encore expliquer, former, corriger et assurer le suivi.

La partie technique n'occupe pas toute la place. Elle n'est parfois même pas la plus difficile.

Le problème des casquettes

Être polyvalent est une force au départ.

Comprendre le développement aide à évaluer une demande. Connaître un peu le design améliore la présentation. Savoir communiquer facilite la discussion avec les clients.

Mais les casquettes finissent par se gêner.

Quand je code, je ne prospecte pas.

Quand je réponds à des messages, je ne termine pas cette fonctionnalité.

Et quand je travaille sur une proposition commerciale, je ne fais pas avancer le produit que j'aimerais lancer.

Ce n'est pas seulement une question de temps.

C'est le coût mental du passage permanent d'un rôle à l'autre.

Ce que le client ne voit pas

Prenons une demande de site web.

Le client découvre les pages, les images et les boutons.

Derrière, il y a le recueil du besoin, le choix d'une architecture, les contenus, les corrections, le référencement, les réglages d'hébergement et les vérifications avant mise en ligne.

Après la livraison, il peut encore y avoir des modifications ou des problèmes à résoudre.

Tout cela doit être compris, cadré et facturé correctement.

J'en parle aussi dans Le rêve du petit SaaS.

Un projet rentable n'est pas seulement un projet qui a été payé. C'est un projet dont on comprend les efforts, les risques et la maintenance.

À quel moment faut-il s'entourer ?

Il serait tentant de répondre : « Dès qu'on a beaucoup de travail. »

Mais recruter ou sous-traiter demande aussi du temps, de la trésorerie, des consignes claires et une manière de vérifier la qualité.

Avant de déléguer, il faut parfois commencer par documenter.

Quel résultat attend-on ? Quelles parties peuvent être confiées à quelqu'un d'autre ? Comment transmettre les accès sans créer de risque ? Qui parlera au client si quelque chose se passe mal ?

Ces questions sont moins excitantes qu'un nouveau projet.

Elles sont pourtant indispensables pour ne pas rester éternellement le point de passage de tout.

Le vrai objectif

Mon ambition n'est pas de porter le plus grand nombre possible de casquettes.

C'est de construire une activité capable d'apporter de la valeur sans dépendre en permanence de chaque minute que je peux lui donner.

Je n'y suis pas encore.

Pour l'instant, j'expérimente, je structure et j'essaie de progresser entre les projets clients et mes propres idées.

Parfois je suis le développeur.

Parfois le commercial.

Parfois celui qui doit rappeler au développeur que le commercial a promis une livraison.

Le plus drôle, c'est qu'ils sont tous les trois dans la même pièce. 😂