Quelle est la différence entre produit et side project

1. Ne pas écouter ses utilisateurs (car le produit n'est pas fini)
2. Se concentrer sur les fonctionnalités aux lieu de prototype technologiques, surtout lorsque cela est fait par des tech/devs.
3. Un produit demande plusieurs corps de métier à l’œuvre. La vente est importante, ou des compétences légales ou financières.

Un side project c'est un projet qu'on réalise à côté, le soir, le week end. C'est un extra en dehors d'une autre activité. On le fait sans contraintes en mode best effort. Et si j'arrive à une conclusion désormais, c'est que dans beaucoup de sujets, le mode best effort c'est le meilleur moyen d'échouer.

Bref, pour caricaturer, il y a donc deux extrêmes qui ne marchent pas :

• le mode best effort, sans moyen, sans temps alloué
• la profusion de moyens et l'absence de contraintes

Et pour transformer un side project en produit, il faut viser la solution médiane : être à 100% et avoir des contraintes.

1. You have multiple hats: separate them. Split up the design tasks from the implementation tasks.
2. Know your environment, fit in your team
3. Do hero mockups before implementation
4. Use Design Briefs to keep track of raw notes and decisions.
5. Design system helps to be more productive
6. Research: focus on the 20%. 80% of what a good designer does should be usable.

We have a broad array of tools at our disposal. Use them! Only the right tool for the job.
Low fidelity can be better than no fidelity.

1. It takes longer than you think
2. Go all-in sooner (part-time is helpful to test an idea).
3. Make direct sales (don't think about scaling).
4. Choose a niche.
5. Focus on product quality, and talk to your customers.
6. Build a culture of execution.
7. Don't underestimate deliverability and fraud.
8. Meet customers and partners in person.
9. Use workshops to create urgency.
10. Move from a cost center to a revenue center.

SASU, Portage salarial, Micro-entreprise, SASU pour en tirer un SMIC + dividences, EIRL ou EURL.

The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

And an eloge of Lisp, or in the world of startups, the art of doing things differently.

1. Outline your why
2. Outline your purpose
3. Outline your mission
4. Outline your customer
5. Outline your culture
6. Outline your vision
7. Outline your north star metric

Un retour d'expérience littéraire ❤️

Ulti­ma­tely, the value of plan­ning isn’t that you execute the plan perfectly, that you catch every detail befo­re­hand, or that you predict the future; it’s that you enforce the self-disci­pline to think about the project in some depth before diving in and seeing what happens. […] The plan itself, howe­ver accu­rate it turns out, is less impor­tant than spen­ding time on the act of plan­ning. »

I totally agree. It is god damn hard to make accurate estimations about software development, because it is hard to know what will work or breaks and because the specifications are never complete until the full development

J’ai souvent eu cet échange avec les leads et les staffs. Oui, tu l’as dit. Oui ça n’a pas fonc­tionné. Ce n’est pas que tu es impuis­sant ou que les personnes sont de mauvaises volonté. Ce n’est même pas un échec. C’est qu’il va falloir le répé­ter, le répé­ter, et le répé­ter encore.

Facture 2x plus cher, quitte à échouer à signer la moitié de tes pros­pects

Le corol­laire que j’ap­plique : Si la très grande majo­rité des pros­pects signent, c’est que tu n’es pas assez cher.

#Feedback d'un freelancer en développement web

Son parcours:

À New York:

« Et bien déjà, de combien de développeur as-tu besoin ? » « Une trentaine. » « Trente développeurs Ruby ? Et pourquoi faire ? Et combien es-tu prêt à les payer, tes développeurs ? » « $150 000 par an. » « Personne ne viendra travailler pour toi à ce salaire. Les développeurs peuvent avoir des salaires équivalents dans des petites sociétés. Pourquoi viendraient-il travailler dans une grosse société de finance pour gagner aussi peu ? »

Après être revenu des USA, il s'est rendu compte que ses compétences ont plus de valeurs que ce qu'il pense.

Le contrat au forfait est inadapté au monde du dévelopement: à partir du moment où le contrat est signé, les intérêts du client et du freelance divergent immédiatement. Le contrat à l'heure est préférable.

Le point clé consiste simplement à être transparent, totalement honnête avec son client. Si vous pensez que travailler au forfait se passe toujours mal, et que vous comprenez ces raisons (d’ailleurs cela vous est probablement déjà arrivé à vous, en plus des nombreux témoignages qui abondent sur le sujet), il est de votre devoir de prendre le temps et l’énergie pour expliquer cela à votre client. [...]

Avantage pour le client:

• les temps passées sur chaque choses sont justifiées
• les fonctionnalités onéreuses mais qui apportent finalement une faible valeur ajoutée sont démontrées
• si une demande est hors du domaine d'expertise, un spécialiste peut être recommandé afin que le prix sois moins cher, et elle sera mieux réalisée

Avantage pour le freelance:

• le travail est payé à sa juste valeur
• après avoir passé du temps sur un problème non-anticipé, le freelance devra contacter le client pour lui expliquer son erreur, et que cela risque de lui coûter cher, pour une valeur ajoutée faible: s'il désire tout de même la réalisation de sa demande, alors le freelance pourra l'accomplir pour sa juste valeur. Le client aura dans tout les cas conscience de la difficulté et de la valeur de ce travail.
• facturer les heures permet de travailler moins, car la concentration doit être maximale sur ces heures. Le client doit donc faire travailler le moins possible.

Les bénéfices du travail en précarité: il n'y a pas de contrat d'exclusivité: le contrat peut être annulé des deux côtés à n'importe quel moment. En pratique, il est indispensable de faire des efforts afin de travailler ensemble et de se comprendre. La précarité empêche d'endormir ces efforts. Ainsi le freelance apporte la garantie qu'il fera son possible afin de garantir la bonne marche du projet; et le client s'engage de même.

Le système est donc gagnant pour tout le monde.