I've seen 4 product launches as a web dev on a software engineering team, and they've ranged from absolute-dumpster-fire to overall success. Each launch brings a new set of lessons, and I've found that the worse the launch, the richer and more unforgettable the takeaways.
The first product release of my career -- a web platform for managing college sorority recruitment -- was horrible. Numerous mistakes led to an unfinished and unproven app launching to 3,000+ active users. And these users happened to be stressed-out and sleep-deprived sorority women. Users who were relying on this app to keep the chaos of recruitment at bay. It took over a dozen long, stressful weeks to get back on track, but it galvanized my understanding of software engineering and ensured that I wouldn't make the same mistakes ever again. I've heard this called "scar-driven development", where failures and bad memories guide how you build software.
I'm sharing some tips + thoughts in hopes that someone else can learn from my failures, without having to endure 'em themselves. And also so that I can come back here to refresh myself before I launch the next product. Each of the following is a key part of product development and launch that I've goofed up, and have learned from.
Everything Everywhere All At Once is a great film, but a bad launch strategy
Or, don't launch to more people than can fit in a movie theater. Your first set of users are essentially beta testers; so set try to set that expectation, expect issues, and set up channels for streamlined communication. Having too many initial users will increase the chances of your product failing at scale. Ideally your first users are people that you trust, like long-time clients, your partners and advocates. People that will give you good and honest feedback.
Focus on feature parity
Everything that I've launched has been either a new version of our existing solution, or a reimagining of an existing, external product. It's crucial that your new product has all of the key features of the alternate or previous version. If that's not possible, make that very clear to your customers!
Performance testing is a must
Never let your users be your first performance test! This is regardless of whether it's a green field project or contains legacy tech. I recommend tech like Locust for simulating many users over a short period of time, and users completing several consecutive tasks. Every endpoint should be accounted for, and have metrics as a result. This will often lead to some not-so simple refactors, so plan to spend 2-3 weeks just addressing the bottlenecks or poor performance that performance testing reveals.
Slow down and triple check yourself
Slack is blowing up, you're furiously jumping around files in VS Code, and you can hear the alarm siren klaxon from the Death Star wailing in your head. When I'm hurriedly fixing issues and putting out fires, I'm at my least careful. It's okay to move fast! But when you're rushing to get that fix out, make sure to use all of the same safeguards and precautions that you'd rely on when things aren't crazy. Don't bypass Continuous Integration, don't skip testing things out on staging, don't forget to breathe.
Keep your feature set as small as possible
This might be the most important advice, but maybe the hardest to do. Especially when you're rebuilding something massive from scratch, or your users really need that real-time messaging feature. Launching an MVP means a focus on simplicity, a shorter feedback loop, and less initial development time. Release an MVP to new users that don't expect every feature, or free/lite users that don't have access to all of the bells and whistles. And set a prioritized roadmap of all of the "fast follow" features that will enter development once you launch the MVP.
Make plenty of time for initial data migrations
Chances are, a new product's database will need to be seeded with data from another database (if you're lucky) or a combination of spreadsheets and industry knowledge (if you're unlucky) Both can be very complex and time-consuming, and this is often the last thing that engineers get to pre-launch. What results is a last-minute scramble to get the product to a point where it's actually usable and it sucks. Getting your data right from the get-go will set your product up for success in the long term, so give this the attention it deserves!
Usability testing will save you
Watching a user interact with your product is like having a contractor poke around your house. They're going to find issues that you never realized! You're going to want to do 2-3 rounds of usability testing, where you test-iterate-test. Plan to do this over the course of at least a month.
There will be hiccups, and that's okay!
Releasing a product isn't stress-free, but it doesn't have to be painful or chaotic. Some things will go wrong, there will be bugs, and even if users and/or your team are frustrated, that doesn't mean you've failed and the countless hours you invested in a project are for nothing.
Launching a product isn't something to fear! Sharing a project that you've spent many moons crafting can also be exciting and cathartic and even victorious. All of the above responsibilities shouldn't fall on one person, and as a team, you will reach success.
