In my journey, I’ve experienced the dynamics of both small and large teams. When starting out and the teams were small, the responsibility of product analytics invariably landed on my desk. As our operations expanded, we onboarded professionals to ease the load – initially business analysts, and then a mix of seasoned analysts and data engineers. Yet, despite these additions, navigating the analytics terrain remained a challenging, costly endeavor, often falling short of perfect execution.

Beginning a venture with limited funds often brings its unique set of challenges. One of the primary dilemmas is resource allocation. It’s tough to justify hiring analysts when the immediate need revolves around either developing or selling the product. However, understanding the product’s usage is paramount; it feeds into critical decision-making processes. A common misconception is that every bit of data is already tracked, just waiting to be queried. Many assume that any developer with database access can instantly provide answers to questions like, “How many users who signed up in March are still using the product weekly?” But in reality, it’s rarely that straightforward.

I completely grasp the complexities behind analytics, but I’ve always been hesitant about pouring substantial resources into it. Whether it’s shelling out for premium tools or hiring specialists, it’s been a tough call. So, more often than not, I find myself dedicating a ton of my own time to get the insights we need.

Throughout the years, I’ve been on a continuous quest to refine my analytics approach. I’ve tested various tools, delved into numerous books and blog articles, and gained insights from some truly brilliant minds in the field. While I’ve also made my share of missteps, it’s clear to me that things are gradually becoming more manageable. Yet, there’s still this lingering challenge. I can’t shake the feeling that many of the routine aspects of analytics could be streamlined further.

I’m confident that the insights I’ve gathered over the years could spare many startups from the pitfalls I’ve encountered. At the same time, I’m ever-curious and believe there’s a wealth of knowledge out there that can further hone my expertise and take me forward.

We’re navigating through some truly fascinating times in the tech world. The landscape is teeming with groundbreaking tools and advancements. Among these, the potential of AI in revolutionizing the field of analytics stands out. I’m eagerly watching its progression, curious about how it’ll mesh with what we know and perhaps transform our established methods.

I’m eager to dive deeper into this realm. Connecting with fellow entrepreneurs, CTOs, product experts, and business analysts is high on my agenda. There’s so much value in understanding best practices and swapping ideas. As I journey through, you can expect to see my thoughts and learnings shared on Twitter, my blog, and other platforms. It’s a way for me to both seek insightful feedback and contribute back to our vibrant community.

Seasoned developers, especially those indie hackers who’ve crafted multiple apps, often have their go-to templates. These are typically skeleton apps filled with essential functions, integrations to services like Stripe, marketing automation tools, and embody proven workflows. I’m inspired to create something similar, but with a focus on product analytics. Over the years, I’ve developed systems and methods that I’ve recycled across projects. With some refinement and expert feedback, I believe there’s potential to mold these into a valuable resource for others. Naturally, a product analytics template would center less on code and more on best practices and tool utilization.

If you share an interest in this domain and are keen on swapping ideas, I’d love to connect. Please reach out!

When I was younger, I used to play a lot of chess. There is a famous quote from a former world champion in chess, Capablanca: “A good player is always lucky”. I have come to realize that this applies to software development as well.

Now let’s look at what the real meaning of this quote is. If you thought it meant chess is a game of luck, you couldn’t be more wrong. What it truly means is that good players will (sometimes unconsciously) make good moves, placing their pieces on squares where they are more active. For example, placing rooks on open files and pawns on opposite color squares than the remaining bishop are both basic strategies. Following them will eventually lead to more opportunities and perhaps one of the opportunities will lead to victory. When an opportunity like this presents itself and some tactic can be used to win the game, it sometimes feels like luck.

In software development, following certain principles and patterns will keep more opportunities open in the future. An unlucky developer will often feel that it is hard to add new features and that the features do not really fit into the existing legacy. A lucky developer will often realize that there is a very easy way to add the new feature. Part of it is just because the lucky developer was following good principles when he wrote the old code. Many years of experience will also give a good gut feeling on which way to implement certain things.

Less experienced developers often do object oriented programming wrong. Even experienced developers sometimes break SOLID principles and that may lead to various difficulties when the codebase grows. Juniors sometimes get basic inheritance completely wrong and then wonder why they have programmed themselves into a corner. Many juniors do not know when to use composition and when to use inheritance, so they inherit classes just to get access to methods they need. Not only does this become a testing hell due to lack of possibilities to inject dependencies (stubs or mocks), but it will often lead to various problems later.

Let’s look at a completely hypothetical example, one that I was able to quickly come up with. Let’s say that we are building a racing game and have decided to model how the engine accelerates at different speeds; high acceleration at the lower speeds and then slowly decreasing when it gets closer to the top speed. We have a class Engine, with method:

1

public double getAcceleration(double speed);

Now a junior will start implementing the Car class, which has the properties: coordinates and currentSpeed. Additionally, it has the following methods used to control the car:

1
2
3

public void setGasPedalDown(boolean down);

public void runUpdateCycle(int time);

The runUpdateCycle() method is supposed to run an update cycle of the game, by first getting the acceleration and applying it to the speed (in case gas pedal was down). Then calculating the new coordinates based on the speed and time.

A senior developer will obviously use composition and let engine be a member of Car, and in fact most likely program against an Engine interface in the car class instead of the concrete class. Some juniors would perhaps jump at the opportunity of just changing the Engine class to be the car class and add the missing functionality there. Some junior developers might (although perhaps not that likely) inherit Engine class to get access to the acceleration method. Both of these approaches will of course work fine, but what happens the day when the producer of the game asks for a feature to let the user switch engine?

The senior developer would just implement a setter method, unless the senior developer already had implemented such a method for for dependency injection and unit testing purposes. Now the junior developers will either have to do some refactoring or continue on a path that will require a lot more effort and eventually will lead to bigger problems. The juniors will experience a lot of bad luck.

This idea of luck can probably be applied to many other professions as well. Or why not for all things you we do in our lives. When we have constantly bad luck, perhaps we should ask ourselves: are doing something wrong?

At the time I wrote my last post, about one and a half years ago, I was still at Kiosked and as a side project looking into a few FinTech ideas. There were two ideas I considered very seriously and almost ended up founding a company for either one of them.

The first one I considered was an investment assistant app. Most people’s life savings are going to waste because of mutual fund fees and we wanted to help them. For those unaware of this fact, let me give quick explanation. I could easily write 20 pages about this topic, but I will summarize the key points:

• The stock market is at least somewhat efficient (if not even fully efficient), so by randomly picking stocks you are likely going to do as well as most fund manager on average.
• Very few funds can beat the market enough to justify their fees and you cannot know in advance which fund it will be, so throwing the dice and investing in random stocks is actually a much better alternative (or to invest in the index through ETFs for example).
• The typical 1-2% fees don’t sound high, but the total loss over a 10-20 year period can be surprisingly high due to our world’s eighth wonder, which is compound interest. After 20 years, you may easily have 30% less wealth.

So we wanted to build a tool which serves as your investment assistant so anybody can do this themselves quickly at a reasonable fixed fee. The tool was going to help users choose a strategy and pick stocks fitting the criteria as well as help reduce risk. I won’t go into too much detail if we one day end up building this product ;)

Although most people we interviewed seemed to get the idea, it seemed as if it would be hard to sell to the masses through an online channel. Selling financial products is so much built on trust and a face to face meeting is needed to sell to the mainstream market. However, when meeting customers face to face, one would almost have to sell a product with a high fee just to break even.

