17 Jun

Building your Product in Public: Omega Halftime Review

Exactly 93 days ago, we decided to go with a product launch cycle that would make the hardest LEAN methodology veterans go queasy in their stomach. No MVP, no private betas. Instead, we decided to launch germ.io as we built it, and we’ve been calling this our Omega launch.

I’d say we’re roughly in the middle of our Omega journey right now – not from a timing point of view, but more from a “fulfilling that promise” angle. We’ve now roughly brought in about half of what we promised germ.io would be.

So what have we learnt about going Omega? And would it have made sense to wait it out for a a more traditional feature-complete Beta?

Lesson 1: Paint the dream before you code it

Before you can sell your product, sell the promise

When we decided to build a product that helps move awesome ideas to execution, we knew we were biting an elephant in the rear end. We had a good idea of where we wanted to go. But we knew we couldn’t afford 8 months of development time only to realize our users wanted something else. We wanted feedback, and we wanted it in real-time.

When I say we decided to launch germ.io Omega as we built it, I mean it quite literally. For the first few weeks, all you had was a text editor to put in your ideas, and the ability to share it with a bunch of people.

Today, you can add your flows of thought, nest ideas under it and collaborate on discussions around each of your ideas. And in a couple of weeks you’ll be able to turn your most promising ideas into actionable tasks.

And yet, for 93 days now, we’ve had users actively trying germ.io, giving us their feedback and helping us shape up germ.io. All based on the promise of germ.io. We showcased our most powerful value proposition – a dream that made as much sense to our users as it did to us.

Lesson 2: Don’t build something PEOPLE want

Build something you need, not something you believe people want

Everywhere we went, startup gurus and veterans told us we should be building something that people wanted. Only, we did not know these “people”. We went looking for a problem to solve, and worse still – trying to fit our solution into an existing problem. And we knew we couldn’t solve the pains of an imaginary user we did not empathize with. So instead of looking for a “people with problem”, we decided to look inside – at ourselves.

Right from the start, we knew our lives would have been much happier, merrier, with fewer hangover headaches if only we had germ.io already. This was a product need that we felt more dearly than anybody else. And we have been our first, and most loyal users.

We did not need to see our usage stats to know when something was amiss. If I did not feel the need to log or build on an idea in an entire day, I knew we were sucking real bad somewhere already.

Interestingly, building a product for ourselves has made it a lot easier for us to identify the right set of users for our Omega. People like us hang out where we hang out. People like us talk like we talk. And people like us obsess over the trivialities that we obsess over. We had our target market, user profile and pilot focus group developing our product.

But sometimes, when your nose is 5ft deep into the codebase, you can’t see things like usability flaws and annoyances clearly enough. Which brings us to Lesson 3.

Lesson 3: Users are NOT kind forgiving monks

Your user's anger is the greatest love your product can earn

When we decided to launch germ Omega, we debated tooth and nail about whether it’s fair to “annoy” users with a rudimentary product. But then, we decided to go ahead. Our users would understand.

And for the greater part, our Omega users have been awesome – throwing feedback, pumping motivation, and most important – giving us a reality check every so often. But they haven’t been those kind forgiving monks we expected either.

We wanted our users to believe in the promise, and yet take in a product that, for the moment, did not even match a tenth of their expectation. We believed they would shower us with love and kind words. Instead, for the first week all we got was an angry outrage.

But that anger was the best feedback we could hope for – our users genuinely couldn’t wait to get their hands on the product. The worst, and possibly the most painful feedback we got was when we had an entire week of just a bunch of crickets chirping. It hurts when there’s zero activity on a product you spent weeks to build, even if it’s just a text editor!

Lesson 4: Architecting and Engineering an Omega is a pain in the git

With omega your feature complexity falls quick, and the value you add raises fast

The trouble with going Omega is you can’t just work on a part of the feature puzzle and go back home. Everything you build will have to play nice with both what’s already running and things that are to come.

The technical debt we could potentially incur with the Omega is quite high. Features that should take a couple of days take a week of planning, development and pretty deep testing. But that’s just the cost that comes with getting immediate feedback.

But it’s not all bad from the engineering table either. Since we know exactly what we’re going to build next, the complexity that comes with every subsequent feature steadily diminishes. For example, we spent over two weeks just perfecting the authentication part of germ.io (the part where you sign up on the website, get invite to the Omega, login and use the app). We could have done this way faster, but it would have broken down later, costing us more time and effort.

But the cool thing about the Omega is the value addition every release brings. From a text editor to mapping out the flow of your ideas and collaborating with the people that matter, the benefits of being an Omega user jump up exponentially with every roll out.

In 93 days, we have over 200 users who actively use the product, share their feedback and help us build an idea-centric project management tool that’s miles ahead of what we could have come up with just by ourselves. And we’ve earned a few thousand people who’ve signed up for the promise that is germ Omega.

So far, we’re glad we went Omega. We’ve learnt things about our product and users that we couldn’t have hoped for otherwise. We’ve made ever-so-minor changes to our trajectories in real-time that instead of going back to the drawing boards months later.

We are now in the third phase of the Omega release cycle. After this we plan to spend some time cleaning up the interface, making the product more usable, and ironing out some kinks. If you haven’t signed up for germ.io, now would be a good time. And if you think you have what it takes to be an Omega Super User, drop us a line and we’ll get you in through the secret backdoor.




2 thoughts on “Building your Product in Public: Omega Halftime Review

    • I would agree. We’ve been waiting for a production-quality video for such a long time, I might have as well made the next Pixar movie with that knowledge :D We should be putting up a nice intro video soon though…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>