Why isn't Germ.io following the Lean Methodology for product development?
Editor's note: Germ.io is an upcoming project management tool being developed by Vikram Bhaskaran, Gautham Shankar and Subramaniam, ex-Freshdesk technologists. The tool has hit 1000 weekly active users mark and currently has over 60,000 ideas added on germ.io, spread across 7500+ projects (the startup has also been featured on this week's watchlist). The interesting about the company is that it is not following the Lean methodology, here's their take...
About four months 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
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 do a lot more. All this while, 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
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
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
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.
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.
The post was originally published on the Germ.io blog and has been modified considering the product has gone through one more development stage. What do you think about this method of development?