Regulation in Finland is very strict compared to for example Sweden, which means that piloting a product like this would be an extremely expensive operation. Moreover, there were no easily accessible APIs to brokers in Finland (this is typical in FinTech anyway), so it is a long road ahead to negotiate API access (and possibly even development) with brokers or alternatively become a broker ourselves.

Piloting abroad was an option but not an easy one with our funding situation. The market is very small here in Finland. We looked at other companies who were doing something in this field or had been doing previously. We even met with a few of them to learn a bit more. Unfortunately it turns out that every one of these companies were extremely unprofitable or already bankrupt years ago. The only exception is brokers and companies selling mutual funds and various investment instruments with very high fees (exactly what we did not want to become).

Perhaps the last nail to the coffin for this idea was that my partner decided to drop out. This venture was not something I could pursue myself alone and the the initial funding was obviously lost when there was no team. I looked a bit for co-founders or ways this could be piloted with a reasonable investment, but then another idea seemed more lucrative.

Just like we lacked proper broker APIs and that was a problem for us, it seemed to be a problem for almost any FinTech company. Plenty of FinTech companies out there would like to access bank account data for various purposes, for example personal finance analysis, lender credit score evaluation, etc.

We all knew that the PSD-2 (EU directive) was going to force banks to open their APIs by January 2018 (this date has been pushed forward and is September 2019 at the time of writing this). Many FinTech companies were doing screen scraping to access this data and some lucky ones had special deals with the banks. We also knew that the date for PSD-2 would possibly be postponed, some banks would apply for extension and even after that there would be banks choosing to accept the fines just to avoid opening up their APIs. Finally, even if the new directive would help a lot, there would be fragmentation; many banks implementing their APIs their own way. No small FinTech startup would like to integrate with 5000 different banks and different APIs in EU.

I guess most of you can expect what we wanted to build. We wanted to build a so called “API Hub”, which is one standardized endpoint to all banks. We wanted to launch this pre-PSD-2 times, solve the bank integrations with screen scraping and try to get a big enough market share before PSD-2 comes.

Always with good ideas I do customer development, contact a lot of companies who I think could be potential customers and try to learn as much as possible. Many seemed to be interested in paying a decent price for this and there seemed to really be a market for this.

The biggest drawbacks were that there was competition, some companies had a head start already and had raised quite big rounds. Competition validates the market, however, in this type of business it is a bit tricky to differentiate from the competition. There were some options though but I suspect competition will push prices down and additionally FinTech companies will start implementing some integrations with common banks themselves to save on costs.

It was a tough decision to make. I wanted to do this so badly but I did not have a co-founder for this yet. I had two advisors and some developers who would be potentially interested in helping me out at a reasonable price.

As always, one adventure leads to another. I ended up dumping this idea for an even better opportunity. One of the companies I had met for customer development was Arkkeo. The founder, Tuomas Kohila, said he has been looking for a technical co-founder for his company. Arkkeo had been building a document bank for receipts, tickets and various documents one receives from companies. He had a new big vision and plenty of interesting ideas how we could take it forward. After some meetings, emails and phone calls, I ended up joining him instead.

So far it has been really exciting. We pivoted, launched a small pilot app in NYC to validate some key assumptions and have now landed back in the FinTech field. I will write more about this soon. In short, we are on a mission to create the standard how shops and restaurants can distribute appreciation and gratitude!

Also from a tech point of view this has been super fun. We modernized the tech stack and are using React Native for the app and React for the merchant dashboard. We also built validation as a key cornerstone in our agile development process, so that everything we build will result in learning and validation of hypotheses. I will write another post explaining this process, which I think is the best way for a startup to really make sure all development produces “validated learning”. We are going as “Lean Startup” as one possibly can in the field of FinTech.

In my previous blog post, I explained that I had been doing customer development for some new ideas related to wealth management. I did have earlier experiences in doing customer development in less regulated markets. I had gained my experiences from both being a real founder (Disruptive Media) and as a member of the founding team (Kiosked). Thus, I only had an understanding of how to do this stuff in less regulated markets, like photo sharing, e-commerce and online advertising. I thought the same process can directly be applied to wealth management as well. However, wealth management is a bit different.

First, let’s recap what these methodologies are. Customer Development, invented by Steve Blank, helps startup founders systematically search for a profitable and scalable business model and ensure there is product-market fit before putting all chips on the table and scaling up the company. The key idea is getting out of the building and validating whether customers really have the problem and whether they are willing to pay enough for the solution. Lean Startup is a similar approach, invented by Eric Ries, which is perhaps better suited for typical consumer web apps, where most experiments can be run online.

What both of these methodologies have in common is that they aim to minimize waste. A startup often needs to try out things quickly and learn from each experiment. When something does not work, most code (and work) goes to trash. It makes sense to minimize waste and only do what is absolutely necessary to validate or invalidate a hypothesis (or idea). The more efficiently a startup executes this process of coming up with hypotheses and testing them, the more likely the startup is to find product-market fit before it goes bankrupt.

The word hypothesis is used to distinguish ideas and assumptions from facts. They become facts once validated. Typical business hypotheses can be for example: what price the customers are willing to pay, what channels are used for distribution and cost structures. These are often easiest to document lightly in a Lean Canvas or similar.

Whichever process you use, in the end it all comes down to two steps: 1) coming up with business hypotheses and 2) validating them. Usually hypotheses are validated by conducting experiments. Sometimes this can be done by going out and meeting the customers and test selling the product. Other times it is necessary to build an MVP and measure conversion, retention and whatever else that is necessary for success.

Success in the search for a profitable and scalable business model will be determined by how well a startup performs both of these steps. The better a startup is at coming up with the right hypotheses, the fewer iterations will be needed. In the best case scenario, the first set of hypotheses happens to be right and the product immediately hits a homerun. On the other hand, the better a startup is at performing the second step (testing of hypotheses), the more iterations it can do before reaching the end of its runway.

Most of the startup literature focus on the second step, which is mostly about process and execution. It is easier to become good at this step. Learn to design experiments which will result in maximum learning with minimum effort. Good engineers also develop stuff faster and the whole engineering team can also improve its process. There are tons of books about these things so there is no point discussing it any further in this post.

It is much harder to create any formal method to come up with good hypotheses (in other words great ideas). It is a combination of experience, knowledge and creativity. It helps to have a long background in the industry or being a heavy user of similar kind of apps. A heavy user of some specific apps may have some painful unsolved problem and a vision about a solution.

I used to think that ideas don’t matter and that it’s all about execution. This is the typical mantra that is repeated everywhere. Books, like Lean Startup, give the impression that if you do not know something you just test it and find out. This is all very good advice and also applies to wealth management and FinTech. However, in certain businesses testing and validating hypotheses is harder and more expensive. Wealth management and many FinTech businesses unfortunately belong to this category.

Why is this the case for wealth management?

1. Trust is everything

One reason is that it is a business where the customer’s trust is everything. This means that your sales conversions are completely dependent on how much people trust you and your brand. Hence, putting up a landing page to test conversions will not necessarily be a reliable experiment to validate whether a wealth management solution will have enough interest.

Since it’s all about trust, a startup’s success will depend a lot on how successful the company will be in establishing the trust within the core audience. Most likely building such trust is going to take some time and this is very hard to test in advance. Likewise with conversion rates and willingness to pay, they are both dependent on people’s trust.

Of course trust in brand is important in any business and has huge impact on conversion rates everywhere. Still, I think wealth management is at the high end of the scale. I feel that when doing customer development in some other markets, it is much easier to find earlyvangelists and visionary customers who are willing to be the first to try new things more eagerly. In fact, they often prefer that others have not yet discovered the new product and therefore do not want to see references either. However, in wealth management also earlyvangelists and visionary customers want to be sure it’s a trustworthy service and say that they would like to hear that a friend used it or something similar.

