The Disruption Theory Applied to Web Apps

I was fortunate enough to get to talk at Future of Web Apps + Future of Web Design double conference in Prague. First, I would like to thank to Future Insights (previously Carsonified) and personally to Cat Clark for the trust in me to give me the speakers wild card.

Bellow are my slides and complete text of my 30 minutes speech. I spoke from memory so I have probably digressed on a few places. Also, please, forgive any typos or grammatical errors I’m basically posting my notes and I had no time to do thorough proofreading.

Here you go, enjoy.

It is said that the best start of a presentation is “Let me tell you a story.” Well, let me tell you three stories. They may seem to have no bearing on web application industry at the beginning but I promise, I will tie it together. It will all be about business strategy.

Story of the steel mills

(Slide 2 – Steel Mill)

Where to better start a talk for the Future of Web Apps conference than in the 1970′. In the steel industry. Right?

What you see here is classical blast furnace. Coal and iron ore comes in on one end and molten steel comes out on the other.

(Slide 3 – Mini-mill)

In the early 70′ there was a revolution in steel production. You see, clever heads come up with technology of electric arc furnace. Instead of fighting with the raw iron ore these so called mini-mills used scrap steel as their input and molted it with electric arcs. This new technology allowed them to produce steel at 20 % lower cost than traditional steel mill.

There was a catch. These mini-mills could only produce the steel of the lowest quality – rebar – you know, the iron rods used in constructing buildings, pour them over with concrete. That stuff. But, in the rebar market, the mini-mills had 20 % cost advantage on the classical blast furnace mills.

Markets working as markets do, mini-mills started to push the big mills out of the rebar. The managers of the big mills stood in front of this conundrum: Should we fight for the low-end of our market, where the margins are lowest or should we invest the money into the higher portions of the market where we have more money to make and the mini-mills can’t follow because, you know, they can only produce rebar. Yes, they chose to flee the rebar and let it the mini-mills to fight out.

Well, what happened then was a bit of a let down for the mini-mills. As they successfully drove out the last the big mill, they found themselves competing against other mini-mills. What that meant was that their margins fell down as they lost the advantage of lower cost. All their competition were mini-mills with the same cost structure.

You can almost see the managers of big mills laughing, can’t you? Ah, but how that laugh stuck in their throats.

For mini-mills the situation was clear. If only we could somehow produce better steel than rebar, we could move up market to the broad, sunlit uplands of angle iron with 12 % gross margins. Necessity being the mother of invention, that’s precisely what they did.

And the situation repeats. Big mills managers stand before the question to defend angle iron market where they make their lowest margin or use the money to invest in higher margin production where the mini-mills can’t follow.

(Slide 4 – Chart)

Well you see in this chart what happened next. The circle of innovation, driving out the old competition, falling margins and innovating out of the hole repeated itself a few times during some 25 years and at the end one of the biggest producer of steel is Nucor which started as mini-mill.

What I want you to take from this first story is this: When setting out to build your web app, position yourself so, that the existing players are encouraged to flee from you, because you make them defend the undefendable from their point of view. And second thing, it’s good to grow from the low-end. You will get to know the market much better and you will not allow much space for the competition to undercut you.

Now, to our second story.

Story of the iOS gaming – story of new market disruption

(Slide 5 – Nintendo DS + Sony PSP)

I guess most of you are part of this story in a way. I want to look at the producers of handheld gaming hardware at the start of the 2007. There were two main producers: Sony with PSP (or Play Station Portable) and Nintendo with its DS (for Dual Screen).

Then this thing happened.

(Slide 6 – Say hello to iPhone)

The first iPhone went on sale in June 29, 2007. It took some persuasion but Steve Jobs eventually allow developers to write apps for the iPhone and other iOS devices. From the beginning, games were the most purchased type of app.

From the point of view of Sony and Nintendo the iPhone was just another phone. They were thriving for years even with games on phone existing. But the games on the phones before iPhone were a joke in comparison. Their customers were people who were, let’s say, more of the “hardcore” gamers category. Sony and Nintendo were not seeing the iPhone as they competition. We are making a gaming handheld Apple is making phone, they thought.

