19.3 C
Tuesday, June 28, 2022

Qaiku.com – What Can We Learn From Failure?

Editor’s note: I think we in the tech press have the tendency to focus on the positive stories and forget about the startups that didn’t live up their expectations. Our Sofanatics coverage this past week has been one of the few times we’ve covered abandoned projects, which is a pitty because there are a lot to learn from “failures.” Below we have a long read from Eero Holmila which is one part eulogy, and another part what he’s learned from the now-announced shutdown of Qaiku.com.

- Advertisement -

Qaiku.com might be a familiar name for some of the readers of Arctic Startup. However, I am quite sure that the background and the rough road from high hopes to a bitter decline probably is not. I am the CEO of Rohea, a company behind a handful of quite successful Finnish websites like Kotikokki.net, Kuvake.net, Mikseri.net and of course a less successful Qaiku.com.

I am going to share some lessons learned through the trip. I hope some of it might be of use, spark up ideas or if nothing else, be at least a bit entertaining. One last important disclaimer: all the opinions are my own.

Now without further delay, this is the story of Qaiku.

Ladies and gentleman, start your engines
The birth of Qaiku was all Google’s doing, really. We were avid users of the splendid Jaiku microblog service by fellow finns, namely Jyri Engeström and Petteri Koponen. Ever since I started using Jaiku I was admiring its clean and beautiful base concept. It was in many ways great, though I always thought that by adding just a few crucial features it would be even better – and more importantly – perfect for corporate use. In 2007 I wrote in my blog ‘Oikeita totuuksia’ (true truths) a wish list for Jaiku to implement for it to be suitable for enterprise use. At that moment we hadn’t the faintest idea that a year later we would start a project that would come out as Qaiku.

Then it all changed. In came Google and bought Jaiku in October 2007 and the slow death spiral of once so potential service had started. By the middle of fall 2008 we started talking about the lost potential of Jaiku and started wondering if Google would be doing anything with it. From the bits of information we were able to gather, we came to a conclusion that Jaiku had been left behind. Frustration about the situation was starting to get quite high among other Jaiku users as well. Talk about “mass exodus” started getting louder and more serious.

As we had resources, technical knowledge and a vision of the potential, we decided to go for it. We were counting on that if we could offer a viable alternative to Jaiku, we could get a critical mass of users right from the start and avoid the death valley phase completely. We were not totally wrong, but we were not right enough either.

We hit the valley and got lost there.

The Vision
Our vision was to create a conversation centric tool for creating, sharing and processing knowledge and ideas. The ultimate idea was to take and improve the best communication models from Jaiku, the best light project management practices from Basecamp and the best professional information network and knowledge management ideas from LinkedIn. In addition we were going to add a lot own and mash them all together to create a lean, powerful and fun to use ensemble.

The vision didn’t stop there though. We didn’t just want to create a single powerful service but a platform with many instances. Instances that could be used not just as public hubs but as private ones used from the safety provided by the organisation’s firewall. In essence we wanted to create a distributed platform that would be able to link and share spaces in between different Qaiku instances. For example an organisation using a private instance would be able to open a room in public instance or share a common room with another private instance. Users could be members of several different Qaiku instances, public and private, and would be able to hop in between them easily as a walk in a park. We also wanted Qaiku to be entertaining and fun to use as well.

Money was going to be made from monthly payments from companies using the “organisation Qaiku”, or as we called it “oQaiku”, and from premium services like chat, bigger quota, better administration tools and so on. I remember that at some point we were thinking about the challenges and the pain of invoicing a huge number of small clients. As it turned out, we really didn’t have to figure that one out.

Lucky us.

Improving versus innovating, tributing versus copying
One of the first mistakes we did right at the very beginning. We underestimated the deepness of love some users had for Jaiku. In the middle of Jaiku’s death spiral and the talks of mass exodus we thought we were giving a tribute to Jaiku when building up a new similar service with a future. Furthermore we thought that we would be generally applauded for our hard work. Now, some years later, this thought seems distantly childish. But hey, we were young(er).