2. People don’t want to share financial information with strangers

Another thing to keep in mind is that people are not really open to share all financials with strangers. Additionally, people are a bit embarrassed to admit how unprofessionally they handle their own investments and often try to give a better picture of what they are actually doing. This adds up to the uncertainty.

3. Regulation

A third difficulty is regulation. In many countries FinTech startups can run small closed and controlled experiments without all the necessary licenses. This is unfortunately not the case in Finland. Depending on what you want to do, licenses can take a very long time to obtain. There may also be requirements for the company’s staff and its financials. This is extremely bad news if you just want to test something quickly with the help of an MVP.

4. Things happen slowly

Last but not least, things happen very slowly in this field. Banks and other financial institutions move very slowly and it can take ages to get any partnerships done with anyone. The situation is even worse if you need any integrations with them.

SOLUTION

Since the 2-step iterative process of coming up with hypotheses and validating them can be extremely slow and expensive, we either have to succeed with fewer iterations or accept greater risk. Either you run the iterative process and make decisions based on very inaccurate data or you just accept bigger risk and hope you are right. I have a strong feeling that in this business one just needs to take a bigger leap of faith and have a lot more funding at an earlier stage.

What does this mean?

I think it means that startups need to put way more value on the idea phase (coming up with good hypotheses). I think it is important to get the initial “guess” close enough, so that potential pivots will not need new licenses or new deals and integrations with slowly moving banks and other big players.

How to ensure that the initial “guess” is close enough?

I think that especially in wealth management and FinTech, it is vital to have people on the team and advisors who have a background in the industry. People who can help make sure some details have not been overlooked, which could kill the business later. Additionally, I think it is a good idea to make sure there is room for error in the initial hypotheses because there probably is. In other words, the business must look extremely profitable on the spreadsheet, so that the actual reality will also be acceptable.

I want to still say that what I just wrote also depends largely on what kind of a startup we are talking about. There may also be some concepts in wealth management which can easily be pivoted in any direction without that much hassle. Stock pickers, alternative data services and various calculators and expert tools are not under regulation and fall into this category.

Founders should be aware of the stale nature of the field and understand that pivots here and there are not that easy. When I got in, I underestimated the impact of the regulation and how slowly things go forward in this field.

CONCLUSION

So as a conclusions, this business is very stale and trying out anything is expensive and time consuming. Therefore, startups cannot as easily run experiments and pivot here and there. Instead, startups need to have an experienced team, preferably with industry background. This way it can improve its odds of being close enough with its initial hypotheses, so that no major pivots are needed.

This is my current understanding of this business, I’d be happy to hear what you think?

It’s time for me to give an update on what I have been up to lately. I was lucky and had the opportunity to take a break from my daily work and take a look at a few market opportunities in FinTech.

Already during 2014 and 2015 I tried out some new concepts related to trading stocks, mainly TradingDrill and some ideas related to sentiment and alternative data. We launched a low-fidelity MVP to test initial demand and how the channel to reach customers worked. Thereafter we continued doing customer development and interviewed everyone who signed up and could be reached. Unfortunately, we learned that the business model was not profitable and the customer acquisition costs were quite high.

We turned a few stones and investigated some related ideas which came up during the customer development process. Ultimately the interest faded away. Regular work had the highest priority and almost required our 24/7 attention. So the ideas were put on hold sometime late 2015.

At a startup event, a few months ago, I happened to meet Petri Asunmaa. He was pitching his idea about a tool to help stock investors. We started discussing after the event and eventually decided to join forces and figure out what could be done. This time it was about investing and not trading. There was huge potential in the field.

We started doing customer development almost by the book. So far during this process we have interviewed about 100 potential customers, banks, brokers and various players in the industry. Petri’s blog post summarizes quite well our findings. We also pivoted our concept a few times, starting from a tool for non-professional “do it yourself” investors to a wealth management solution. We gained a significant understanding of the business and how customers really behave and the reality is quite surprising.

Additionally, we learned a lot about the difficulties of FinTech startups entering the market. Typical Lean Startup methodologies are difficult to execute and they need minor adjustments due to the nature of the field. Partnerships and integrations with existing big players take a very long time, not to mention the regulation and applying for all necessary licenses. You cannot just one morning decide you want to test if customers are interested in buying stocks through you and deploy your MVP code in the afternoon, measure and learn. No, you need a different approach in this business.

I will write a separate blog post about lessons learned about customer development in wealth management and FinTech. The biggest takeaway is probably that one needs to take a bigger leap of faith than in other software businesses. This usually comes in the form of bigger initial investments as well as larger and slower MVPs.

During the process, many other good ideas came up. Some related to trading or wealth management, others related to disruptions in the industry, like PSD-2. We are now working at a better plan how to move forward with a few smaller leaps of faith instead of a gigantic one.

We are interested to continue discussing with other companies within wealth management and see if we could find ways to validate our ideas more easily and do something together. Both with new startups and existing players.

PHOTO EDITED FROM WIKIMEDIA COMMONS USER MORITZ WICKENDORF

A long time ago I wrote a series of posts about my own startup. For the readers with more time and patience, I suggest you pour a glass of scotch (or whatever your favorite drink is) and start reading from part 1/3. I certainly had my fair share of scotch when I wrote it.

For the rest of you, I’ll just give a quick summary:

Together with my co-founder Jarl Törnroos, we built a photosharing website, which allowed users to gather their photos around shared events. All events together formed the collaboratively documented story of each and every user’s lives.

This did not become a major success for various reasons explained in more detail in the full post. At that time we thought monetization was our biggest problem to solve. We could not have been more wrong and monetization should have been the least of our worries with the small user base we had. Anyway, we wanted to monetize our small user base by selling print products (like photobooks) from the photos people had uploaded to the service, and that is what we did.

There were not really good 3rd party solutions we could use for this purpose, so we set up to build our own. That eventually led to building a full blown e-commerce solution specialized for selling print products. Here we kind of pivoted, although in practice it was more like branching or spinning off a new business.

We productized the e-commerce solution and sold it (as SaaS) to a few photo shops who needed an online store. Unfortunately this was not really a good business either and it was hard to compete with existing big players like Fuji, who already had way over 50% market share and sold a full service, including an e-commerce solution, photo machines, paper, etc.

We had to try something and the next thing on the list was the hypothesis that other websites and photosharing sites would also want to monetize their images by allowing users to buy them, just like we wanted and did with ours. We launched together with Riemurasia, which was one of Finland’s biggest websites at that time. Now this generated real revenue at first. Unfortunately we encountered various difficulties, which we were unable to overcome with the money we had left.

That forced us into doing consultancy, which actually is nothing else than a safe way to fail. So we built whatever software anyone was willing to pay us for. We took projects from various clients. One of the projects was for the guys who are behind Kiosked. Eventually, we put aside all our own other businesses and joined them as partners when they founded the company Kiosked.

This is where the story ended in my previous posts and a lot of things have happened after this.

The e-commerce solution had been running for itself for about 4-5 years. Almost no maintenance required and very few incidents as long as we remembered to upgrade the servers before the huge peak in usage before Christmas. Perhaps the bureaucracy caused the biggest headaches, which consisted of sending invoices to customers, filing VAT reports, etc.

Now last year (2015), we sold the whole e-commerce solution to MV-Kuvat, a photo shop who had been our customer ever since the beginning. Their engineers are taking care of all future development work and will be able to customize it better for their own needs.

Also worth to mention is that today we closed the Pix’n’Pals photosharing community, which was founded 9 years ago. Although that is very sad, it frees up room in our minds to focus on other things. Sometimes it’s good to cut your losses and move on.

