Skip to main content

Launching a Product

This is the third post in a series I’m writing about a company I’m starting up (or have started, depending on when you’re reading this). You can read other posts in the series here.

My last post - Building a Product - covered the technical details that have formed MailSnail. In this post, I want to talk about how we’ve actually gone about bringing the product to market.

Ship Early. Ship Often.

This has become a very popular mantra in the world of software development (also known as “Release Early. Release Often.”). If you Google that phrase, you’ll be presented with enough reading material to keep you busy for the foreseeable future. For somebody like myself - a perfectionist at heart - this is something incredibly difficult to adhere to but it has worked very well for us so far and I’m convinced that it’ll be a cornerstone of the success (hopefully) of MailSnail.

There’s a quote I shared in my last post but I’m going to share it again because it’s even more relevant here:
If you are not embarrassed by the first version of your product, you’ve launched too late.
- Reid Hoffman, Founder of LinkedIn

What seems to be a somewhat tongue-in-cheek statement from Reid Hoffman is actually a very real piece of free advice from one of the most successful internet entreprenuers in the world. We at MailSnail take it seriously. Many others have written about why this is so important. Here are a few of my favorite resources on the topic:

I would certainly encourage you to check out all of those resources because they’re super-interesting but I’ll be pulling out some of the bigger points and how they directly relate to MailSnail.

Step 1: Ship Early

Again, this idea is not something I’m super-comfortable with and I’d imagine there are many others out there in the same boat. The reason I’m not super-comfortable with it is because building something yourself, whether it be a piece of artwork, a piece of furniture or, in my case, a piece of software, is intensely personal. I’ve poured countless hours (and, of course, a certain amount of money) into building this product and for lack of a better explanation, she’s my baby.

I want to present the product to the world and have the world respond in a positive fashion. A natural reaction to the world not responding positively to something that you’ve built is to feel slightly defeated. It has a tendency to not just invalidate your product but also to invalidate you as a person and the skill-set that you thought you were bringing to the table. Here’s an example of some of the initial feedback we received when we first announced the official launch of MailSnail:



Welcome to the internet! Now, in actuality, these tweet responses didn’t bother me in the least. This is a simple matter of internet trolls doing what they do best — trolling. But the fact remains, at some point we will get, and have gotten, legitimate negative feedback and we must steel ourselves against it and use it as an opportunity for growth.

Here are just a few of the reasons why shipping your product early is so important:
  1. You get feedback (both positive and negative) about your product — the sooner the better.
  2. You get validation as early as possible that you’re on the right path in how you’re building your product. Or the opposite occurs and you get invalidation of your product. Either way, the same ultimate goal is accomplished. The earlier you get this information, the more time you save in the long run. If your product is validated, you are able to continue focusing your attention on the right features. If your product is invalidated, you don’t waste more time working on features that are going to fall flat on their face. This invalidation can actually save your company from potential failure because it gives you time and some financial runway (hopefully) to make a pivot and build what your potential customers actually want. Without this early invalidation, you would have continued down the wrong path and only found out that your product is a value-add to nobody when it’s too late to do anything about it.
  3. The world moves fast. The tech-world, in particular, moves even faster. The longer you wait to launch your product, the more time you’re giving your potential competitors to launch their own product and begin getting a foothold in the market that you’re hoping to grow in. If you wait too long, you may become obsolete before you even have a chance to, well, become.

Now, I also want to be very clear about what “Ship Early” does not mean. It does not mean shipping a piece of crap software that breaks constantly, has no features, doesn’t fill a need for anybody, etc. Another term used often in the world of software development is “Minimum Viable Product” (MVP) — “viable” being the key word here. Your MVP is whatever you determine to be the first product that you can ship that has the minimum amount of features necessary to make your product worth using. Shipping early should not apply to anything less than your MVP. What should be included in your MVP? Well, that’s for you to figure out and I recommend you determine what you see as your MVP before you write your first line of code.

Step 2: Ship Often

So you’ve accomplished Step #1 — you shipped a product. That’s great! But shipping often is where the rubber really meets the road. One of the main purposes of shipping early is to begin getting feedback from real users as early as possible. Shipping often is the culmination of what you should do with that feedback.