To set the record straight, I don’t want to mask the rationale behind building Qaiku just as a tribute for Jaiku. Naturally we thought a lot about giving a familiar user experience for Jaiku users to get them aboard and of course we thought there could be business to be benefited from. After all, if Google had not decided to kill Jaiku, we would never have started with Qaiku.

We launched Qaiku in the early spring 2009, first to a small team of pilot users to iron out the bugs and then to everybody. At the launch, Qaiku was really Jaiku like, only more fugly as we weren’t that design centric at that time. Or as one of the non-favourable persons unbeatably put it: “it’s like a cheap and bad Chinese clone of Jaiku”. Even if true, at the time that remark hurt us as did some other remarks down the road on the subject of copying and stuff.

There’s a lesson in it as well. Developing a thick skin and not getting too emotionally beaten by possible unkind comments is a must. It’s Internet after all, you will get bruises, for sure. Yet even when the comments feel unfair, it doesn’t mean that there’s not any truth in them. Breath deep, get over the initial shock and analyse if there is something valuable to gain. If not, drop it and move on.

It wasn’t all that bad as we did won over a lot of people. And with the very same breath, we did also alienate quite a few who became almost if not completely hostile against Qaiku. When people started to flock from Jaiku, we lost especially alienated ones to Twitter. Some of these became quite fierce evangelists for Twitter, and partly against Qaiku as well.

Why mourn a loss of a few users? When building a successful product, even a few really passionate and well-connected users might help you a long way. In fact if you should put any trust on Malcolm Gladwell’s The Tipping Point it might be one of the most crucial things in between winning and failure, but if nothing else, committed users just make the developing so much more fun.

Personally I don’t believe that not getting “everybody” from Jaiku to Qaiku broke us for good, but it didn’t help either. In a time when social network space was getting more crowded every passing day, we were never able to leverage the network effect even in a small scale as some central knots were not and would not use Qaiku. Most didn’t naturally care at all about the birth history of Qaiku (or hadn’t even heard of it), they just preferred Twitter for some or the other reason or even more often, they liked Qaiku, but couldn’t find time for multiple networks and Qaiku was first to be dropped. In a war of network effect, we effectively lost.

Especially in the early days of Qaiku we got quite much heat about not innovating but copying. I always found that a bit harsh as we had plans that were definitely somewhat innovative and we had unique, even innovative features from the start. Even if we wouldn’t have had any of those, one might ask what’s wrong with just improving existing [dead] product if you can see potential there? History is full of successful products that weren’t the first ones or even the most innovative ones, but built upon the base someone else had created or invented. Of course, we were a bit shy on communicating our goal and intentions.

In retrospective, the choice of name wasn’t the brightest ever either. It is hard to pronounce and resemblance with Jaiku didn’t really help either. Furthermore, we did understand that the chosen name would be too difficult internationally, and a bit more original name would have been better, but we were too fascinated about the name game (in finnish qaiku is almost identical to word kaiku which means echo) to care as it supposedly wouldn’t really matter that much anyway. Again, you should care. The devil is in the details.

Let’s dive deeper.

(Screenshot from ArcticStartup’s first coverage of Qaiku from back in 2009)

Technology; choose badly, and it will be hell
Today Rohea is a technology powerhouse, no question about it, but to get here, we had to pay our dividends. As we founders have all graduated from the Helsinki University of Technology we have always been fascinated about elegant, powerful and smart technological ideas. This is a huge benefit, but sometimes it also plays against us, at least to some degree.

Our first web services were coded from scratch utilising battle tested architecture solutions and models straight from the rulebook. In practice we ended up with a custom platform for each and every new project. In a technical sense they were working well, but from an economical point of view we quite soon understood that this model just wouldn’t scale. We had to find a way that would make possible to reuse code and let us focus our time to problem solving, not to doing monkey coding and creating some basic functions again and again. In 2008 we started to research for an alternative model, i.e. suitable programming framework to match our needs.

We ended up with a component based PHP framework called Midgard. It had some elegant and unique ideas that we were immediately drawn to, it was already used in several commercial web projects and we knew quite many of its core developers. That was the good part. The bad part was that we jumped in just right when the whole framework was going through enormous development, including massive API and other fundamental changes. Talking about a bad timing, eh.

How this relates to Qaiku? In every way.

