9 λάθη στην ανάπτυξη SaaS που βυθίζουν αθόρυβα τις νέες startups

Σχεδόν κανείς δεν χτίζει ένα προϊόν SaaS λάθος επίτηδες. Τα λάθη που βυθίζουν τις νέες startups είναι αθόρυβες, λογικοφανείς αποφάσεις που παίρνουν έξυπνοι άνθρωποι υπό πίεση — και όλες μοιάζουν σωστές τη στιγμή που λαμβάνονται. Έχουμε δει τα ίδια εννέα να εκτυλίσσονται σε δεκάδες προϊόντα, τόσο σε γκαράζ ιδρυτών όσο και σε καλά χρηματοδοτημένες ομάδες. Τα καλά νέα είναι ότι είναι προβλέψιμα, που σημαίνει ότι μπορούν να αποφευχθούν. Αυτή είναι η λίστα που θα θέλαμε κάθε ιδρυτής να είχε κολλημένη στην οθόνη του πριν γράψει την πρώτη γραμμή κώδικα.

Χτίζουμε λογισμικό για μικρές και μεσαίες επιχειρήσεις, που σημαίνει ότι μας καλούν σε δύο πολύ διαφορετικές στιγμές. Άλλοτε είναι η πρώτη μέρα, όταν δεν υπάρχει τίποτα παρά ένα σκίτσο και μια ιδέα. Πιο συχνά, δυστυχώς, είναι ο ένατος μήνας — όταν ένας ιδρυτής έχει ξοδέψει τις οικονομίες του, το προϊόν τεχνικά λειτουργεί, και όμως κανείς δεν πληρώνει γι' αυτό. Η δεύτερη κατηγορία κλήσης είναι αυτή που μας δίδαξε αυτή τη λίστα. Κάθε φορά, η νεκροψία αποκαλύπτει το ίδιο μικρό σύνολο πληγών, που προκλήθηκαν νωρίς και αφέθηκαν να μολυνθούν.

Κανένα από αυτά τα λάθη δεν αφορά το ταλέντο. Οι άνθρωποι που τα κάνουν είναι συνήθως ικανοί και εργατικοί. Το πρόβλημα είναι ότι το χτίσιμο SaaS ανταμείβει ένα πολύ συγκεκριμένο είδος αυτοσυγκράτησης που δεν έρχεται φυσικά όταν είσαι ενθουσιασμένος με τη δική σου ιδέα. Ας περάσουμε λοιπόν τα εννέα, περίπου με τη σειρά που τείνουν να δαγκώνουν, και ας είμαστε ειλικρινείς για το γιατί το καθένα είναι τόσο δελεαστικό.

1. Χτίσιμο για έξι μήνες πριν μιλήσετε σε έναν και μόνο πελάτη

Αυτό είναι το αρχικό αμάρτημα, και είναι το πιο ακριβό. Ένας ιδρυτής είναι πεπεισμένος ότι η ιδέα είναι καλή — και μπορεί να είναι — οπότε σιωπά, χτίζει με σκυμμένο το κεφάλι για μισό χρόνο, και αναδύεται με ένα γυαλισμένο προϊόν που κανείς δεν ζήτησε. Η αγορά δεν ανταμείβει την προσπάθεια. Ανταμείβει τη λύση ενός προβλήματος που κάποιος θα πληρώσει για να εξαφανιστεί.

Η λύση δεν είναι περίπλοκη, είναι απλώς δυσάρεστη: δείξτε κάτι πρόχειρο σε πραγματικούς δυνητικούς πελάτες πριν είναι έτοιμο. Ένα κλικαρόμενο πρόχειρο, μια σελίδα προορισμού, ακόμη και μια χειροκίνητη εκδοχή της υπηρεσίας μέσω email. Κάθε εβδομάδα χτισίματος πριν επιβεβαιώσετε ότι ο κόσμος το θέλει είναι μια εβδομάδα που ίσως ξοδεύετε διακοσμώντας ένα σπίτι σε λάθος δρόμο.

2. Χτίσιμο για ένα εκατομμύριο χρήστες που δεν έχετε