The exit for our e-commerce solution was far from anything you usually read in Techcrunch. No Ferraris or private jets for us. Still, it was an exit, which provides some kind of closure and recognition that what we had built was really something of value. That feels good and that is worth to celebrate!

Life has been quite hectic lately. Hard work at Kiosked and four kids at home leave very little room for additional hobbies. Still, I have had the time to write two posts on Kiosked’s blog about microservices:

Discussing pros and cons of microservices:
http://blog.kiosked.com/en/blog/to-microservice-or-not-that-is-the-question/

Kiosked’s approach to microservices:
http://blog.kiosked.com/en/blog/kioskeds-approach-to-microservices/

Now it’s time to get back on track and continue writing. But first things first. It was time to get rid of the damn Wordpress. Wordpress has been a liability. It is all the time under attack. Mostly various DDoS attacks on weak points like xmlrpc.php, etc. But there’s more. The technical design of wordpress is really flawed. All PHP files are public, including all the plugins which may have their own security holes as well. It’s a nightmare. I don’t have time to deal with that kind of shit.

Now I have switched to Hexo. Thanks to Perry and Daniel for the recommendation. Although I am not too keen on writing in markdown, I will sleep a lot better during nights when I am just running plain HTML files instead of a buggy Wordpress.

Ok, this was a short post. I have learned that the best way to get started is to just do something quickly, even if it is small. So more posts will follow…

You would think that startup founders and stock traders have nothing in common, but when it comes to characteristics needed for success, it turns out that they have to overcome many of the same psychological difficulties. I was reading the book Trading for a Living, partly because I am involved in a software project related to it and partly because I have been doing some trading as a hobby myself. A major part of the book is about trader psychology, like how to defeat your inner demons to succeed. I noticed that this stuff really applies to startups as well.

1. Dishonesty and Postponing Losses

Honesty to oneself is important in any field. The book advocates keeping records of all trades and planning ahead. Before doing a trade, one should have a plan when to exit the trade and always put a stop-loss to limit the amount of money that can be lost on the trade. Amateur traders sometimes neglect this and get stuck with their shares when prices decline. Their hope of some magical event turning the price trend around keeps them from selling. For them it is always possible to find some indicator giving false hope. It is human nature to postpone losses.

The record keeping and planning in the startup world is covered by basic customer development, where you write down your business hypotheses and your plan to test them. This includes what the result must be in order for the hypothesis to be valid. Steve Blank, the inventor of the customer development model, also speaks for the importance of writing down the exit criteria (pass/fail) of a test before executing it in his Startup Manual. It is too easy to find some other metric showing positive signs. Founders need to be honest with themselves, otherwise they will hurt themselves just the way traders do when they hang on to their shares to the bitter end.

It is very easy to fall into this trap. For example a simple MVP (Minimum Viable Product) with a landing page may be used to test general interest in a new product. One might set a specific requirement for the signup ratio of new visitors coming to the page. If there are too few signups but instead some social shares with discussions and long visits to the page, the founder can easily find a way how to interpret this as a success even though it is not.

The new observations about how users shared and discussed the page is still valuable insight. It should be used to plan new tests. However, it cannot be used to pass the current test, that had a different requirement. It is as easy for a founder as it is for a trader to find false proof justifying the current strategy. In practice, both are just postponing the losses.

I fell into this trap in my own startup. We did not plan our tests well enough with clear exit criteria and we were not fully honest to ourselves either. We ended up hanging to the same idea too long, hoping for some miracle to happen while implementing more features to better support the wrong idea. The pain we went through is actually quite similar to what a trader feels like when his stock is going down and he keeps buying more in hope of a change to the trend to get even.

2. Repeating Mistakes

Traders should try to look for repetitive success and failure patterns in their trading records. They should write down why they thought the trade was good, what they where feeling, etc. A startup that has been running for a longer time and tried out several different things can probably find similar patterns in all experiments they conducted. Even though all ideas would have failed, it still would be possible to find common mistakes that were repeated or common reasons why stupid things were done.

A startup should be able learn which types of experiments were unnecessarily expensive and could have been tested in a more efficient and cheaper way. I bet many failed startups wasted most of their time on a few very bad ideas/features, just like failed traders usually destroy their accounts with a few really bad trades. If traders can find out what the common denominator is, why couldn’t startups?

3. Irrational Goals

Another very interesting point in the book is that many traders are consciously or unconsciously trying to satisfy irrational goals when they trade. The one and only rational goal a trader should have is to make money. Typical irrational goals a trader has are getting some excitement into their otherwise boring lives or honor from a big win. These irrational goals hurt traders. I think the problem of having irrational goals is even worse for startup founders, who can have quite many of them.

When I think back of the times I had my own startup, I remember how good it felt when Mashable, TheNextWeb and lots of other tech blogs wrote about our first product. In terms of product-market fit, we were not ready for a full launch at all. By doing a big press release, we satisfied an irrational goal of getting acknowledgement for all our hard work. Doing a big launch before product-market fit is often considered bad, because potential pivots and other corrections to positioning, etc. are going to be very expensive. Unfortunately it is very hard to keep oneself from pulling the trigger too early.

Additionally, I remember many times thinking what completely irrelevant people (to the business) are going to think about our product or some feature. What if we spent too long time iterating and experimenting? What would people think of us after 6 months if we only had built something small? To look good in front of other people is an irrational goal. Adding more features is an easy way to satisfy that irrational goal. Allowing this kind of thoughts in your brain is dangerous and may take you one step closer to featurism.

Irrational goals must be satisfied elsewhere. Maybe it should be some hobby or something less important. Actually, to be really honest, I use this blog to satisfy some of my irrational goals.

_Photo edited from original creation by L. Whittaker _

There has been a lot of discussion about whether kids should be taught programming in school, even as early as in preschool. Like always, there are different opinions on the subject. Many based on the question whether everyone can learn programming or not. Some say it is only for certain kind of people. Usually at basic programming classes in universities, it seems as if some people just “gets it” and others don’t. What could be the reason? I have my own theory.

I remember reading from Malcolm Gladwell’s book, Outliers, that there had been a study showing that the success of a math student is directly proportional to how much time the student is willing to spend on a problem before giving up. I think the same applies to programming as well. Even though most programming tasks do not require any knowledge in math at all, programming and math have one thing in common; they both require the same kind of logical thinking.

A lot of people try to learn math in school by trying a little bit on one problem and then giving up and moving to the next one. Almost as if they would be practicing throwing darts. You throw a dart, you miss the target, you throw another one, you might get closer, a third one… and so it goes on. They think that they should know how to solve a problem immediately. If they fail by not seeing the solution immediately, they move to the next problem. They will go through all problems but fail on each one.

During my studies, I remember seeing people desperately trying to learn programming exactly this same way. They got a problem and thought that they should be able to just write the code immediately. Sometimes they were able to write something but realized that it did not compile or it did not work for some other reason. They almost immediately gave up and thought that they failed, after which they moved on to the next problem and did the same all over again. One completed task is better than having tried on 10.

I believe anyone can learn programming, if they just accept the fact that it is something that requires time. That first exercise takes as long as it takes, but once it is done you have learned a lot. Having this right attitude will make sure you will later master any more difficult language construct, library or anything else. Even though it is always frustrating at first, once you understand how something works, a lot of things start to make sense. You will see that there are patterns. Bigger pieces of information will start coming easily. In the end you may not need to spend that much time after all. You just need to accept that the initial effort required is huge and you need to be prepared to sacrifice as much time as is needed.