Here are a few of the huge advantages you gain by shipping often:
  1. You develop a relationship with your users. They feel like their opinion actually matters, because it does! As your product evolves based on their feedback, they realize how tightly coupled their feedback and the evolution of your product actually is. This creates loyal users who are going to be more patient in waiting for features that are currently lacking from your product because you’ve given them confidence that if you ask, you shall receive! Of course, this means you’ll need to circle back to shipping early in order to ship often. For example, if you have several users who are requesting a feature, you’ll be best served by shipping the MVP of that particular feature, instead of taking months and months to build the “perfect” version (in your mind) of that feature. After all, users are only so patient.
  2. Related to #1, you will create a constant stream of feedback from your users. Think of this in terms of naval captains trying to navigate on the ocean. If they’re only receiving updates on their current location once a day, they could become wildly off-track in navigating to their ultimate destination. Yes, they may still eventually reach their destination but it could take much, much longer, wasting valuable time and resources. So what if they were receiving these updates every 12 hours instead of every 24 hours? Or every 1 hour? 1 minute, etc.? The more often these captains are receiving this crucial feedback on their current location on the ocean, the straighter their path will be to get from point A to point B. The same goes for software development.
  3. You will make your users happier by addressing bugs as quickly as possible. If you wait until you’ve collected a whole bunch of bugs and then take a month or more to knock out all of them so you can ship all of these fixes together, you may have already lost users by that point. If you uncover a bug, fix it immediately and ship it immediately.

Beta Launch

Like most companies, we released MailSnail to a limited number of Beta users before we launched publicly. This launch took place from February to March of 2016, roughly 6 months after development began, and the application remained in Beta until May. We wanted to get our application in front of somebody (other than ourselves and a handful of trusted friends/co-workers) as soon as we possibly could.

For the sake of limiting the exposure of any potential bugs even further, we decided to invite Beta users in stages. Our first invite group was 5 people, then 30 people, then 50, then 100, etc. The reason the groups of people we invited onto the app increased in numbers exponentially was actually two-fold:
  1. As we got more feedback from users, we were able to fix issues and gain more confidence in our application.
  2. The less people you reach out to, the less people you’ll actually get on your application as a user. The fact is, you have to cast a very wide net to catch even a handful of fish.

During our Beta launch, we learned a lot about how real users were actually using our app and how they wanted to use our app. We were able to fix a lot of bugs — a lot of bugs 😐. We were able to rebuild features to make them much better and even build a few completely new features. Long story short, we were able to build a better product by just getting it out there, uncomfortable as it might have been. We shipped early and then we shipped very often.

Public Launch

We made our public launch of our application on May 27th of 2016, with our official announcement of the launch going out on May 31st.



After making our public launch, our focus has now shifted more to marketing, user conversion and user on-boarding. As we’re still in the midst of this stage of our application launch, there’s not too much I can share in hindsight. However, the basics of what we’re now planning on accomplishing is trying out several different avenues for making our application known to potential users and constantly measuring the results to see what’s working best for us.

This will take place through social media, purchased ad spaces, and YES, even Direct Mail! Fortunately, we know the best application to use to create and manage a Direct Mail campaign. We drink our own Kool-Aid here at MailSnail. 😀

Comments

Popular posts from this blog

Review of the New Macbook

I finally got a chance to give the new MacBook a whirl and decided to share my thoughts about it. I very rarely feel compelled to review products or services. Like the average consumer, I typically only review things when they’re so fantastic that I think they’re a real game-changer or, conversely, when they’re so terrible that I think it’s very likely they’ll be a game-ender. Unfortunately, this review will be the latter - let’s begin:

The Big Question Admittedly, I was skeptical about the new MacBook from the get-go. Despite my skepticism, I really do like to give everything a fair chance, so I tried to keep as open of a mind as possible. Rather than focusing on any specific feature of the MacBook and making an uninformed decision about whether or not I would like it, I instead simply pondered the question “who is this designed for?” Unfortunately, after spending some time with it in person, I’m no closer to answering that question.

And that really is the big question - the only on…

MailSnail Series

Starting in August of 2015, I began building a company called MailSnail with my friend and co-founder, Matt Bertino. To follow along with my personal thoughts on the ins and outs of the company, experiences, lessons learned, technical details, etc., please check out the posts below. I’ll continue to add new posts here as I publish them.

Post 1: Starting a Company
Post 2: Building a Product
Post 3: Launching a Product

Building a Product

This is the second post in a series I’m writing about a company I’m starting up (or have started, depending on when you’re reading this). You can read other posts in the series here.
As I’ve talked about here, I’m starting a company called MailSnail. In this post, I want to share the ins and outs of how we’ve built the product (i.e. the actual web application).

The Buzzwords I’ve tried my hardest to make this post as approachable as I possibly can for anybody and everybody. I don’t want this to be something that is only interesting to folks who know what HTTP stands for or can rattle off it’s associated status codes. So for my non-tech readers, please bare with me for this one section and keep on reading.

For my fellow tech-nerds, I figured you might not care so much about the minute implementation details but rather are just more interested in a list of all of the pieces of our tech-stack (because you already know the implications of each in their use). So here’s the quick and dirty …