Το δεύτερο λάθος φοράει τη στολή του επαγγελματισμού. Ο ιδρυτής, ή ένας φιλόδοξος πρώιμος μηχανικός, σχεδιάζει το σύστημα ώστε να αντέχει τεράστια κλίμακα από την πρώτη μέρα — microservices, Kubernetes, βάσεις δεδομένων πολλαπλών περιοχών, περίπλοκα στρώματα caching. Μοιάζει υπεύθυνο. Στην πραγματικότητα, είναι παγίδα. Ξοδεύετε τον πιο σπάνιο πόρο σας — τον χρόνο — αμυνόμενοι ενάντια σε ένα πρόβλημα που θα ήσασταν τυχεροί αν είχατε.

Ένας βαρετός, μονολιθικός σχεδιασμός με μία βάση δεδομένων θα σας μεταφέρει άνετα στους πρώτους χιλιάδες χρήστες σας και πολύ πέρα από τα πρώτα σας έσοδα. Οι αρχιτεκτονικές αποφάσεις που έχουν σημασία στην κλίμακα σχεδόν ποτέ δεν είναι αυτές που μπορείτε να προβλέψετε στην αρχή, και η πρόωρη πολυπλοκότητα κάνει το προϊόν πιο αργό στην αλλαγή — που, στις πρώτες μέρες, είναι το μόνο πράγμα που πραγματικά σας σκοτώνει. Χτίστε για τους επόμενους δέκα πελάτες, όχι για τον φανταστικό εκατομμυριοστό.

3. Ένα MVP που δεν είναι ούτε ελάχιστο, ούτε βιώσιμο, ούτε προϊόν

Όλοι συμφωνούν να χτίσουν ένα MVP. Σχεδόν κανείς δεν το κάνει στην πραγματικότητα. Αντ' αυτού παραδίδεται μια εκτεταμένη «έκδοση ένα» παραγεμισμένη με κάθε λειτουργία που θα μπορούσε να φανταστεί ο ιδρυτής, επειδή η περικοπή λειτουργιών μοιάζει με περικοπή φιλοδοξίας. Το αποτέλεσμα παίρνει τρεις φορές περισσότερο χρόνο, κοστίζει τρεις φορές περισσότερο, και είναι πιο δύσκολο να μάθεις από αυτό — γιατί όταν ένα φουσκωμένο προϊόν αποτυγχάνει, δεν μπορείς να πεις ποιο μέρος ήταν λάθος.

Ένα πραγματικό MVP κάνει ένα πράγμα αρκετά καλά ώστε κάποιος να πληρώσει γι' αυτό. Αυτό είναι όλο. Η πειθαρχία δεν είναι να αποφασίσεις τι θα συμπεριλάβεις· είναι να αποφασίσεις τι θα αφήσεις έξω, ξέροντας ότι κάθε «προφανής» λειτουργία που αναβάλλεις είναι μια εβδομάδα που κερδίζεις πίσω και μια ερώτηση που μπορείς να απαντήσεις με πραγματικούς χρήστες αντί για εικασίες.

Ένας γρήγορος έλεγχος λογικής για το εύρος

Πριν μπει οποιαδήποτε λειτουργία στην πρώτη έκδοση, βάζουμε τους ιδρυτές να απαντήσουν δυνατά σε μία ερώτηση: «Αν παραδίδαμε χωρίς αυτό, θα αρνιόταν έστω και ένας πληρώνων πελάτης να χρησιμοποιήσει το προϊόν;» Αν η ειλικρινής απάντηση είναι όχι, περιμένει. Θα εκπλαγείτε με το πόσο από τη λίστα «απαραίτητων» λειτουργιών σας εξατμίζεται κάτω από αυτή τη μία πρόταση.

• Αν μια λειτουργία υπάρχει για να εντυπωσιάσει επενδυτές, όχι για να εξυπηρετήσει έναν χρήστη, περιμένει.
• Αν μια λειτουργία χειρίζεται μια ακραία περίπτωση που θα συναντήσουν λιγότεροι από 1 στους 20 χρήστες, περιμένει.
• Αν χτίζετε ρυθμίσεις για να παραμετροποιήσετε μια συμπεριφορά που κανείς δεν έχει ζητήσει να αλλάξει ακόμη, περιμένει.
• Αν το «ο ανταγωνιστής το έχει» είναι ο μόνος λόγος που βρίσκεται στη λίστα, περιμένει.
• Αν η αφαίρεσή του δεν θα εμπόδιζε ούτε μία πώληση, περιμένει.

