Building a product (II)

Riding the emotional roller-coaster while trying to define my product

When you’re not an expert on a field, the fear of the unknown acts in funny ways. Sometimes you’re super excited because you don’t know how actually difficult it is to move forward, and in some other occasions you are extremely low on morale because you don’t know that it’s actually not that difficult.

That’s my emotional roller-coaster now.

I’m learning a lot, but oh boy! the disappointments are one after the other. The best thing though is that I’ve been able to overcome the feelings of despair and identified many of my mistakes. So here are some lessons for myself.

Define your product

I have started with a specific idea in mind. I would offer a service on top of an existing open source software. For that matter, I would build a web application that has to interface with several deployments of this software.

Does that tell you something? No, me either.

If my own product doesn’t tell me anything, how can I sell it to anyone?

You need to have a clear picture of what’s your product, and be able to define it in a sentence. Unfortunately I’m telling myself my product is too technical to be able to summarize. It also has so many possibilities that I couldn’t possibly choose one… but I have to, and even if it’s technical I still should be able to explain it. Those are only excuses to avoid the reality: I’m still not good at it.

It is important to have a definition of what you want to build. Only by knowing where are you going you will be able to choose your best path. If you have no goal, no final destination, you will steer around with no clear direction and under someone else’s command.

So here’s my current try at defining my product:

Wormhole is a cloud virtual networking solution that simplifies your network and helps you save thousands on complex and costly VPN and MPLS solutions.

Meh. I’m pretty sure it can be done better, but that’s my current best take. It’s not the first, but as I’ve steered from my initial target market, I had to also change my message.

How you define your product does actually pave the way for many other aspects of your product. E.g. What features should we include now? and which ones in the future?

Let’s imagine my product goes after enterprise customers — that implies that its main value should be “our product takes the risk from your and puts it on our lap”. On the other hand, small businesses and freelancers are more happy to shave a few thousand and risk eventual downtime of your service.

So not only defining your product will mark which features you should work on, but it also requires you to work on knowing your customers. It’s not enough to know how to reach them, you have to know what they want to hear.

“Building a product” series.

I’m writing these articles as a way to record and share my learning, while I try to reinvent myself.

This is the second article in the series, and this is the previous one:

Building a product (I) — Or how I’m moving from a job to a career

These are part of my experiences while building Wormhole, a cloud virtual networking solution that empowers you to extend your private networks between different cloud and hosting providers.

If you haven’t tried it yet, you should, it’s fucking awesome.