Version 1 Product Launches are Hard
Creating something from nothing, and putting it out there is no easy task. Launching new products face a variety of challenges including the fact that there are:
- No references
- No track record
- Few features
Now if you read that and stopped in your tracks – wondering why I suggested new products had few features, it's likely that you've been overshooting.
Are you an OverShooter?
When I called you an overshooter, I wasn't being mean. I'm simply putting you in a class of product developers that likes to get it right. You're in good company with Steve Jobs. So don't worry. In fact, right about now you're wondering if I've lost my mind by suggesting that Steve Jobs got anything wrong. Steve and I would have disagreed about a few things if we'd ever spoken with each other. That is, if I'd had the courage to speak. But either way, trust me for a sec and see where I'm going.
An overshooter is simply someone who doesn't want to be embarrassed by their first launched version.
When you release an early version of your initial product, and you limit its features, you'll notice it's:
- faster to market
- still has a lot of different directions it can go
Now, back to Steve. He had money, so he didn't need things to be cheaper. He had other products in the market making millions, so he didn't have to rush to market. And he knew exactly where he hoped things would go (even if the ipod Touch came out without any sense of it being a gaming machine).
So let me state the obvious – if you're as rich as Steve Jobs, running a company like his, you probably don't need to waste your time reading my silly article here.
Differentiate on Responsiveness, not Features
Over the years I've been involved in a lot of product launches. Some have been great. Some have royally sucked. But none of them have ever gone exactly as we planned. By that I simply mean this: I have learned something new after every single launch.
You may call your product (that version 1 thing) a beta release, a partial product or an early release version. I don't care what you call it. But in every way, the version you should release as version one should have a very focused and small set of features.
- Because you can iterate faster on a product that has 3 features instead of 30.
- Because you can focus on a single core pain easier.
- Because prospects can understand exactly what pain you're trying to solve.
When you differentiate, you'll likely have some reason why you're solving a core problem differently and better than anyone else. That's great. But a second and equally powerful way to differentiate is based on how quickly you respond to your initial customers.
When you have a limited set of features, and discover you're missing one, or that you need to change the way one works, you can react quickly when your product is small. It's much more complicated as your product grows.
Less requires Closer
This approach to releasing “less” requires that you get “closer” with prospects and customers. What you're looking to hear from people is that their main or core pain/problem is resolved. If that's true, then you've got something worth pursuing.
Recently a team of us worked on creating a document imaging solution in the affordable housing space. If you look at all the products competing in the space you'd quickly see that to enter today's market you would likely need a huge set of features (at least to compete directly). But we didn't do that. We didn't because we wanted to pursue a “less” strategy. Beyond that, I thought most of those features missed the boat completely – so why jump on board and spend more and delay longer.
Your Product needs an Opinion
Launching new products wouldn't be hard if you knew exactly what to produce, and had customers that were already committed to giving you money for them. Some people enjoy that scenario. Many of us don't. So for the rest of us, the trick is finding a product/market match. That means finding the match between the product we're trying to build and the market that wants it. But if your product doesn't declare loudly it's perspective, everyone may express some interest and you'll waste time trying to figure out exactly who is really your customer.
When we built our imaging product, we decided that the core problem was that most solutions start when documents come back to an organization. That is, when they're received in envelopes, opened and scanned. That's when products typically do their scanning, OCR'ing, categorizing and storage. OCR, for all that's been invested into it, still doesn't actually work great. So the question we challenged ourselves with was, “What if we created an imaging product that didn't have OCR?”
Telling customers (or prospects) that you don't do OCR in imaging is a bit crazy. But it came from our opinion. That opinion was embedded in our product.
And it was simply this: capturing your business documents when they come back into your system is too late and wrong. You should capture them as they are created.
So we created a product that worked in the background and captured all the documents when they were created, and when all the meta-data and knowledge about them was already known (rather than when they came back into the system with no context).
That opinion made it different from other products. Made it cheaper and faster to develop. Made it more interesting and valuable. Made it clear what problem we were solving. And most importantly, made it clear to us who would really be a client and who would walk away.
When you've created a small and focused product, which is opinionated, then really, the only work you're doing when launching new products is syncing perspectives. You're taking your product out for a walk, saying, “This is what I do. This is what I won't do. This is why.” Then, you're looking for folks who agree with you and happen to think you've solved the exact problem they have.
So job number one when launching new products is finding people who share your opinions. And that's not as hard as you might think – since most people want to share their opinions about everything!