Due to Qaiku’s communication model and multi-instance dimensions Qaiku is a really complex organ. It would have been a quite challenging task to make it work even with a fully problem free and totally powerful programming framework. With Midgard going through massive changes at the time it was an ultimate challenge. The framework wasn’t bad at all for things that it had been used before; our needs were just a lot more demanding and we were pushing the framework to its limits and beyond.

Unfortunately, it didn’t cope with our needs too well. We made it work, at some level, but not without a cost. Most of the time it felt like we were fighting against the framework, not beside it. We had to code a tweak after another and huge amounts of hacks just to get around different limitations. Use framework, get rid of the monkey coding, right? Well, not quite.

During the development of Qaiku the Midgard project released two major new revisions and because of the massive renewal process new versions were not very compatible with previous versions. In addition to compatibility breaks we also had a lot of our own tweaks and hacks that weren’t working with the new versions. For each of the new versions we had to basically recode most of Qaiku. During a time span of one and half to two years, we were using most of our time in creating the same basic functionality again and again with only some small improvements.

Lessons learned? When tech doesn’t play for you, it’s a clear warning signal to stop and think about the alternatives. If you don’t, it will be costly and morally devastating to fight against the technology day after day when your focus should be in completely different questions. Like, for example, thinking on how to improve your product to meet numerous challenges and how to improve its core user experience.

In summer 2011 we thought we would make one last try with Qaiku. Midgard had matured a lot and with its new version it was possible to use only its PHP MVC framework part, which we had been contributing to quite heavily as mine stompers. We started to refactor our code to take the advantage of it and to get rid of all the old deprecated stuff and less-used features.

The plan was to get to the bare bone core of Qaiku and make it as it should have been from the start. We were about halfway ready when we learned that the core developers of the Midgard project were gradually shifting their main attention to consolidate the Midgard project with another framework project. Combined with the reality that the activity levels of the users were already spiralling down, this left us with two options. We would either be almost only persons in the world using Midgard MVC on a product that had a very uncertain future or we could finally cut our losses and end the development of Qaiku.

We did the latter.

One could say we did a big err when going all in with the Midgard project, but we have to remember that at that time programming frameworks around weren’t anywhere near where they are today. It’s totally plausible that we would have hit the same problems with other frameworks as well. We are still using Midgard MVC in couple of our sites and it’s working well enough so not everything was for vain. The Midgard project’s core will still live on other projects and we will be following it’s progress. There was and there still is some neat ideas.

The lesson to be learned is not a framework centric but more generic. We have done the very same mistake more than once with many different cool technologies during our ride. In the technology department it’s easy to get carried away with the newest hot tech. It’s good and essential to play around and test stuff, but at the end you should make a clear difference in between testing out the newest technology and taking them to a serious production use.

Building on technology that isn’t stable enough or is going through big fundamental changes is just asking for problems. And we sure got what we asked for.

Listen to your users, but too much is too much
In addition to technological challenges, we got first hand experience on well-documented perk, a feature creep. During development of Qaiku we were obsessed about listening to users and improving the service based on feedback. Sounds great, doesn’t it? The main problem with this approach – even if you should be doing it to some extent – is that if you take it too literally and forget to keep design rationales firmly in your own hand, you might end up with clutter and tons of features that may be functional, but UI and UX wise underwhelming.

And yes, we hit this pothole.

Instead of focusing on core features and making them really stand out, we got a bit carried away by adding new features with more the merrier line of thinking. This is not a best possible approach when wanting to build a fun to use service. And of course there’s a paradox there as well. If you are listening to every one of your users and their wishes, you will have a lot of contradicting wishes as people’s preferences do vary. But naturally we knew how to handle that one! Bring in the settings page and make everything configurable so everybody can have the features just the way they want. The only downside was that the already complicated code got a lot more complicated by every addition.

The hidden wisdom here is quite obvious. Most of the users are not a bit interested about being able to configure everything. They just want to have a beautiful product that works like a charm. If something nice-to-have is missing, they’ll let you know, but if the core set of the service is working splendidly and the UX is top notch, much is forgiven. And what’s best, your code and the product itself stays a lot simpler and hence a lot easier to take further.