4. Αντιμετώπιση της χρέωσης και της ενσωμάτωσης ως δευτερεύον ζήτημα

Οι ιδρυτές ρίχνουν αγάπη στην κεντρική λειτουργία και μετά, δύο εβδομάδες πριν την κυκλοφορία, θυμούνται ότι οι πελάτες χρειάζονται έναν τρόπο να εγγραφούν, να πληρώσουν και πραγματικά να αρχίσουν να χρησιμοποιούν το προϊόν. Η χρέωση προστίθεται βιαστικά μέσα στον πανικό. Η ενσωμάτωση είναι μια οθόνη σύνδεσης και ένα ανασήκωμα των ώμων. Όμως η διαδρομή από τον «ενδιαφερόμενο επισκέπτη» στον «πληρώνοντα, ενεργοποιημένο χρήστη» είναι η επιχείρησή σας — και είναι εκεί που τα περισσότερα έσοδά σας διαρρέουν αθόρυβα.

Έχουμε δει προϊόντα με μια πραγματικά εξαιρετική κεντρική λειτουργία να χάνουν την πλειονότητα των εγγραφών μέσα στα πρώτα πέντε λεπτά, επειδή κανείς δεν μπορούσε να καταλάβει τι να κάνει μετά την εγγραφή. Συνδρομές, δοκιμές, αναλογικές χρεώσεις, αποτυχημένες πληρωμές, ακυρώσεις, η εμπειρία της κενής κατάστασης για έναν ολοκαίνουργιο λογαριασμό — αυτά δεν είναι γραφειοκρατία. Είναι το πραγματικό προϊόν, για τον πελάτη, τη στιγμή που αποφασίζει αν θα μείνει.

5. Λανθασμένη πολυμίσθωση (ή παράλειψή της)

Αυτό είναι εκείνο που φαίνεται μια χαρά μέχρι τη στιγμή που γίνεται καταστροφή. SaaS σημαίνει πολλοί πελάτες να μοιράζονται ένα σύστημα, και ο τρόπος με τον οποίο διαχωρίζετε τα δεδομένα τους — η πολυμίσθωση — είναι μια θεμελιώδης απόφαση. Κάντε το λάθος και είτε χτίζετε κάτι που δεν μπορεί να απομονώσει σωστά τους πελάτες, είτε χειρότερα, παραδίδετε ένα σφάλμα όπου μια εταιρεία μπορεί να δει τα δεδομένα μιας άλλης. Δεν υπάρχει πιο γρήγορος τρόπος να χάσετε όλους τους πελάτες ταυτόχρονα από μια διαρροή δεδομένων μεταξύ μισθωτών.

Δεν χρειάζεστε εξωτική διάταξη. Για τα περισσότερα πρώιμα προϊόντα, μια μόνη κοινή βάση δεδομένων με ένα αυστηρά επιβαλλόμενο tenant ID σε κάθε πίνακα και κάθε ερώτημα είναι απολύτως επαρκής — αρκεί αυτή η απομόνωση να είναι χτισμένη στα θεμέλια και ελεγμένη, όχι ραντισμένη αργότερα. Το λάθος δεν είναι η επιλογή της απλής προσέγγισης. Το λάθος είναι το να μην αποφασίσετε συνειδητά, και να ανακαλύψετε το κενό όταν είναι ήδη στην παραγωγή.

6. Παράδοση στο σκοτάδι χωρίς τρόπο να δείτε τι κάνουν οι χρήστες

Κυκλοφορείτε. Ο κόσμος εγγράφεται. Και μετά... σιωπή. Δεν έχετε ιδέα ποιες λειτουργίες αγγίζουν, πού κολλάνε ή γιατί φεύγουν. Έτσι μαντεύετε. Χτίζετε την επόμενη λειτουργία βάσει μιας υποψίας, ή του πιο φωνακλά email πελάτη, ή της δικής σας διαίσθησης — η οποία, μετά από μήνες μέσα στο δικό σας προϊόν, είναι το λιγότερο αξιόπιστο όργανο που έχετε.