Now if they plan to teach programming in school, how are they going to get people to do this in the right way. I think they have failed to do that in math. There is a huge risk that this wonderful subject is going to be taught the wrong way. Imagine that there is a 2 hour class and the teacher will naturally want to stuff in lots of exercises. Students who get 10 exercises for 2 hours will not feel good about spending 3 hours on the first one. They will ask for help immediately or copy-paste from examples. That is the only way to get something done so it looks like you tried, while a few students are going to spend 20 hours during the weekend to get the initial boost and will therefore easily fly through the rest of the course.

I am going to teach my kids programming and I hope I will do it the right way!

Photo by Paul L Dineen

It has been fun blogging for a year now.  Only 11 posts so far, but I have gotten a lot of good feedback from different people. Follow me on twitter, more posts coming soon…

Follow @frans81

Do you know the difference between scalability and performance? Which one do you need? Whether you are building, buying or selling web-based software, this post will teach you what you need to know in order to make the right choice.

I touched the surface of this topic in one of my previous posts, Scalable, Flexible and Cheap, Pick 2 you can’t have All 3, when discussing how to understand customer requirements regarding scalability. I learned that when a customer orders a software project from you and says “It must scale”, it can basically mean anything.

A few questions should help understand whether the customer means scalability from a technical- or business point of view. Business scalability means whether the business model can be scaled for a bigger audience. This is a bigger concept, covering market, process, localization and various other properties, including the technical scalability. Engineers often forget that scalability is not always only technical. However, in this post I will only discuss the technical one.

Having narrowed down to technical scalability, there is still room for misunderstanding. The customer may actually mean performance. If you are the subcontractor, you need to ask the right questions to figure this out. If you happen to be sitting on the other side of the table and you are outsourcing the software development to some other company, it is very good to know the difference too. There are plenty of subcontractors out there who just implement whatever was originally requested.

In various discussions, I hear all the time people say “this does not scale” when something is not as fast as expected or “Wow, this is really scalable” when something is fast. This is another reason for writing this post. Scalability and performance are not synonyms.

A high performance website is what one could call a “fast” website. Sometimes this is all you need. You might know in advance how many users are going to use it but require that the page responds quickly. This is usually achieved by code optimizations, bundling/packing/minifying resources and doing various other configurations.

A high scalability website is a website, which performance-level can be maintained by adding more capacity when the load increases. Some websites need to scale for growing traffic, others for growing amount of data. Many need to scale for both. A website can be slow and perform badly even if it scales well.

Regarding scalability, there are two types of scalability: vertical and horizontal. Vertical scalability means that capacity is increased by upgrading the server(s) to more powerful ones. Horizontal scalability means that capacity is increased by adding more servers of the same kind to the system. Horizontal scalability is preferred, since costs will often grow somewhat linearly to capacity. When scaling vertically, costs will often grow exponentially to capacity, since hardware gets very expensive at the high-end.

In practice, many systems only scale horizontally to a certain point. This is usually because they consist of many components, of which some cannot be scaled horizontally. When these components become bottlenecks, they need to be scaled vertically, resulting in a non-linear cost structure.

As earlier said, a website can perform badly even if it scales well. For example a website having a response time of 2 seconds could be considered slow and performing badly. If this website can handle 1000 users with one server, 10000 with 10 servers and 100000 with 100 servers, still maintaining its performance level (2s response time), it would be considered a highly scalable website.

Scalability and performance can have dependencies, both with positive and negative impact on each other. Consider a website, which architecture is changed into a more scalable Service Oriented Architecture (SOA), resulting in many more layers and web services. Requests may have to pass several layers causing a performance drop. On the other hand, some performance optimization tricks (or hacks) may be hard to scale. However, performance optimizations will often save resources, which will let you handle much more traffic with the same servers; hence, you will not reach your bottlenecks as early.

So, back to the question, which one do you need?

If you expect traffic or amount of data to grow, you need an architecture that can be scaled to meet the future needs by investing in proportion to the need. Hence, you need a horizontally scalable website.

If you know the traffic and amount of data is going to be within some reasonable known boundaries, but expect the website to be fast, you need a high performance website, designed for the specified amount of load.

Whichever you go for, remember that premature optimization is the root of all evil.

This post is about one common mistake startups often do. We did it when we built the PiX’n’PaLs photosharing website and later kind of repeated it in our e-commerce solution (read the story here). The mistake I am talking about is implementing more features without fully understanding what all the implications are. There are always a lot of great ideas popping up, but you can probably only pursue 1% of them. Trying to do to much is a common cause of failure; thus, the saying “Startups don’t starve, they drown“ has become so popular. In order to help others avoid drowning, I decided to list 10 things for startups to think about before implementing another feature. These are based on my own experiences, others’ stories I have heard or read about and a lot of common sense.

Experienced product managers use the word NO often. When I was younger I didn’t get them. Now, having been an entrepreneur myself, I understand them perfectly. I have really started to like Steve Job’s famous quote “Innovation is saying no to 1000 things”. Focus is essential and when you have one good idea you always find thousands of other ideas that would be cool. It is so easy to fall into the trap of implementing ideas here and there.

It is vital to understand that there are huge hidden costs in implementing a new feature. A feature may be really cool and seem to take only a few days to implement. An inexperienced product manager may happily keep pushing this kind of features into production even before product-market fit is found. The feeling is good when progress is being made and there is a lot of positive feedback from others. If the product gets poisoned with various different features that don’t fit well together before product-market fit is found, the company will be in a “feature hell”. At this stage it will be hard to find product-market fit, since all changes are slow and require a lot of work.

Let’s look a the different reasons why features can be poison:

1. Every new feature implemented requires more effort (the obvious one)

Every new feature obviously needs implementation effort. Additionally, a lot of documentation, manuals, FAQs, legal documents, etc. need to be updated. Some of these documents can be seen as features as well. Do you really need an FAQ or a manual? Will they become liabilities and slow you down? Furthermore, startups often put a lot of effort into analytics, which is used to learn about customers. This means that usage of the new feature need to be tracked. Finally, there may be a need to monitor the health of the feature in some cases, which will also result in more implementation work. What the developers initially thought would be a one day task suddenly became a huge operation that requires several people to get involved.

2. Every new feature may need maintenance and support

Having a new feature requires more maintenance work; someone needs to analyze all measurements collected, monitor the health of the system, etc. The new feature may also require more sales- and customer support.

3. Every new feature uses resources

New features may use more memory, hard disk or some other resources. All these have a cost.

4. Every new feature increases complexity

New features will increase the complexity of the system. This is dangerous for a startup still in search for product-market fit. Very often the complexity grows exponentially, because features have dependencies. This means that when you specify (or implement) feature X, you need to take into account that features A, B, C, etc. may or may not be used together with feature X. Sometimes it is possible to design everything in such a way that they are independent. But often when we solve real world problems that real customers have, we may not have that luxury. A well thought through spec and good software design will help deal with the complexity, but only to some degree.

5. Every new feature will cause some loss of flexibility

When there are more features and more complexity (indirectly), it will obviously be harder to do changes. Both technical- and business/logical complexity will require that a lot of time is spent on analyzing the impact of a change or new feature. All combinations must be thought through. This is very bad for a startup that has not yet found product-market fit and may still have to pivot.

6. Every new feature increases risk of bugs

Complexity will make it harder for developers to understand what the impact of a change is going to be. Also, high logical complexity will often also result in underspecification of new features and everybody will not share the same understanding of how the new feature should work together with everything old. Misunderstandings will lead to bugs.

7. Every new feature may introduce security holes

