This is the final part of The Disruptive Adventure, where we see that the whole adventure led to something good, even though it didn’t go as initially planned. This post makes more sense if you have read part1 and part2 first.

From the beginning we had all the time planned to sell photo books in PiX’n’PaLs. At this point we had built the software needed to setup a store selling customized photo products. Additionally, we had sold the software to customers, who had all the capabilities to print photo books and other products. Customers of StoreFront were more than happy to handle our production. This was also technically easy for us. All we had to do was transfer our own orders to our production partner’s account. We could charge our end users whatever we wanted for their products and then pay the production partner an agreed amount.

We thought that others would also be interested in such a feature for their website, that made it possible to sell print products from all their pictures. Therefore, we decided to build something more generic, that everyone else could use as well. The new service was called PiX’n’PaLs PhotoProducts, which helped publishers monetize their website by selling print products from images. We took care of payment, shipping and everything else. The publisher got paid a 20% commission.

The service had two main features:

1. A publisher could add our code snippet to their website, making it possible for users to buy print products directly from an image. Clicking on the buy link opened a small shop, where the user could select which photo product to order from the image and use basic image editing tools, such as cropping, rotating and resizing the image.
2. Integrate our whole e-commerce solution to their website. When a user ordered print products, they had all the photos immediately available. This was practical in PiX’n’PaLs, where users had access to all their pictures and their friends’ pictures from the shared events. The events appeared as directories in the shop.

We launched with one of the biggest Finnish websites, Riemurasia, which enabled this feature for all its photos. The launch looked really promising and we immediately got lots of orders. Unfortunately our luck ended pretty soon when our feature had to be limited to only certain photos, due to potential copyright issues. Later it also turned out to be so that many orders got canceled, so in the long run it wasn’t that easy money after all. We would have needed many more big websites and better products with higher margins. Finland was definitely too small.

Launching this globally would have required lots of funding in order to get production and logistics to work well internationally. Getting deals with big international companies was hard and plugging into their production pipeline turned out to be technically impossible, since they did not have any APIs. It’s hard to tell whether this would have worked, since we were running out of money and had to leave it there. Potential investors were not too crazy about investing in a declining market either. The numbers did not fully work out.

The safe way to fail for many entrepreneurs is to start doing consultancy. This is what we did. We started doing projects for others to get some cash quickly. This seemed more comfortable after a long adventure with very high risks, so we kept doing it for full time until we joined one of our customers (Kiosked) as partners. We had already built the first version of their software and had all knowledge to take it forward from there. Today I am working there as the Chief Technology Officer and living really exciting times now that the company is growing rapidly.

PiX’n’PaLs is still running and used regularly by a lot of users and PiX’n’PaLs StoreFront is still used by two print-labs. These products are not developed further anymore. Some maintenance work is done every now and then to keep paying customers happy. If we would want to continue one day, we would have to update the UI and graphics completely, since they were optimized for IE6 and other ancient browsers. We have shut down the PhotoProducts and our own store (EasyKuva) which was one service built on the PhotoProducts API.

Well, you probably wonder: was it worth it? Absolutely! I don’t regret anything. The things I experienced and learned could not have come from any normal nine-to-five job. And as it turned out to be, one adventure led to another.

_This post makes more sense if you have read part 1. This post is about the 2nd phase in my company’s life.
_

We had been occupied with our real jobs for over half a year, only doing small fixes to PiX’n’PaLs in the evenings or weekends. I was working at a lab in Helsinki University of Technology, doing research and writing my Master’s Thesis. When I graduated, it did not make much sense for me to try to extend my employment agreement any further, since I didn’t have plans to continue with post graduate studies anyway. Jarl was also occupied in a similar position in his school, doing research in a different field. We had a strong belief that we could make PiX’n’PaLs work if we made a few improvements, so we decided to give it another shot.

The problem was that few new users saw any immediate value in using PiX’n’PaLs. For a user to see any value in PiX’n’PaLs, there had to be many events in the user’s story with many pictures taken by different people. A lot of effort was required for a user to get to that point, therefore it was easier for them to just post photos on Facebook. We felt that there had to be some bigger reward for going through all this. Nowadays I understand that end users on the web think really short term. There must be instant gratification for every small action.

