_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.