As complexity can lead to bugs and low quality of code, these can in their turn lead to security holes. Like with bugs, if the complexity is high and it is unclear how something is supposed to work, you will easily end up with some security holes in both code and application logic.

8. Every new feature must scale

The more features you have, the more potential bottlenecks you have. Complexity and dependencies between features are going to make it even harder to scale. Consider a consumer web application, which hits product/market fit and starts to grow rapidly. You have to cache content shown to end users. You have a requirement that the data must be fresh (changes visible immediately). The more different features there are that can indirectly have an impact on the data that is going to be shown to end users, the harder it is going to be.

9. Every new feature results in a longer learning curve

The more features and complexity there are, the longer it will take for new team members to be able to work independently and become productive. This applies to both developers and other employees.

10. Every new feature which is not used by the user will decrease usability and value

Every feature that is not used by the user, will distract the user from achieving his/her goal. Many studies show that a lot of options may result in the customer not choosing any because making the decision becomes so hard.

Additionally, when new features are added that do not perfectly fit into the software or are not fully thought through, the overall experienced completeness of the product will decrease. This happened to us in PiX’n’PaLs. If you thought our first version felt 50% complete, after we had added some more features that were not really core, you probably felt it was 40% complete.

At the time we realized that we should have been spending 80% of our time fixing old and 20% developing new, we had already implemented so many features that raising the degree of completeness required a lot more effort.

What happened in PiX’n’PaLs was actually that new features introduced new requirements. First our puzzle was missing a few pieces. Instead of looking for these pieces, we started building new puzzles next to the core puzzle, so the result was that we were missing even more pieces to the puzzle than when we started.

A startup should build a Minimum Viable Product (MVP). The product is either viable (can be used to validate a hypothesis) or it is not viable. The product cannot become any more viable by adding more features.

What to do then?

A startup needs to try out things and they may be complex, since customers need real world problems to be solved and the real world is complex.

Here’s some advice:

• Seriously try to keep things simple before product-market fit is found. Look for different trade-offs to reduce dependencies between features if possible.
• Narrow down the target customer segment.
• Focus on only one revenue stream, one Growth Engine, one X, one Y, etc. at a time. And do it well. Fail fast and move to next one.
• Avoid automating everything. Experiment by doing manual work.
• Really force yourself to think 80/20.
• Remove features and old stuff that do not add enough value.
• Focus on the goal and how to get there. Is this new feature really the way to get to the goal? There is most likely one biggest problem at the moment that you must solve in order to succeed. That problem is so hard and frustrating that it feels good to concentrate on some other tasks instead, like implementing some other new cool features. Don’t fall into this trap!
• If possible, keep things modular and reduce dependencies between features
• If you can identify key components that are unlikely to change during pivots, go for a Service Oriented Architecture (SOA). This is easier said than done ;)
• If you find yourself in the “Feature Hell”, try a Zoom in pivot, which means detecting one feature that is used, and making that the product and hiding everything else. If that is too hard to do, due to complexity, take the knife, be really aggressive and cut off all dead meat (features) from the product. This is what I would do if I would continue PiX’n’PaLs or any of my other old projects.

Picture Source: Jesse Sneed / Flickr (Creative Commons)

There are plenty of people who feel that a startup should not do TDD, because it slows down the development in the beginning. The only goal of a startup is to find product-market fit as quickly as possible. Probably 90% of the code is anyway going to trash in the beginning. Progress is measured by validated hypotheses and not features, lines of code or anything else. The usual argument is that things change too quickly and the built MVP is anyway so simple that the benefit from TDD will not show off, since the code will be in trash before the velocity starts to drop. The blue curve in the diagram below shows theoretically the progress made when all code is thrown away after each experiment. One will have the opportunity to start fresh each time with no technical debt, so the average velocity will be quite high. This can probably only be done for the first experiments, after which there will be a better understanding of the users/customers and code reuse will start to pay off.

Some TDD fanatics argue that TDD actually speeds up development no matter what. The developers just have to learn to do it efficiently. Additionally, maintainability of the code is considered important in a chaotic environment where things change quickly. A final argument is that once product-market fit is found, it will be hard to take things forward and scale up when there is an enormous technical debt. This holds true for most software. The only exception would be apps, where the market risk is so high that one needs to start validating hypotheses with some really simple tests that go to trash immediately like illustrated with the blue curve in the diagram above. Completely new concepts for new markets meet these criteria.

Another common argument is that the software can be a bit buggy as long as it is good for validating a hypothesis. I read an interesting comment in Hacker News from a user called DanielBMarkham, that “technical debt can never exceed the economic value of your code, which in a startup is extremely likely to be zero”. I think this should be understood so that the cost of a rewrite is very low in a startup. This should not be be mixed with quality. Low quality with bugs will be a lot more costly than what was invested in writing the software. Even if the software is just a simple test of a business hypothesis, a bug may result in wrong measurements, which will eventually result in wrong business decisions.

How high quality do you need in your MVP? Let’s first look at what quality means. Colin Kloes wrote a good blog post about the importance of a team’s shared understanding of quality. He said “Software quality is characterised by how well the software has solved the user’s problem.”. Now think about Steve Blank’s definition of a startup: “A startup is a temporary organization designed to search for a repeatable and scalable business model”. The only purpose of the software is to help the founders find a repeatable and scalable business model. The software itself is the test; testing the business model that the founders have come up with. This means that quality is defined by how well the software is able to help the founders test their business model hypotheses.

In order to be able to test hypotheses, it is vital that all analytics are correct. A bug in the tracking of some important event that we are testing will result in wrong measurements, which may result in the wrong decisions taken by the founders. Also if there is a bug making the software unusable, the founders will never know if users were not using it because of a bug or because they were not interested. By putting it this way, quality is suddenly more important than ever.

Usually MVPs do not have much complex code, mostly just getters and setters. On the web they may sometimes be mostly html/css with some data retrieved from the database. In these cases there will not be a need for many unit tests. However, it is still a very good idea to have the TDD attitude from start. You do not know in which direction the MVP is going to evolve. You might want to have a couple of automated acceptance tests around the most important features to be sure they work as supposed to, ensuring your experiments are conducted correctly. Also, by doing this you will have the necessary infrastructure already in place to scale up operations when product-market fit is found.

In many cases the first MVP can be just an almost static HTML-page as an experiment to see how many users would sign up for a new concept. Some concepts can also be tested with something built on a CMS or even just static HTML-pages updated manually by a user. In these cases it would not make any sense to do TDD. However, I think these are special cases and at some point the founders are going to need own code to validate hypotheses further.

The software a startup is building, no matter whether it is an MVP or not, will have a purpose. If the software fails to deliver what it is meant to do, it is useless. Thus, bad quality is not acceptable. My conclusion is that the software is an important tool for the founders to validate their hypotheses. If the tool breaks or the technical debt becomes so high that it is no longer possible to use it for validating hypotheses with quick experiments, the founders will not be able to do their job of finding a repeatable and scalable business model.

All too often non-technical people put too much weight on scalability at a too early stage. When working as a consultant I discussed many projects with different startups wanting to outsource the development of their software. Many of them asked me for an offer of a web based app containing lots of different features. Sometimes there was a requirement that the app must scale to millions of simultaneous users or something similar to that. Everything was planned with a “Build it and they will come” mentality, which is very rare to work on the web. The problem was that most of these startups did not fully understand what scalability meant. People think of scalability in 3 different ways:

1. That the software is built in such a way that costs grow linearly when traffic grows or amount of data grows; meaning that scaling up happens by just adding more servers. This is referred to as horizontal scalability.
2. That the website can handle heavy traffic without any actions. This means that option 1) is done and there are lots of servers in place already.
3. The website is fast and responds quickly. I like to call this a high performance website, which I see as a different thing than a high scalability website.
   Unfortunately most people want type 2 scalability. Usually after learning about server costs and what needs to be done in practice, they want type 1 instead. But depending on the complexity of the app, type 1 may also require a significant amount of work in order to scale horizontally above a certain threshold.

A common misconception is that scalability is always good to have in place. The truth is that premature optimization in terms of scalability is very bad. Scalability often results in loss of flexibility. I define flexibility as the possibility to easily make modifications to the software or pivot quickly. This is a very important tradeoff that one needs to understand; therefore, I am going to explain what needs to be done from an implementation point of view to achieve these properties in web software. Jump directly to “What should you focus on”-subsection if you feel it gets too technical.

Flexibility

To have a fully flexible system, you may want to go with a relational database and a fully normalized schema. This makes sure there are no inconsistencies in the data whatever you do; Thus, it should be quite easy to implement any new functionality with various ad hoc queries to the database. You probably want to let the database take care of as much as possible. Preferably you want to run everything on one server, but having a separate database server and a few identical web servers behind a load balancer should not harm the flexibility.

Scalability

Depending on your application, your first step to a more scalable architecture may be caching. You want to minimize the load of the database, so you cache data that is used often. If you need to show fresh data to your users, you need to delete the affected cache entries when data changes. As you see, developers need to take this into account and they can no longer just do ad hoc queries to the database.

Additionally, you may need to take in new technologies, like a search engine. Whenever data changes in your database, you need to update the data in the search index and other potential storages to avoid inconsistencies. New features may also require schema changes, which may need to be taken into account in all different systems. You have lost a lot of flexibility.

Furthermore, to be able to scale for really big datasets, you cannot just do complex database queries. You need the data to already be in the format you are going to use it. This requires denormalization, which means that you have a lot of redundant data. An example of denormalization could be a photosharing website keeping a separate count for the number of comments an image has, in order to be able to easily sort images by number of comments. Without this number, the database would have to count the comments each time. The more the database is denormalized, the harder it is to do quick changes. You may also want to switch to a NoSQL database if you plan to denormalize a lot.

Finally, scalable apps usually use plenty of application specific tricks. These tricks may not work if there are bigger changes to the application logic. This means that when functionality changes, the developer needs to come up with a new way to scale; thereby spending a lot more time implementing the change.

Flexibility and scalability together

Sometimes you need both flexibility and scalability. In this case you have to define within what scope you need to be flexible. Full flexibility is not going to be possible. However, by planning how to migrate data, re-calculate redundant data and using several other tricks, it should be possible to be flexible within the scope.

You may be able go into a Service Oriented Architecture (SOA) and build web services for retrieving any kind of data needed for features within the predefined scope. This way the scalability can be implemented in the web services (application servers) and developers can have quite good flexibility when developing on the web servers. The broader the scope is, the more expensive it is going to be.

What should you focus on?

Now we know that scalability will require certain design decisions that will make it harder to do changes in the future. If there is a need to be both scalable and flexible, you need to have a good understanding within what scope to be flexible. The cost wll be higher since the implementation is a lot harder. I think the best way to illustrate this equation of flexibility, scalability and cost is by using a ternary plot. Cost would refer to both time and money:

Now that you know the basics, the question is where do you want to be on the triangle? The wrong decision can be fatal for a startup, so understanding the pros and cons is important. I think it all comes down to what kind of a startup you are and at what stage you are.

Most new web apps built by various startups have enormous market risk, especially the ones trying out completely new concepts in new markets. Every startup has a runway of a certain length, during which it needs to find a profitable and scalable business model and fly or run out of cash and die. It needs to test and validate hypotheses as quickly as possible. This needs to be supported technically, therefore it is extremely important to be as flexible as possible in the beginning.

When product-market fit is reached, usage starts to grow rapidly. Now scalability becomes more and more important. It may be tempting to still keep things flexible and go for various other great ideas that come up here and there; however, this increases the cost and can be very dangerous for a startup which does not yet have all its processes in place. Therefore, the best approach is probably to productize what works and just scale up loosing as much flexibility as necessary. The fewer features got implemented during the flexibility stage, the easier it will be to scale. Due to this, it makes sense to keep the feature set as small as possible during the flexibility stage by removing unused or otherwise not working features.

There may of course come a day when there is a need for flexibility again, for example when the product is going to enter the mainstream market. The mainstream market usually requires a whole product, which naturally is going to require a lot of effort to build. But then again at this stage, the company has probably generated some revenue and raised more capital and the processes and technical competence are at a much higher level.

The point I am trying to make is that it is extremely important that everyone making product decisions understand what the cost of scalability is. It is so easy to fool yourself that whatever you are building is going to hit the jackpot and build too much scalability into the system. When you learn that it didn’t work, you are going to need to pivot. Either you pivot keeping the scalability but with high cost or you drop the scalability. Jumping back and forth in the triangle is going to be costly and is probably going to result in a lot of technical debt.

I would be very glad to hear what different successful and/or unsuccessful startups have done regarding flexibility and scalability at the early stages of a company. Any experiences?

Most of the books presenting great frameworks for analyzing different things, will not tell you how to obtain the input needed for these frameworks. Bad input leads automatically to bad output, which means that these frameworks are completely useless unless you have all the data. Bigger companies may already have a lot of market data and can somewhat easily get more, since they probably already have a good understanding of the market. Startups don’t have. Many books let you believe that you either need to know all this in advance or if you are lucky they present a way to do market research in some classical way that only a big company can afford to do well.

I came across 3 books that managed to put everything in its right place for me. These books helped me to understand what is really needed in a startup and when to focus on it.

1. The Four Steps to the Epiphany: Successful Strategies for Products that Win, by Steve Blank

I found Steve Blank’s blog a couple of years ago from a TechCrunch article about the long lost formula of startup success. After reading some blog posts about the Customer Development model I realized that this is exactly the missing piece to the puzzle, so I bough the book. It’s a step-by-step guide to build a software company. It tackles the core problem of how to find which customer problem to solve and how, using an iterative process called Customer Development. All the other business books that I had previously read had made me think that good entrepreneurs know from the beginning which problem to solve. Also various books about usability, focusing on finding the solution to a predefined problem by doing interviews, usability tests and various other activities with the customers had as well put me off the track. They made me blind to understand that the real point is not to directly find the solution to the customer problem but instead to find a problem that is worth to solve; a problem around which it is possible to build a profitable and scalable business.

Order you copy here!

2. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers, by Geoffrey A. Moore

Crossing the Chasm has been said to be the bible of entrepreneurial marketing. It discusses the technology adoption life cycle and the so called chasm, which lies between early adopters of a product and the early majority. It is known to be very hard to get a technology product from visionary customers into the mainstream market. This book is most certainly a good read for anyone who is going to get their software product out in the mainstream. One way to look at it, is that Steve Blank’s book is the one helping you to get to the chasm and this book helps you cross it. But I think there is much more to it than that.

For me the book additionally helped me put all the different activities I previously had learned from other books into the right stages in the technology adoption life cycle. I had read from various other books several statements, such as “You must create a strong brand for your company”, “You need to prove that you are the market leader”, “There must be something new that gives a competitive advantage to the first customers”, etc. All these statements are true, but at different stages in the technology adoption life cycle. This book helped me understand that. Also understanding the behaviour of customers from different stages helps a startup understand which customers to focus on and which to leave for later. In my previous company, with PiX’n’PaLs StoreFront, I wasted an enormous amount of time trying to sell to late majority or laggards.