I wouldn’t go Steve jobs here, you know, like f—k the users, we know best, but there’s some deep deep wisdom there. At the end if you are not keeping things under control and the vision clear on your mind, who will? It’s good to keep a keen ear for user feedback, but take everything you hear with a small grain of salt: does that user really need that feature or are they really in need of something completely different? Or are those users really just early adopters who like to build space rockets on their free time and whose needs are not very relevant to your target audience anyway.

Give too much weight to feedback, take all ideas something you really have to implement, and you will go wrong. Stay focused, stay on your own course, stay true to what you believe is the correct winning combination. Basically, stay in control. It might pay off a bit better than listening and doing too much the way your users would seemingly like you to.

Cooperation is all about trust and achieving together.
Acknowledging your team’s strong and weak spots is quite essential to do at some point, preferably quite early. There are a few ways to handle results. You can either ignore them or you can strengthen weak areas by acquisitions, inner training or hiring new people. One possibility is also to focus on your strong points and try to partner with companies and individuals that can cover your weak spots.

When we started our journey in the world of web at the end of 2005 we were believers of mastering every aspect of the trade. We identified our weak spots to be in marketing, customer relationships and selling. As we had no money to make acquisitions or to hire new people, the only option left was inner training. As other founders were taking care of tech, this role fell to my hands. Shamed to admit, even if I have become a bit decent in some areas, marketing and selling are still not my strongest skills.

Even if I will never master those two arts, it doesn’t matter that much anymore. As we started to gain some insights to business, we started to shift our focus to be more and more in a constant lookout for networked cooperation. Today we believe that we don’t necessary have to be great in everything, just in things we do best. And we do a pretty good job with creating and operating good solid products, both b2b and b2c services.

As a rule of thumb when you’re about to start cooperation with someone, you start with trust and you end with commitment. This really is heartbrokenly obvious, but still too often missed. If during the negotiations you cannot achieve both of these, walk away. As this is easier said than done you probably might end up in a situation where you are determined or even overcommitted to close a deal no matter what. If this should happen I advise you to put a lot of energy at the very start of your working relationship to build up the trust and commitment you were too busy to secure during the initial talks.

We did one of our first networked cooperation agreements with Finnish publicly traded company Alma Media Oyj. We sold a share in one of our application to Alma Media and as part of the on-going cooperation we still develop and operate the product. Alma takes care of most of the marketing, channel distribution and governs advertisement selling. In many ways, this is a very good match: we both have clear complementary areas of expertise that we are taking care of.

With Qaiku we went a bit different road. In the second half of 2009 we started talking with another Finnish web company about cooperating on building Qaiku to be something really great. The idea was to accelerate the development of Qaiku by securing additional technological resources, especially in areas of location based services and APIs that we had no previous technical experience of our own.

Making a cooperation deal isn’t that big of a challenge, making it work and every party committed to the bone is. Looking back at our discussions I can spot multiple points of failure. We both were in too hurry and we did not take our time to discuss what we really expected from each others. We kind of made the deal and just thought we would figure out many important points later down on the road. Some challenges that we should have tackled right at the start roused from our different backgrounds i.e. from cultural differences.

The other company was an open source company to the core, and we weren’t at that time almost at all. We and especially I were really jealous of our homebrewed tech and wanted to protect it in every way possible. This led to a point where we didn’t get extra resources we had wanted to secure to full use as the other party wasn’t able to access our development servers as we hadn’t had time to agree on suitable non-disclosure contract. Funny enough, we trust those guys in real life, but as we were rushing forward, we didn’t put aside enough time to work it out on a contract level.

Here’s a no-brainer. Great and beneficial cooperation is essentially about relationships, not legal contracts. Good relationships might be possible to form up even after contracts have been signed, but it’s not granted. I’d say it’s better to build up the cooperation-centric attitude first – and whenever possible not just between the top bosses – and bring in the legal contracts later on. After all in cooperation you have to think other parties and their well-being as much as your own. You are not anymore playing just for yourself but for the whole team. Creating mutual working habits, trust and commitment takes work, communication and time. But it’s time well spent.