Instead, we chose something more long term. We felt that adding a possibility to buy a photo book from an event would make it worthwhile for users to go through all the extra effort required. We knew that people usually want to create photo books or albums from events like weddings, bachelor parties, etc. Very often it required getting everyone’s pictures together into one place before making the book. This was often a hassle when everyone put their pictures to different places or sent them by email. We thought that PiX’n’PaLs could solve this problem.

This new feature required building an e-commerce solution with photo editing capabilities, since there were no solutions available that would have fitted this purpose. There were some solutions that could have been used for selling t-shirts and other simple products, but nothing for a photobook that we could have integrated into PiX’n’PaLs.

During this time we got into a pre-incubation service in Technopolis Ventures, where we got some help from an external advisor. Together we decided that it does not make any sense to simply build this feature only for ourselves. Instead, we decided to look for someone else who we could sell it to, thereby financing at least part of our product development.

After doing a few hours of research, we learned quickly that the ones who could potentially be interested in buying it were either small print labs and photo shops that needed an online shop with a photo book editor or then a few bigger players that had their own web shop already, but could potentially be interested in a high-end photo book editor. We tried for a while to sell this to one of the bigger players as a project but didn’t get the deal. Additionally there were photographers that could sell print products of photos they had taken. Both small print-labs and photographers had small budgets, so building something for them would not make sense unless it was possible to sell to enough customers.

We actually got on the right track and came up with a MVP to suggest to them. The MVP was a simple file uploader. Since so many small print labs did not have anything, we thought that a simple photo uploader would already give them something and would immediately bring money into the almost bankrupt company, and from there it would be easier to go forward.

I started cold calling all these companies and tried sell and find out if there were a need for this. I was not aware of Steve Blank’s Customer Development model at the time, but I had heard pieces and parts of similar theories from other entrepreneurs, mainly about the importance of starting from selling instead of coding. What I didn’t know was that you really need to do this iteratively and pivot when the current idea does not work. I did not fully understand the importance of iterating to find the best problem to solve.

I think we did not understand that the real purpose of selling was validation (or invalidation) and had the “always be closing” mindset at a too early stage of the company. Later, I have been joking that during the validation process, if customers don’t buy, you should open a champagne bottle and celebrate that you found one way that didn’t work and are now a lot closer to success.

We met some of the companies and had long chats with them and learned a lot more about their business. Even though we iterated the product based on what we learned, all our iterations were to improve our solution to the same customer problem. We should have iterated on the problem first, to find which problem makes most sense to solve, from a business point of view.

Anyway, a simple photo uploader was not enough and everyone wanted lots of features like selling coffee cups, mouse pads, etc. Most of them were really interested in buying the product. Some that were already using the competitor’s product were thinking about switching if certain features, that the competitor’s product lacked, were implemented. It looked really promising. We were not able to sign any deals immediately, since everyone first wanted to see a demo or try it out a little bit before buying.

So the spec changed to a full e-commerce solution with photo product editors. We decided to brand the product “PiX’n’PaLs StoreFront”, since PiX’n’PaLs was what the customers recognized and remembered us by.

We started implementing the product with most of the needed features. We should have continued with our customer development and tried to find a MVP that the customer is willing to buy before it’s implemented. We should also have validated that the business model is profitable and scalable, which we did not do well enough. This was because we had left the price question a little bit open and talked about a commission based model, making it very hard to predict how much we were going to earn. We thought the commission based model made sense, since we did not have a good understanding of the volumes or the margins in that business at the time.

Afterwards it is easy to say, but best would have been to require them to sign a contract and agreeing to a constant monthly fee. Unless the product is really a must have, they would not have signed. This could have invalidated the whole idea (champagne!). If not, it would have meant that the idea is validated and has good chances of succeeding. The contract could have had a minimum feature set specified and a deadline, speeding up things. Customers would also be much more committed to help with development by giving good feedback if they already had put money in the project.

Iterations took longer than planned for us, because small print labs were often quite busy and did not have time to immediately have a look at the new version and give feedback. The owners had to work themselves in the store and usually they could only find once a week time for a quick chat over phone. When they finally had time to try out the new version, if they felt that it still needed improvement or they came up with a new feature that would be needed, the launch was likely to be postponed by at least a month. We kind of got into a “feature hell”, implementing too much customization to fit everyone’s need before the product was live anywhere.