What a mistake! But a lot of companies made this mistake. iPhone is in fact a handheld computer that also acts as phone, as camera, as music player as anything that could be digitized. Don’t forget that.

With each sold iPhone, iPod Touch and later iPad, the addressable market for iOS game developers grew. Latest number we have is, that there are 435 mil. iOS accounts with credit card and one-click purchase and is adding 12 mil. each month. For perspective PSP and DS combined are selling half that IN A YEAR.

(Slide 7 – Angry Birds)

The culmination of all this is the success of Angry Birds. They’ve had over billion downloads and that tells us a few things.

Casual gamers market is much, much bigger, than the hardcore gamers. Casual gamers were not willing to pay for specialized device to play on and than pay $20, $40 for a game, but they are willing to buy $5 games and there is a lot of them. And this sets into motion a dynamics that encourages game developers to focus on this new market and they are making progressively better games and the hardware is getting better so we may say that the iOS is eating the addressable market for PSP and DS.

What have we seen in this second story? We have seen that it is great when you are not seen as a competition at all. iOS as a gaming platform was in the beginning interesting for different sort of customers – non-consumers from the point of view of Sony and Nintendo – that is they did not buy their handhelds anyway. But very quickly the situation is changing and iOS and Android gaming is eating more and more of the market of PSP and DS. With the integration of iOS with TV I would be very scared if I were not just handheld HW producer, but even a game console (Xbox, PlayStation) producer.
That’s new market disruption – approach non-consumers and grew from there. By the time your competition realizes you as threat, it may be already too late for them.

Now, let me tie this two stories in a third one. The story of how we build our invoicing web app Fakturoid.

Story of Fakturoid

(Slide 8 – Fakturoid with building kit)

The robot, that’s Fakturoid, he is sort of a personification of the app. Just to explain the name: The Czech word for invoice is “faktura” hence “Fakturoid” could be roughly translated as “Invoicedroid”. Anyway…

(Slide 9 – Lukáš)

Me and Lukas started working on the app during Christmas holidays of 2008. Our vision was for a simple invoicing web app targeted on people like we were. We each had our web client business and besides that Lukas was (in fact still is) a student at a university. So our target market was single-person businesses or small companies.

From our own experience we knew that we didn’t want to use “the real” accounting software as it was far too complex for what we needed and we each ended up building our own clunky invoicing “systems”. Also we had friends and we knew they have the same problem but ended up with some Excel or Word templates.

So the business plan was really simple: We each want better invoicing, we will build simple app and then we try to find people willing to pay something like $8 a month for limited account and $16 for unlimited one. Even if we don’t get any customers, which seemed unlikely, we will have better invoicing for ourselves and last but not least, we will learn a lot along the way and find out how we work together.

We’ve read our Getting Real and all the 37signals well, so we knew we want to start with some core set of functionality and grew from there. John Gruber has put it best.

(Slide 10 – Gruber quote)

But, of course, the question is: What the fuck is the minimum? Think about it for a bit… Invoicing web app for single-person businesses and small companies… What it needs?… OK, I will tell you what we thought was necessary and why. I will tell you how it went and I will then tell you what I would have done differently if I knew then what I know now.

(Slide 11 – The Minimum)

Here is what we thought necessary:

  • Outgoing invoices
  • Incoming invoices so we could do cash flow etc.
  • Clients – hold their invoice info etc.
  • Statistics – monthly, quarterly, comparisons etc.
  • Recurring invoices – because we wanted the app to be able to handle the automatic invoicing of its clients.
  • Support Value Added Tax (VAT)
  • Support proformas

What do you think? What would you have sacrificed in the search of the minimum? We ended up sacrificing ingoing invoices, as we really wanted to catch the beginning of the new year because that’s a good time for people to start using new invoicing tool as it is also start of new accounting year. We managed to launch at Christmas 2009.

So, it’s been almost 3 years. How it’s been?

(Slide 12, 13 – UI screenshots)

We were new market disruption in relation to accounting software. We provided core set of functionality desired by businesses and we provided it in a more convenient way. Against some of the software we are even low-end disruption because we are able to charge smaller fees. The low-end disruption was the smaller part of it but it may become larger as more customers paying monthly allow us to charge less in exchange for another piece of market. Our margins are really good.