At the end, what we gained was some valuable consulting and a few coding workshops, but we couldn’t realize all the potential benefits of this cooperation. And as time proceeded areas we had agreed to be on other party’s responsibility became slowly our turf as well, mainly because of a law of reciprocity. As we were heavily focused on the heavy lifting and didn’t even always ask for other party’s help they slowly became less committed. In turn as we felt that they were less committed, we started to do even more on our own and hence reducing other party’s commitment further.

One last thing about this particular cooperation deal. Today we might not be entering into this relationship; not because of the experience described above but because the other party’s area of expertise is almost the same as ours. In Qaiku’s case we believed we needed to extend our development resources and I am quite confident this cooperation would have worked out eventually if the real problem had been technology resources. It really wasn’t. In this case the real weak spot was marketing and selling, and we would have needed more guns on that front, not on tech sector.

On that basis, when looking out for cooperation deals, it might be better to seek out for parties whose expertise and resources compliments your own. There is most often some overlapping knowhow, but main areas of responsibilities should compliment each other. If you are weak on technology but strong in marketing and selling, find a tech partner that you get along with and start a networked cooperation (and the other way around). It should benefit you both.

This is exactly what we are aiming to do from now on.

qaiku shutdown
(Screenshot of Qaiku before shutdown)

Going global & getting funded
I don’t have too much to share on this topic, as we have really never gone global or raised any money from outside (well, years ago a very small sum from TEKES on one prototype project, which did help a bit at that time). With Qaiku we aimed to be glocal – that is global local – from the day one. This was the reason we build a multilingual support to the very core of the application. The purpose was that users would only see messages in languages they understood… or wanted to learn. We didn’t have any clear going abroad strategy though as we were mostly relying on the network effect… It wasn’t quite the success we hoped for, but if nothing else, with English user interface we got the attention of thousands of insurance and porn spammers. That’s something, right?

Anyway, one thing I’d like to raise up is that even if the current mantra is “go global day one”, I would suggest having a bit of a thought about that as well. In many cases going abroad as fast as you can is a viable choice or even a must decision. The other alternative is to make a stronghold on your own country as there’s usually some decent money to be made from the home market, even in Finland. There’s a lot more upside when going abroad and especially if you hit the jackpot, but then again there are advantages, even if a lot less upside, on concentrating on the home market.

Yes, I know, that is a bit heretic. I am sorry.

Nevertheless I’d avoid believing that there is one universal rule, and think carefully what is your best bet case by case. If you want to play the high stakes game and the first goal is to achieve a big investment or make a huge exit, you quite certainly should aim to go global right away and grow as fast as you ever can. If your goal is to build up a profitable business that you might hang to years to come, the choice might not be that obvious. After all, if you get the basics right and start to see good results, you are still able to make informed decisions about seeking later on more leverage in a form of investment.

I might be going again a bit against the tide here, but what comes to funding, I think startups should concentrate more on creating a sustainable and cashflow positive business from day one, not on getting the very first investment at the earliest possible phase. Neither should they, in my opinion, aim and dream about a grandiose exit, but aim to build a great profitable business first, and think about exit after that. If I would be an investor myself, I guess I wouldn’t invest to anybody who hasn’t put any of their own money into a play.

When one has something else to lose than somebody else’s money, sh—t is more real and one usually thinks more about the profitability… and might fight a bit harder to gain it.

Almost ready is not ready at all. Without focus, you have nothing.
There’s a saying that the last 10 per cent takes as much time to complete as the previous 90 per cent. We have found this to be, to a certain extent, true. In practice this means that just when your service seems to be almost ready to be published, you suddenly notice that, no, we are not just yet there. It could be a bit of tweaking needed, a bad UI decision, a plain bug or a new addition that is just so really totally compulsory to get included to the very same release.

With Qaiku we were constantly building a very wide set of features at the same time. I remember that we had at times tens of new features, enhancements and bug fixes almost ready for the production, but not quite. As we were proceeding with a broad front, there were almost at any given time dependencies that prevented us from deploying the ready bits to production. Because we lacked focus on what to develop, we couldn’t get the features and fixes rolling out as fast as possible, and the process became at times horribly slow.