It took a horribly long time to implement everything from custom photo product editors and photo book editors to shipping cost calculators, payment options, etc. We even made the shop as a widget, running seamlessly on the customer’s website. It was possible to customize the colors of all texts and elements and lots of other things as well. The customer could configure the service to sell almost any kind of print product having a photo on it, just by defining the dimensions and the position where the photo should be printed on the product.

The photo book was probably the one particular feature we spent most time on. It was highly customizable and the first version already contained lots of unnecessary features, such as infinite undo/redo and an intelligent autofill feature that laid out all the user’s images in a nice way on all the pages, depending on their image dimension, number of pages, etc.

All the different configuration options that we provided customers just made the adoption harder. Likewise, the seamless integration into the customer’s website required that there were at least one technical guy on the customer’s side. Otherwise we had to help embed it. Nevertheless, a lot of work was needed both before and after the customer had said yes. When we learned how much commission we were getting, we quickly understood that the business could not scale and be profitable if we were going to pay full salary to sales people and support engineers that would handle the whole process. Luckily, we had not hired these people yet.

Bigger photo shops could possibly have generated enough money, but they already had some solution that was tightly integrated to all their equipment and processes. This market was more mature and these customers would require a so called whole product, to which there exist a lot of additional equipment and other software that can be connected to it.

For small photo shops, there was also a lot of pressure coming from big international players. The online market was already taken by bigger players and even larger international players were trying to enter the market. Small businesses had no chance competing with prices, so instead they went after the only segment left, which were customers needing high customization, assistance in the store and quick delivery (you could often get your products within an hour if you were at the store). The small shops seemed to prefer customers coming into the store instead of buying from the web. This was also a shrinking market and more and more photo shops were closing their doors, so it was time to get out of there.

To be continued…

This post is about my own startup (Disruptive Media) and how we pivoted and where it took us. I have split it into 3 parts, which all describe a specific phase in my company’s life. I am not going to go too deeply into all the lessons learned, but instead focus on the story and leave the many lessons for coming posts.

In 2007 I founded Disruptive Media Ltd. together with my colleague Jarl Törnroos, who I know since the late 80’s when we went to school together. Both of us have had programming as a hobby and written 2 computer games together back in 1998; one poker game and one labyrinth game. However, after that we have not had any experience working together until we founded our company.

In 2006 I was playing around with lots of different ideas to found a company. One was an improvement of a private photosharing website Jarl had built a few years before as a hobby project. Jarl’s website was used by all his friends and it was kind of used to document the life of our group of friends. All albums were group albums, usually created for crazy parties and other events.

More and more people were asking if they could use Jarl’s website and the existing users seemed happy. Sadly, it was designed only for one private group of friends, where everyone could see all the albums, so it would not have scaled. Therefore, I proposed building an improved version of this, which would allow anyone to setup an own private gallery with group albums. The idea was not only to target groups of friends, but also sport teams and similar.

The idea grew in our minds for about half a year before we got started. I was still studying at TKK, which I had just continued after an over 2 year long adventure in the Finnish mobile game company Sumea, which during my time was acquired by Digital Chocolate. Jarl was also working, so there was little time for our own project, other than brainstorming ideas every now and then. At those days we had a third member in our team, who dropped off before summer, during which we had taken some time off to start hacking for real.

Our idea had changed a bit from the initial one. Our idea was now a service to document your life (or the story of your life) in a collaborative way with your friends. We had dropped the idea of groups, since there are no real boundaries between groups of friends. The idea was that any user can create events and invite their friends to these events, so that everyone can upload their photos to the same event. All these events a user belongs to, form the story of that user’s life.

In addition to this, we had an innovative friend/contact list, where you became friends with anyone you had been to an event with. We thought it was a killer idea to quickly build up a social network that so many companies had tried to do but failed.

Early usability tests and interviews had revealed that some users would like to publicly share images from events. Events and pictures in them were private only to members of that event. So, we came up with another “great invention” that users could publish any events or images from their story on their public profile. This way, users who never took any photos could also share their story with the world.