Order your copy here!

3. The Lean Startup, by Eric Ries

Although I had been reading Eric Ries blog before the book and was already quite familiar with many of the ideas in The Lean Startup book, I found it to be very useful in helping me understand how to validate business hypotheses with an agile software development process; it is actually possible to take it so far that all the “stories” that developers build are considered tests. Instead of an engineer getting a job to implement a feature, he would get a job to find out whether a feature helps the company in its goal. This goal may be to grow virally, convert users to paying customers or something else. Running a process like this will get a product built with only features that are needed and the chances of reaching product-market fit are higher. I think it contained many of the missing pieces to the puzzle regarding how to actually run the tests and what to measure and what not.

Order your copy** here!**

Nowadays, most of these theories in these three startup books may be more known in the startup community than they were when I was an entrepreneur. Still, if you have heard pieces of advice from different people here and there, you may have a poor understanding of the big picture. Thus, I recommend that anyone who intends to start a software company the first time reads these books.

I recently had a conversation with a friend, who also has a programming background but has moved more into a managerial position like me. We talked about when programming is fun and when it is not. We have both had moments when there is nothing else in the world but the one thing you are working on 24/7. You have so much adrenaline in your blood that you couldn’t sleep if you wanted to, so you just keep on hacking the whole night. These are the peaks that make software development the most interesting profession in the world. This of course requires the right circumstances.

I think it all comes down to how much “magic” there is in the stuff that you implement. It may be something really Hi-Tech to you, that you perceived as magic at some point in your life. Or it may also be something really simple but has the potential to spread virally to millions of users. However, there must be some magic in it to be able to unlock that kind of a productivity boost. My biggest moment of magic was when I built my first chess engine in 2002.

From the day I played chess against a computer the first time, long before I took up chess for real, I had been wondering how it is possible that the computer can think. When I got a little bit older I understood that it has to search through the moves tree and check what results in the best position. But still, without proper understanding of algorithms and data structures, it felt to me like some kind of magic.

Before directly going to the story, I’ll give a quick background to how I got into chess and writing a chess engine. I have always been a fan of strategy games, ever since I got my first computer and played Civilization 1, Sim City and later C&C and similar games. However, as much as I would have wanted to become very good at any of them, I knew that the knowledge would become obsolete one day when a newer game was released. That put my view of chess into a completely different perspective, since that game is going to stay unchanged forever.

My cousin had taught me to play chess since I was small, but I never really enjoyed it at that age. But when I was studying for the first year in high school, surprisingly chess became very cool. We were about 15-16 years old. People were playing during the breaks and even girls played or watched. I am not talking about nerds and geeks. This was an all-embracing phenomenon. I immediately felt that this is my game and I must be best at it. I started playing a lot. I read a few chess books, joined a local club and after a while I played in tournaments.

When I took a beginners course in Java programming at TKK in spring 2002, the course had a bigger project assignment at the end with several different topics. One topic was to build a chess game, but it was without possibility to play against the computer. I couldn’t let the opportunity pass, so I just had to choose that assignment and also go for the artificial intelligence as extra. Students were allowed to do changes to the scope if they were reasonable.

This was a very interesting project. I still remember well the moment when I got to try the AI functionality for the first time. I had already implemented all the functionality necessary to make a list of all the legal moves in a position and to make moves on the board. There was only textual representation of the board at this time, but that was all that was needed. I was at a computer class in TKK, where I used to work to be able to concentrate. It was 5 am already and I had fully lost my sense of time.

I used the negamax algorithm, one of the simplest forms of search. I had implemented with a very simple static position evaluation function, only counting the score of the pieces at the board. When the first bugs had been fixed so that it did not crash immediately, it actually played. It was able to search to a certain depth and suggest a move that proved that it had some kind of intelligence. It was able to think. I immediately jumped up and said to myself: “It’s alive, it’s alive!”. Too bad there was nobody else listening.

These kinds of peeks came every now and then when I was improving the AI. Adding alpha-beta search and other improvements to the algorithm allowed the engine to search deeper and do more complex tactical combinations. Improving the evaluation function to take into account positional advantages, such as positions of pieces, king safety and pawn structure made it play a lot more like humans. I still remember the Wow-feeling when I realized it was thinking strategically and it was playing quite coordinated attacks against me.

When the school project was over, I decided to continue the development as a hobby. I rewrote the engine in C, while doing several other improvements as well. I was doing this for a year or so. My engine (Hoplite) implemented the Chess Engine Communication Protocol, so it was able to play against other engines. Hoplite was playing in several tournaments around the world. It was free and open source, so tournament organizers could easily enter it into a tournament.

I had a lot of fun watching how it performed in a tournament after I had done a new release. Also during development I had set up my own tournaments, where I had several engines playing against each other. I usually had 2-3 variants of my own engine and then a couple of other engines for reference. Tournaments were automatically played with a script, so I could have it running during the night and check the results later. If a new feature showed good results, I added it to the mainline. I almost took this process so far that I would have used evolutionary algorithms to get optimal configurations. This would have been overkill, since the biggest improvements would have come from completely different optimizations.

The last time I touched Hoplite was probably in 2005. There came other more important things and at those days I had already realized that making it play really well would require rewriting some parts and a lot of time, which I unfortunately did not have. Maybe one day I’ll give it a shot again.

These are the peaks that make programming so damn interesting. You need to implement stuff that has magic in it. Every time you do that, you raise the bar and it gets harder to find any problem with magic again. During the last 10 years I have been raising my bar all the time and nowadays it is getting very hard to find something that I could implement with as much magic in it for me as the chess engine once had.

This raises an interesting question: What can a software company do to let all developers experience these kind of moments? Should a company give a lot more freedom to developers to work on things they like even though they are not 1st priority? It’s always a tradeoff and it depends on what kind of software you are building. If there is development of complex algorithms or growth hacking involved, it may make sense to let a team operate outside the usual process. Product management can define the boundaries within which the team can make decisions themselves and then give green light to do whatever they want within those boundaries.

For those interested, I created a simple page for Hoplite, from which the source code or Windows binary can be downloaded. The original Hoplite page was removed from TKKs servers when I graduated. Follow this link: Hoplite Chess Engine

The usual process to create a viral app used to be to start with a quiet launch to be able to optimize the viral loop and doing a full launch when reaching something above 1. I think optimizing the viral loop this way is still a must. But it is very hard to emulate real conditions. There are many variables that will have an impact. Some can be emulated, others are harder. For example, the conversion ratio of invitations to signups will most certainly be affected by how well known the brand is. If a user gets an invitation to a well known app like Angry Birds, the user will of course be more likely to sign up and try it out, than any previously unknown app.

My hypothesis is that there are many situations, where a virality coefficient of less than one during tests will be sufficient in the real world. The reason is that it may be possible to improve it with some big PR event, where you influence the masses before they get reached by the virally spreading invitations. I look at this like in war, where you first fire with the artillery (PR) and then send in the infantry (invitations). Also in many cases there may be economic externalities, and reaching a critical mass will also have an impact on the virality coefficient. Therefore, the actual post-launch viral coefficient will be above one, which is all that matters.

Even though the ecosystem of web apps is unlikely a “zero sum game”, someone’s gain in virality is often away from someone else’s. This happens when everyone is optimizing ther virality in every possible way. Apps are fighting for eyeballs everywhere in feeds, emails, etc. The more there are players using the right methods, the harder it will be to reach a coefficient above 1. Therefore, one could assume that some apps would have to do a big PR launch just to get over the edge. I would be glad to hear what others think and what the new startups that recently launched a successful viral app did.

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.

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…

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…