For example when we got fix requests, the fix was usually already in our development servers, but we just couldn’t take the risk of deploying it to the production immediately because of the dependencies. In worst cases rolling out fixes took even weeks. Same thing happened with new features: as a marketing gimmick and to get users a bit excited, we teased about great features that would be released in a very near future. Usually this very near future was a lot further away than we had imagined.

Eventually this lead to a not so agile model where we put out huge new versions with tons of features, fixes and other stuff, like, bugs. It’s software developing 101 really: when a release gets too big, it gets harder to control, and the probability that not all the parts are completely in place gets higher. If you have resources to fight big release problems, it might not matter that much. If you have only a small team, another approach might be more suitable.

One thing is quite clear. Majority of users really don’t care too much about nice things to come somewhere in the mysterious future. Only a small partition will be excited to know what’s on the menu tomorrow, but should you fail to deliver, they just might get a bit nasty. This concludes the rule; until it has been released, it’s worth zero, null, nothing. If you don’t put your focus to a limited amount of things at time, you spread your power and resources.

You will miss the deadline.

At some point, you really should start to sell. “We’re not ready yet” means that you will never be.
As long as I can remember there has been a common saying that we Finns are excellent engineers but we don’t know how to sell. Not to mock here, I do believe there’s a certain truth in this. Naturally there’s a great length of examples of marketing and selling done great, but often we might still a bit product centric and believe that a great product will almost sell itself and an awesome product will sell its neighbours as well. This is changing in a fastening pace, but maybe we are not quite there yet.

In summer 2009 we wanted to bring the second phase of our vision to reality. We started working our butts off with a purpose to deliver the first version of organisation Qaiku to a public. In September 2009 still to be launched product was covered by the Finnish economic paper Taloussanomat with our estimation that the beta version would be out in October 2009.

We did have some focusing issues, and it wasn’t.

The initial technological launch wasn’t actually delayed. We rolled out the new product version with a support for multiple organisation instances at the end of October 2009. We just didn’t open it to users as we, and especially I thought, that we were not ready. Beta wasn’t good enough. And there were minor bugs and stuff to do with the public Qaiku that we should solve first. And the response times of the site, dear me, WE WERE NOT READY.

Actually, we pretty much were ready, and we should have started trying to get first customers as we were advised on several different accounts. Contrary to advices, I was reluctant to give it a go-go as I knew that it could be so much better, even if the technical team had already done a remarkably good job. In an ideal world I might have been right, but in this very world we live we just don’t always have the luxury of making stuff absolutely perfect.

The most telling point is this: it’s now august 2012 and the beta is still not open and it will never be. It’s not because the product wasn’t good enough. Even if there was known problems and limitations, we used it for our internal communication from October 2009 to the start of this summer, but you know, there were always things to do and places to be.

The crucial point is that at some point you have to start to sell, as it’s the only way to make business profitable. In essence if the product doesn’t make money, it will be eventually abandoned or shut down. Or you will make million billions with a good exit, but on the other hand, you need a good salesman for that as well.

Without marketing, it’s hard. Do everything you can.
Ahh, marketing. To have any kind of success with any kind of product, you need users eg. customers. And to get users, you have to let them know that you and your product exist. Even if you don’t have big money to spent on marketing, as it is often the case with new guys in town, there are still a few things you can try out. Many rely on viral marketing, own blogs, legwork and the cheapest form of paid advertising – okay, thoughts about this one differ – Google and Facebook ads.

I exaggerate a bit here, but we didn’t use even any of those. We kind of hoped that the product would be so good that we would be able to lever the network effect to work on our behalf. Other than that, we kept silent. We didn’t have a blog. We didn’t try to create partnerships with other websites and medias. Our word of mouth marketing was a bit duff. Some users put a good word out for us, thank you very much for it, but mostly it just didn’t happen. And we didn’t really support or encourage our users to take action either. I guess that instead of marketing, we were thinking really hard about some really important technical detail.

Don’t get it wrong. We were committed to make Qaiku work, but we might have been a bit too overwhelmed of all the technical challenges and just didn’t have any energy left for marketing, good or bad. Effectively this rendered us to a “build and they will come” mode, which is quite stupid, as it hasn’t worked for almost anybody for decades.