Τα βασικά αναλυτικά στοιχεία προϊόντος και ένας απλός τρόπος συλλογής σχολίων δεν είναι πολυτέλεια του σταδίου ανάπτυξης. Είναι ο τρόπος με τον οποίο κατευθύνετε. Χωρίς αυτά δεν διευθύνετε μια επιχείρηση, διευθύνετε μια ακριβή άποψη. Ακόμη και το να ξέρετε κάτι τόσο απλό όσο «το 80% των χρηστών δεν ανοίγουν ποτέ τη λειτουργία που πέρασα δύο μήνες χτίζοντας» αξίζει περισσότερο από άλλους δύο μήνες τυφλού χτισίματος.

7. Αφήνοντας την ασφάλεια και τα αντίγραφα ασφαλείας για «αργότερα»

Η ταχύτητα είναι η θρησκεία του πρώιμου σταδίου, και κατά κύριο λόγο αυτό είναι σωστό. Αλλά υπάρχει ένα μικρό σύνολο πραγμάτων που είναι καταστροφικά ακριβά να προστεθούν εκ των υστέρων, και η ασφάλεια βρίσκεται στην κορυφή της λίστας. Η σωστή αποθήκευση κωδικών πρόσβασης, ο περιορισμός του ποιος έχει πρόσβαση σε τι, και — παρακαλώ — η ύπαρξη λειτουργικών, ελεγμένων αντιγράφων ασφαλείας δεν είναι προαιρετικές λειτουργίες που προσθέτεις όταν έχεις χρόνο. Είναι το έδαφος πάνω στο οποίο χτίζεις.

Το σκληρό σε αυτή την κατηγορία είναι ότι τη γλιτώνετε μέχρι τη στιγμή που δεν τη γλιτώνετε. Όλα είναι μια χαρά για έναν χρόνο, και μετά μια παραβίαση, μια κατά λάθος μαζική διαγραφή, ένα πρωινό με ransomware σβήνει την εμπιστοσύνη και τα δεδομένα που χτίσατε εκείνον τον χρόνο. Δεν ζητάμε ένα τμήμα ασφάλειας. Ζητάμε να υπάρχουν τα βασικά από την αρχή, γιατί το κόστος της προσθήκης τους μετά από ένα περιστατικό μετριέται σε νεκρές εταιρείες.

8. Προσλαμβάνοντας τον λάθος κατασκευαστή για το λάθος στάδιο

Οι μη τεχνικοί ιδρυτές αντιμετωπίζουν μια βάναυση επιλογή: ποιος χτίζει πραγματικά αυτό το πράγμα; Τα δύο κλασικά λάθη αντικατοπτρίζουν το ένα το άλλο. Το ένα είναι η πρόσληψη του φθηνότερου δυνατού freelancer που παραδίδει κάτι που φαίνεται σωστό αλλά κρατιέται με σελοτέιπ, και μετά καταρρέει τη στιγμή που χρειάζεται να το αλλάξετε. Το άλλο είναι η υπερβολική πρόσληψη — μια πλήρης ομάδα senior με πλήρεις μισθούς για να χτίσει ένα προϊόν που δεν έχει κερδίσει ούτε έναν πελάτη ακόμη.

Η ειλικρινής απάντηση εξαρτάται εξ ολοκλήρου από το πού βρίσκεστε. Για να επικυρώσετε μια ιδέα, θέλετε μια μικρή, senior, πραγματιστική ομάδα που έχει χτίσει ξανά πρώιμα προϊόντα και ξέρει ακριβώς τι να αφήσει έξω. Για να κλιμακώσετε ένα αποδεδειγμένο προϊόν, θέλετε διαφορετικούς ανθρώπους με διαφορετικά ένστικτα. Το ταίριασμα του κατασκευαστή με το στάδιο είναι από μόνο του μια δεξιότητα — και το να το κάνετε λάθος σπαταλά περισσότερα χρήματα από κάθε τεχνική απόφαση αυτής της λίστας.

9. Αντιμετώπιση της κυκλοφορίας ως γραμμή τερματισμού