We are still NOT fighting for someone else’s customers, we are fighting for non-consumers, people who pay nothing now, but solve the problem of invoicing ineffectively. We are able to provide them a service that saves them time, makes invoicing convenient and provides valuable information. That’s worth something.

But of course it’s not that easy. I can tell you once you launch your app, better be prepared to run quickly. The knowledge of disruption theory makes entering the market easier putting you in the right place at the right time, but once you get on the radar of competition you better be able to exploit that opportunity.

You see, Czech Republic is small so people know each other and is easier to get noticed. We got noticed big way, when we won special prize at one quite well known IT awards in 2010. We were very happy at the time and it had definitely brought some customers, but in the hind sight I see that it was exposure before the wrong crowd as competition started to grow like mushrooms.

Right now we have something like 5 direct competitors some of them are completely free. Even so we manage to double the revenue in the 2012 so things are going reasonably well.

What would I have done differently? The minimum. What’s the minimum for an invoicing app? An invoice. Give me just one form and the result of it will be the invoice. I will just remember your business info and nothing else. But you will pay like $2 a month for it. And we will go for scale. And step by step we will add functionality as the revenues rises and our initial idea is validated.

We would have been faster to market, with lower costs and I believe we would have grown quickly.

Now to sum up the lessons and look at the future.

So, what web app should I build?

(Slide 14 – Apple 1)

Scratch your own itch. This is the recommended approach to finding the problem your app should solve. The reasoning is obvious and you’ve heard it: “well, we want to solve this problem and there is either no software for us to do it with or it’s shitty. Hey, we are doing this web client work, we can do it in HTML. Let’s build our own. Hack, we can even sell it.”

Scratch your own itch is the low hanging fruit. It’s nice if you can get to it but that window of opportunity is closing pretty fast I’m afraid. Web app developers recruit from people and companies that used to do or are doing client web work. Just think what sort of common problems do these type of businesses have. Project management, CRM, invoicing, time-tracking. Anything else? All that has been covered pretty well already.

That’s why it will be more and more difficult to get in on the “scratch your own itch” low hanging fruit. You will find entrenched competitors with years of head-start. Or you will have to run quickly as competition emerges seeing what you do and being able to copy you relatively easily. As we saw with Fakturoid.

But there is vast ocean of opportunity in all sort of niches that were not approachable in the old software business model, but will be profitable in the web app + SaaS model.

(Slide 15 – LHC – Research)

Thus, the way forward for our industry is research. We will have to learn how to find promising problems that other business need to solve or as Clay Christensen calls it job-to-be-done. Pick a promising customer segment. Let’s do some job shadowing watch the people doing their work. Is there a pain point we could heal that will allow us address big enough market? If not, back to research.

(Slide 16 – Job shadowing cat ;-))

Let’s look at one big advantage the SaaS model with its monthly fees gives us. Standard software licensing were customers pay for update from version 2 to version 3 makes developers to stuff the new version with more features. They need more features to convince new customers to buy, old to upgrade and to keep away the competition that does the same thing.

It leads to creating a segment of over-served customers who do not have the use for our new functions or worse, the functions make it harder for them to actually use the software. And over-served customers open us to the low-end disruption.

SaaS on the other hand, allows us to focus on making the product better in a given set of functions. If our customers pay us monthly fee and the functions they use are improving, why would they stop using our app? Another upshot of this is that we are building sort of protective walls around our customer segment because anyone trying to steal them would have to provide better solution to their job-to-be-done than we do and that would be progressively harder as we improve the core function set.

We can even let people buy modules if they want them so that if the UI gets more complicated you at least know you wanted it. (But you pay for this with more complicated pricing structure etc.)

(Slide 17 – Last advice)

My final pieces of advice to you:

  1. Read Innovator’s Dilemma and Innovator’s Solution
  2. Learn about customer research
  3. Start looking for pain points in business processes

(Slide 18 – Thanks)

My name is Jan Korbel. If you want to talk more, catch me here at the conference or on Twitter (@jankorbel) and you may find my blog worth a look.