A contrary example to this is the early days of Kotikokki.net that later became the biggest food and recipe site in Finland. At that time I was all over the place promoting the site and trying to get people to use it. I think one contributing element was that we believed every single user we could convert would matter, even if we knew that in 2006 we would need at least 50 000 unique users per week to get even distantly serious advertising money. In other words, we were really passionate not just about the tech but about getting users as well, even if we would have to get them one by one. For some readers abroad 50 000 unique visitors might not sound too hard to achieve, but even today six years later there are less than 100 sites in Finland than can get even that kind of traffic week after week.

The point is that even if every single user doesn’t matter in reality, you should do everything you can to get users. The means differ case by case, but you should devote time and resources and most importantly, passion to it. When you lack will to get customers there’s usually only one possible outcome. Crash, bum, burn.

Even all that said, as a company we are going to be even more product centric than ever and focus on building the best products possible. If everything works great, this should be possible through networked cooperation: we bring in the tech and the goodies, others bring in the marketing and salesmanship.

When you get frustrated and lose your faith, it’s downhill from there
The first thing to realise when building a great product is that it’s not a sprint, but it’s a marathon. In the beginning it’s all good and exhilarating; you’re building something new and awesome and everybody in the team is motivated beyond doubt. Real challenge will come later on. Tough ones keep going towards the goal, weaker ones will lose their faith and eventually fall out of race altogether.

There are a lot of factors weighting in this process. If the team gets even small bits of success every now and then and can see a glance of promise forming up, they feel energized and will be able to carry on. If the team hits the wall time after time, spirits start to go downward spiral, and with every encounter a bit faster.

With Qaiku we were closer to the latter place due the huge technical challenges discussed earlier. Despite all the problems and a slow uptake of Qaiku we were quite long able to motivate ourselves through hardships, after all we were already quite experienced on building services and didn’t even expect to have fast or easy wins. We were determined to push it through and make Qaiku a screaming success.

However in the end of 2010, about a year and half after launching Qaiku our spirits started to go down. Team’s faith was crumbling like an old dry cookie found from the furthest back of the drawer. I myself was still a firm believer and kept on arguing that we should push forward. I was rationalising everything we could still try and trying to get the team to believe that we could still really end up on the winning side.

In retrospective I am not even completely sure how much even I believed that we could pull it off and how much I was just reluctant to admit the defeat. I, after all, hate losing.

The worst thing about losing your faith is that you also lose your motivation and just start to work for the paycheck. When this happens the overall quality and performance starts to decline. It might go so far that even a thought of touching tasks at hand starts to feel repulsive and mentally almost impossible. This happened to us as well. We circled around the code, did a little bit here and a little bit over there and at the end of the day we had achieved only a minor portion of what we could have and what we did on our normal days.

And with this, it just gets worse. When you cannot see any real progress, you get even more demotivated. It’s a vicious cycle. We started to get more and more demotivated and as we were not happy with ourselves, we started to get hostile against each other. We were quarrelling really hard about little things and features that really didn’t matter at all. When you get to this low point, it’s hard to spring back up.

I would draw three lessons from here.

The first one is familiar from change management: when you are running a marathon, you have to create short time goals that you can conquer and celebrate. You cannot run the whole long run without strengthening your motivation and faith with little success every now and there. You just can’t. Make sure that you have smaller objectives down the road and that you are able to meet them.

The second is importance of motivation, all the way from start to end. This requires giving a good thought on how to keep a set of different characters motivated and the overall work atmosphere fun and relaxed. It might be as simple as going out for drinks, making stupid pranks, explaining rationales, bringing up the endless possibilities of the project or it might need a lot more, like some out-of-the-box thinking. Sometimes you also just need to face the reality and think hard if there’s really any hope for the project to survive, even if you would be the greatest motivational speaker on the earth. Which you probably aren’t anyway.

The third is about progress. You have to go somewhere, something visible has to happen and there has to be some real meaning on what you are doing. Whenever possible, make progress visible.

You have to give time for a service to flourish. However, sometimes it’s better to call it quits.
We have first hand experience on growing a small web service to be quite big and profitable online business. One of the key learning is that it can take quite a while for a service to take off. I have witnessed many promising ideas going to dust just because of the unfounded beliefs about the time needed for success. Naturally every now and then someone gets a break and scores really well right from the start, but more often it takes time and heavy involvement.