The name of the service became PiX’n’Pals, after several long discussions. We would not have wanted to brand it with anything so tightly linked to pictures, but all good names for story, events, etc. were taken. Finally, we decided that since the service is going to be mainly about pictures in the beginning anyway, we can as well just go with name PiX’n’PaLs. If we manage to get a proof of concept, we are probably going to seek funding and probably even relaunch with a new brand.

Our plan was to make money from selling print products, like photo books, from the photos. We also saw the photo book as a value adding feature that would attract even more users. Additionally, we were going to have ads and possibly premium accounts at some point.

We should have concentrated on the core idea and launched a Minimum Viable Product (MVP) to test the concept, as we initially had planned even though we never had heard of the concept of an MVP. We kept building more features, since we always felt that “the service needs X because Flickr has it too” or “he/she said he needs that feature”.

In addition to all the features, we also felt that we needed an FAQ, long help texts, take a tour, etc. All this took a lot of time to make, but that was not the worst of it. All the features and extra stuff turned out to be a liability later when we wanted to make changes, since they needed to be updated every time. We even hired a lawyer to write our terms of use and privacy policy for the first version. I will probably write another post on this topic soon, to list all the reasons why features are poison and so dangerous!

Time spent in “feature hell” was away from implementing other planned things, such as good tracking of user behavior and support to run A/B tests to optimize funnels. Our tracking was something quickly put together before launch, only measuring vanity metrics, not really showing whether we are making progress or not.

I had read a lot about A/B testing and optimizing conversions, but did not know that it is the most important thing in our business. Optimizing virality, by measuring how many users one other user invites (virality coefficient), is the path to success, unless there are other ways to acquire customers at a decent cost. Of course, this means that the goal of all product decisions regarding design, features, etc. should be to improve the coefficient. This must be verified with an A/B test to be sure that progress is made. When the virality coefficient is something above 1, the next thing to optimize would be revenue from a customer. These activities must take place after a quiet beta launch, but the processes and infrastructure should be in order to be able to conduct experiments.

Another area where we could have spent more time and money on was graphics (and UI & UX in general). In the beginning we were kind of on the right track with mockups and wireframes, even doing usability tests, but the time pressure made us cut corners and just get it out. More features required more graphics and more complex UI, which required more time from us. It usually takes a lot of time for an artist to do good looking graphics and engineers are rarely top artists. The worst possible combination is when an engineer draws graphics in a hurry.

It was time to launch. Little were we aware of facebook, which was getting more and more popular and also slowly opening up in Finland. One of our big mistakes was not to try out all the other services, to fully understand what the existing services were already capable of. We had read about facebook and probably signed up a user account, but couldn’t imagine that people would really start using it a few months after that.

We realized pretty soon that PiX’n’PaLs did not grow exponentially. In the beginning friends started to use it and they invited their friends and so on, but the branching factor of the tree became really low after a few nodes (These were people we did not know at all).

We started collecting feedback from users and pop out more features and improvements. Generally a good idea, however, all these improvements were targeted to existing users. Instead, all improvements should have been directed by measurements of the virality coefficient.

For new users the service was visually “empty” and there were not really much to do, unless you started to create events and upload photos. Additionally, the service had lost its focus when we had implemented more and more features, like messaging and stuff that was not around the core idea.

Measurements showed us it was growing linearly with more people coming in every now and then from different sources, like blogs writing about us, etc. These users created some viral spread, but with a vitality coefficient way below 1, cooling off pretty quickly.

When I look back at the post it feels like we did everything wrong. We did lot’s of mistakes that we learned a lot from, but we also did some things right. Lots of companies spent even more time trying to get everything perfect before launch and most of them burned a lot more cash. For us this was definitely not the end of the story. I’ll tell you what happened in the next post coming soon…

It took me 2 years to get this done. Lots of people have been asking if I have a blog or why I am not writing one when we discuss topics related to my own web startup I had (or have, since it’s still running).

Also, working in a web business where bloggers are an important group of users, kind of forces me to at least try out blogging. Not having an own blog would be like selling cars but not driving one myself.

Additionally, I like a place where I can write random ideas and share them with the world and get some feedback. So by no means am I going to limit this blog to startup related topics, but instead keep it loose and see where it will take me.

Come back and check here in a few days or follow me on twitter to get notified about new posts…