Τα περισσότερα προϊόντα σε πρώιμο στάδιο δεν αποτυγχάνουν επειδή η ιδέα ήταν λάθος, αλλά επειδή η ομάδα έχτισε τη λάθος εκδοχή της: πολύ νωρίς, με πάρα πολλές λειτουργίες, στο λάθος stack, μπροστά στους λάθος χρήστες. Η διόρθωση αυτού του μοτίβου είναι όλη η δουλειά ενός Fractional CTO.
Το πλαίσιο σε μία παράγραφο: (1) ορίστε τη μία ενέργεια του χρήστη που αποδεικνύει ότι το προϊόν δουλεύει, (2) διαλέξτε βαρετή, δοκιμασμένη τεχνολογία, (3) χτίστε ολόκληρες ροές από την αρχή ως το τέλος αντί για ένα επίπεδο τη φορά, (4) δώστε το νωρίς σε πραγματικούς χρήστες και (5) εξελίξτε το με βάση τα δεδομένα, όχι τις απόψεις. Το υπόλοιπο άρθρο εξηγεί τι σημαίνει κάθε βήμα στην πράξη και πόσο κοστίζει να το παραλείψετε.
Στη WeAreFabbrik δουλεύουμε σχεδόν αποκλειστικά με χρηματοδοτούμενες startups που πρέπει να περάσουν από μια επικυρωμένη ιδέα σε προϊόν έτοιμο για παραγωγή, χωρίς να κάψουν τον επόμενο γύρο χρηματοδότησης στη διαδρομή. Μετά από 50+ έργα σε SaaS, AI και πλατφόρμες B2B, το ίδιο πλαίσιο πέντε βημάτων έχει προκύψει ξανά και ξανά. Δεν είναι μαγική συνταγή. Είναι πειθαρχία, και είναι η διαφορά ανάμεσα στις ομάδες που παραδίδουν και στις ομάδες που γυρίζουν σε κύκλους.
Βήμα 1: Ορίστε τη μία ενέργεια του χρήστη που αποδεικνύει ότι το προϊόν δουλεύει
Πριν γραφτεί έστω και μία γραμμή κώδικα, κάνουμε μια άσκηση που σας αναγκάζει να επιλέξετε: ονομάστε τη μία ενέργεια του χρήστη που, αν δουλεύει, επικυρώνει ολόκληρη την υπόθεση του προϊόντος.
Όχι πέντε λειτουργίες. Όχι ένα roadmap. Μία ροή.
Για έναν πελάτη στο fintech ήταν: «μια μικρή επιχείρηση ανεβάζει ένα CSV με τιμολόγια και παίρνει βαθμολογία κινδύνου σε λιγότερο από 30 δευτερόλεπτα». Αυτό ήταν όλο. Σύνδεση χρηστών, dashboard, ρυθμίσεις, χρεώσεις, ειδοποιήσεις: όλα στο backlog. Η ροή της βαθμολογίας κινδύνου είναι το v1.
Αυτό το βήμα κόβει περισσότερο λάθος scope από οποιοδήποτε code review ακολουθήσει. Επιβάλλει επίσης τη συζήτηση που οι ιδρυτές αποφεύγουν: ποιες λειτουργίες είμαστε πραγματικά διατεθειμένοι να αφήσουμε έξω από το v1, για να βγούμε στην αγορά έξι εβδομάδες νωρίτερα; Σχεδόν πάντα, η απάντηση είναι «περισσότερες απ' όσες νομίζαμε».
Βήμα 2: Διαλέξτε βαρετή, δοκιμασμένη τεχνολογία
Οι τάσεις είναι δελεαστικές. Μόνο τους τελευταίους δώδεκα μήνες έχουν εμφανιστεί τουλάχιστον τέσσερα «προεπιλεγμένα stacks» πάνω στα οποία, σύμφωνα με τη συναίνεση του engineering Twitter, θα έπρεπε να χτίζετε. Τα περισσότερα από αυτά θα έχουν εγκαταλειφθεί, εξαγοραστεί ή ξαναγραφτεί πριν από το Series A σας.
Βελτιστοποιούμε για τρία πράγματα, με αυτή τη σειρά:
- Ευκολία πρόσληψης. Μπορείτε να αντικαταστήσετε οποιονδήποτε μηχανικό σε αυτό το stack μέσα σε τέσσερις εβδομάδες; Τα Postgres, React, Node και Python περνούν αυτό το τεστ. Οι μισές επιλογές τύπου «framework του μήνα» αποτυγχάνουν.
- Λειτουργική ωριμότητα. Όταν το stack χαλάσει στις 3 τα ξημερώματα, υπάρχει απάντηση στο Stack Overflow ή περιμένετε κάποιον maintainer στο Discord;
- Βάθος τεκμηρίωσης. Τα νέα μέλη της ομάδας εκπαιδεύονται με βάση την τεκμηρίωση, όχι με γνώση που υπάρχει μόνο στα κεφάλια των άλλων.
Γι' αυτό το προεπιλεγμένο μας stack είναι React + TypeScript + Node + Postgres για SaaS, μαζί με Python και τα καθιερωμένα εργαλεία ML όταν υπάρχει AI στο scope. Δεν είναι η πιο συναρπαστική απάντηση. Είναι η απάντηση που αφήνει την ομάδα να εστιάσει στο προϊόν αντί για το stack.
Βήμα 3: Χτίστε ολόκληρες ροές, όχι ένα επίπεδο τη φορά
Το πιο ακριβό λάθος που κάνουν οι ομάδες τις πρώτες έξι εβδομάδες: χτίζουν λίγο authentication, λίγο dashboard, λίγο API, λίγη βάση δεδομένων, όλα παράλληλα και τίποτα έτοιμο να παραδοθεί.
Εμείς χτίζουμε κάθετες «φέτες». Μία ολοκληρωμένη ροή χρήστη, φόρμα στο front-end, επικύρωση, API endpoint, εγγραφή στη βάση, απάντηση, ανεβασμένη σε πραγματικό περιβάλλον και λειτουργική από την αρχή ως το τέλος, πριν οποιοδήποτε από αυτά τα επίπεδα πάρει δεύτερη λειτουργία.
Τρία οφέλη αθροίζονται:
- Ο κίνδυνος ενοποίησης φαίνεται αμέσως. Οι ακριβές εκπλήξεις κρύβονται στα όρια ανάμεσα στα επίπεδα. Ανακαλύψτε τις την 5η μέρα, όχι την 50ή.
- Πραγματικά demos για πραγματικούς ενδιαφερόμενους. Μια ροή που δουλεύει κερδίζει μια παρουσίαση στο Figma, κάθε φορά.
- Η ομάδα μαθαίνει πώς γίνεται πραγματικά το deployment. Η παραγωγή δεν είναι ένα βήμα στο τέλος του έργου. Είναι κάτι που κάνετε την πρώτη μέρα, και ξανά τη δεύτερη, και κάθε μέρα μετά.
Αυτό είναι το μοντέλο λειτουργίας που εφαρμόζουμε στη φάση Build της διαδικασίας τριών φάσεων που ακολουθούμε. Είναι η φάση που τα περισσότερα agencies προσπερνούν, και οι περισσότεροι πελάτες μετανιώνουν.
Βήμα 4: Δώστε το νωρίς σε πραγματικούς χρήστες
Ένα προϊόν που δεν χρησιμοποιεί κανείς δεν είναι προϊόν. Είναι ένα πρωτότυπο με αυταπάτες μεγαλείου.
Πιέζουμε σε κάθε έργο ώστε το v1 να φτάσει σε πραγματικούς χρήστες, όχι σε φίλους, όχι σε συμβούλους, όχι στο κοινό του ιδρυτή στο LinkedIn, μέσα στις πρώτες οκτώ εβδομάδες. Ο στόχος δεν είναι ποτέ να τους εντυπωσιάσουμε. Είναι να μάθουμε τι λείπει σε σχέση με όσα υποθέσαμε ότι είναι σημαντικά. Είναι δύο διαφορετικές λίστες, και το κενό ανάμεσά τους είναι η αιτία κάθε εξάμηνης επανεγγραφής του roadmap.
Τα πρώιμα σήματα από πραγματικούς χρήστες αλλάζουν τη σειρά με την οποία χτίζεται το υπόλοιπο προϊόν. Λειτουργίες που έμοιαζαν επείγουσες πάνε στο backlog. Ειδικές περιπτώσεις που έμοιαζαν μικρές αποδεικνύονται ο λόγος ύπαρξης του προϊόντος. Το κόστος του να δράσετε με βάση αυτή την πληροφορία πέφτει 10 φορές όσο νωρίτερα έρχεται.
Βήμα 5: Εξελίξτε το με βάση τα δεδομένα, όχι τις απόψεις
Μόλις υπάρχουν πραγματικοί χρήστες στο προϊόν, το roadmap σταματά να είναι αντικείμενο αντιπαράθεσης. Τα δεδομένα χρήσης, τα αιτήματα υποστήριξης, τα σημεία όπου χάνονται μετατροπές και η συχνότητα των αιτημάτων για λειτουργίες αντικαθιστούν τη σύσκεψη όπου επτά άνθρωποι διαφωνούν για το τι θα χτιστεί μετά.
Σε αυτό το βήμα ο τεχνικός συνεργάτης αποδεικνύει την αξία του. Λειτουργίες μπορεί να χτίσει ο καθένας. Το δύσκολο είναι η πειθαρχία να μη χτίσετε τη λειτουργία που ακούγεται ωραία σε ένα pitch deck, και αντί γι' αυτήν να παραδώσετε εκείνη για την οποία σας μιλούν τα δεδομένα.
Βοηθάμε τους πελάτες να στήσουν νωρίς τα βασικά εργαλεία μέτρησης, product analytics, παρακολούθηση σφαλμάτων, δομημένα logs, ώστε όταν έρθουν οι πραγματικοί χρήστες, η ομάδα να μπορεί να διαβάσει τα σήματα αντί να μαντεύει.
Γιατί αυτό μετράει ειδικά για τις χρηματοδοτούμενες startups;
Αυτό το πλαίσιο δεν είναι μοναδικά δικό μας. Παραλλαγές του εμφανίζονται σε κάθε σοβαρό engineering playbook, από το Reforge μέχρι το Y Combinator. Αυτό που σπανίζει είναι η πειθαρχία να το εφαρμόσετε υπό την πίεση ενός περιορισμένου runway και ενός board που απαιτεί ταχύτητα στις νέες λειτουργίες.
Οι εταιρίες που επιβιώνουν μετά τον seed γύρο τους είναι σχεδόν πάντα εκείνες που αντιστάθηκαν στον πειρασμό να χτίσουν υπερβολικά πολλά τους πρώτους έξι μήνες. Όσες δεν αντιστάθηκαν είναι συνήθως οι ίδιες που ξαναγράφουν τον κώδικά τους 18 μήνες αργότερα, ακριβώς τη στιγμή που ο επόμενος γύρος τους εξαρτάται από το να δείξουν ανάπτυξη, όχι refactoring.
Αν είστε ιδρυτής με χρηματοδότηση που μετατρέπει μια επικυρωμένη ιδέα σε προϊόν έτοιμο για παραγωγή, και θέλετε μια senior ομάδα να εφαρμόσει αυτό το πλαίσιο μαζί σας αντί για ένα εργοστάσιο λειτουργιών που σας χρεώνει με την ώρα, κλείστε μια στρατηγική κλήση 30 λεπτών. Σε 30 λεπτά θα σας πούμε αν αυτό που χτίζετε πρέπει να ακολουθήσει αυτό το πλαίσιο ή κάτι διαφορετικό.
Σχετικά με τον συγγραφέα: Ο Κωνσταντίνος Τσολακίδης είναι ο ιδρυτής της WeAreFabbrik και δουλεύει ως Fractional CTO με χρηματοδοτούμενες startups σε όλη την Ευρώπη. Η WeAreFabbrik είναι μια εταιρία έμπειρων μηχανικών με έδρα την Αθήνα και το Ταλίν, που έχει παραδώσει 50+ προϊόντα AI, SaaS και αυτοματοποίησης από το 2018.