Το τελευταίο λάθος είναι το πιο θλιβερό, γιατί έρχεται μετά από τόση σκληρή δουλειά. Η ομάδα αντιμετωπίζει την ημέρα κυκλοφορίας ως στόχο, ρίχνει τα πάντα για να φτάσει εκεί, και φτάνει εξαντλημένη χωρίς σχέδιο, χωρίς προϋπολογισμό και χωρίς ενέργεια για ό,τι ακολουθεί. Όμως η κυκλοφορία δεν είναι η γραμμή τερματισμού. Είναι η αρχή της μόνης φάσης που έχει σημασία: η μάθηση από πραγματικούς χρήστες και η βελτίωση, εβδομάδα με εβδομάδα.

Ένα προϊόν SaaS δεν είναι ποτέ «έτοιμο». Η πρώτη έκδοση είναι μια υπόθεση, και οι μήνες μετά την κυκλοφορία είναι όταν ανακαλύπτετε πόσο λάθος ήταν — με τον καλό τρόπο. Οι ιδρυτές που το προγραμματίζουν αυτό, που κρατούν λίγη οικονομική αυτονομία και πολλή περιέργεια σε εφεδρεία, είναι αυτοί που μετατρέπουν μια ασταθή κυκλοφορία σε πραγματική επιχείρηση. Αυτοί που ξόδεψαν τα πάντα για να φτάσουν στη γραμμή εκκίνησης τείνουν να μην φτάνουν πολύ πιο μακριά.

Πώς να αποφύγετε πραγματικά και τα εννέα

Το να διαβάζεις μια λίστα λαθών είναι εύκολο. Το να τα αποφεύγεις υπό την πίεση μιας προθεσμίας, με τα δικά σου χρήματα στο τραπέζι και τη δική σου ιδέα στην καρδιά σου, είναι πραγματικά δύσκολο. Να λοιπόν η σύντομη εκδοχή του πώς τείνουν να λειτουργούν οι ιδρυτές που τα καταφέρνουν — όχι ως κανόνες, αλλά ως συνήθειες που αξίζει να κλέψετε.

1. 1
   Επικυρώστε πριν χτίσετε

   Βάλτε κάτι πρόχειρο μπροστά σε πραγματικούς δυνητικούς πελάτες και επιβεβαιώστε ότι θα πληρώσουν, πριν γράψετε σοβαρό κώδικα. Φθηνό να το κάνεις, βάναυσο να το παραλείψεις.
2. 2
   Επιλέξτε το μικρότερο πραγματικό προϊόν

   Ορίστε το ένα πράγμα που πρέπει να κάνει το προϊόν σας, και αναβάλετε αδίστακτα όλα τα υπόλοιπα. Γράψτε τι δεν περιλαμβάνει σκόπιμα η «έκδοση ένα».
3. 3
   Χτίστε βαρετά και απομονώστε τους μισθωτές

   Χρησιμοποιήστε την απλούστερη αρχιτεκτονική που λειτουργεί, αλλά κάντε τον διαχωρισμό δεδομένων μεταξύ πελατών μια θεμελιώδη, ελεγμένη απόφαση από την πρώτη μέρα.
4. 4
   Σχεδιάστε νωρίς τη διαδρομή των χρημάτων

   Αντιμετωπίστε την εγγραφή, την ενσωμάτωση και τη χρέωση ως κεντρικό προϊόν, όχι ως γραφειοκρατία. Τα πρώτα πέντε λεπτά αποφασίζουν αν θα δει κανείς τα υπόλοιπα.
5. 5
   Εξοπλίστε το με μετρήσεις, μετά κυκλοφορήστε για να μάθετε

   Παραδώστε με βασικά αναλυτικά στοιχεία και σχόλια στη θέση τους, κρατήστε οικονομική αυτονομία για τη φάση μετά την κυκλοφορία, και αντιμετωπίστε την πρώτη έκδοση ως ερώτηση, όχι ως απάντηση.

Παρατηρήστε ότι σχεδόν τίποτα από αυτά δεν αφορά δεξιότητα προγραμματισμού. Αφορά την κρίση — να ξέρεις τι να χτίσεις, τι να παραλείψεις και πότε. Γι' αυτό ακριβώς τόσες τεχνικά ικανές ομάδες εξακολουθούν να παράγουν προϊόντα που αποτυγχάνουν: το δύσκολο κομμάτι του SaaS δεν ήταν ποτέ η μηχανική. Ήταν η αυτοσυγκράτηση.

Συχνές ερωτήσεις