My advice is this. If you really believe in your idea, don’t be too hesitant, be patient. Be prepared that you won’t hit the success levels in six months or even in a year. Our most successful product to day took almost two years to show good promise and a couple of more to turn into really profitable. The problem of course is that quite often you don’t have the luxury of time. For that reason, if you are a startup without a proper savings or funding it’s sometimes better to start slow and getting your bread and butter from a day job or consulting work. It’s a bit easier if you already have a profitable company so you might be able to handle the project as a long term investment rather than something that you are probably going to kill or forget after three months.

Just to make it a bit more complicated, there’s a fine balance in between giving enough time for a product to hit it off and just wasting your resources. One of the most classic teachings, that one should not fall in love with their own product, is not a classic for nothing. It is a really common mistake, but a really understandable one as well. One of the hardest things in life are giving up on something you have invested heavily on. It doesn’t really matter are we talking about web services, jobs, dreams, relationships, hobbies or what so ever. The mechanism is simple; the more you get into something, the more committed you are to make it work and the more reluctant you are to let go. Same process can be seen in action in auctions and negotiations.

While deep commitment can move mountains, there might come a moment when you have used so much time, energy and resources to “win”, that you become overcommitted. At that point you are willing to do almost anything not to have to give up, even stupid moves, like throwing good money after the bad. We and especially I myself were definitely overcommitted to make Qaiku work.

Money not so well spent.

The End Result
We did create some buzz. We did get some users, but not nearly enough. We did create a versatile and technically challenging service and made it work, not up to vision, but taking into consideration all the obstacles, we took it pretty damn far, at least what comes to what lays under the hood. We also did gain some visibility as a company and we did get a few small indirect consulting deals through Qaiku.

Sadly, and what matters most, we were not able to get Qaiku to fly. We were never able to unleash its potential and fulfil the vision. What’s more, we were not able to turn it to any kind of business. Instead of generating money, we were burning it. And as a shareholder, I am sorry to say, quite a decent amounts of it.

During the process we did go wrong more than once, but even if we would have gotten everything right from the start, our timing might have been just plain bad. Either way, for a company of our size it was an expensive training exercise. If thinking positively, it was a good trip and served us a few useful lessons. We might be a bit stronger – after all we are still standing – and we certainly are more experienced. Fail and learn. Next time, should it come, I would like to see that we are able to do it a bit cheaper.

What I am proud of is that I like to think we had some part in bringing people together and helping to make some nice things becoming reality and moving forward in the pre-era of Finnish startup scene. As Christina Forsgård, who was nominated by Tietoviikko in 2010 to be one of the top 100 most influential people in the Finnish IT sector, once said ”Qaiku made possible for people to come together and to communicate and to innovate together in a way that would have not been possible without it.” We also did get our picture on the wall of Aalto Start up Garage, next to some big guns of the Finnish tech industry, even if almost nobody who visits the Garage recognizes or knows who we are. That’s quite hilarious, but we don’t complain, it’s always nice to see your own face up on the wall!

That’s it. I hope you enjoyed the read. Qaiku.com is still up and running, but we have not been making any active development on it for more than a year, we have just been keeping the servers running. Now the long days of struggling is finally starting to turn into the night for Qaiku. We will pull the plug about one month from now, somewhere at the end of September 2012, and continue on with our other services and new challenges yet to come.

It was somewhat of a ride. Thanks for everybody who participated.

Rohea is a development company founded by Tero Heikkinen, Eero Holmila and Tomi Saarinen. Rohea specializes in building and operating solid, complex and scalable web solutions and mobile clients, both b2c and b2b. The company’s strategy is to build long and strong cooperation relationships with partners from different areas of expertise.

Rohea operates Kotikokki.net – the biggest recipe site in Finland, Kuvake.net – one of the most heavily trafficed sites in Finland and Mikseri.net – the most famous Finnish unlabeled artist site. Rohea works closely e.g. with a publicly listed company Alma Media Oyj and Fennia Mutual Insurance Company.

- Advertisement -

Related Articles


Stay Connected

- Advertisement -

Latest Articles