Jorma Ollila: "We were very much looking at the Sales, when we should have looked much further into the future"

This is a comment from ex-CEO, ex-Chairman of the Board Jorma Ollila when he was asked in the interview why Finnish Nokia's mobile handset side lost to the competition, broke down and was later sold to Microsoft with known results.

We who have been on board the company, of course know that many other things influenced also. But one has to agree. Company was very much accustomed being a cash cow, and seemingly difficult to change the mode to cannibalise it's own product portfolio with disruptive technologies or new types of products. Somehow it was easier to make "delta products" - the same except some new improvements like better display or camera. But world does not work that way.

Financial Times article

This gives us an important lesson - stay agile and stay almost paranoid towards competition (like Intel's Andy Grove wrote in his book a long time ago, at least when measured in the internet time)

Digitalization brings new possibilities. Something that was not possible suddenly is.

Artificial Intelligence, or Machine Learning has not advanced, except suddenly now it has, when big data and analytics have provided the data for the "machine to learn".

Big companies are suddenly been disrupted by the new entrants. Banking will never be the same, renting and taxi business have already changed.

How should you approach this? As world has become quite unpredictable, the only way is to experiment yourself out of it.

Use Lean Startup methods to navigate in a pragmatic way to find the best products and business models. This is not some "consultant foam" but actually very pragmatic way forward.

Write assumptions on your products and markets - and test them (today in many places Product marketing/ R&D write their use cases and implement them without much verification)

Start using minimum viable products to test the markets.

Many companies seem not just to have a portfolio of products, but also portfolio of business cases.

"Lets be careful out there"

Jukka Märijärvi,

jukka.marijarvi at landon dot fi

So it has been a while perfecting the next book. It does not sound very much if you haven't ever written a book. But let me assure you that it takes many months from the point in time, when you have all the text and pictures together.

The book is called The cookbook on Successful Internal Startups. It is free, so don't worry.

Stay tuned

The Sunday Guardian has an interesting post about disruptions and innovations. The writer notes that disruption is the word of today - all startups with disruption on their slides get funding. And he argues that is not necessarily good.

The article ends:

Instead, be creative. Make something unique. That way, you can stand up to the geeks and say with total confidence: "disrupt this, motherfuc*er!"

http://www.theguardian.com/commentisfree/2015/sep/29/disruption-everywhere-uber-airbnb-creative

Indeed, there is a lot of potential in each company when the innovation path is just fixed. With fixing I mean that many innovation processes would need revitalization, and become truly a part of the company front-end. a lot of good innovations are in peoples mind - only to get them collected, and acted upon. Over the years I have noticed that a innovation tools often work in the beginning but as the dust settles so does the energy around it and ideas just stay on peoples minds not progressing forward.

However, the is a interesting and well working possibility when one adds active innovation process with internal startup concept.

I argue that companies can renew quicker and raise enthusiasm by this method. And additionally ignite more innovation ideas as people actually see that the system is working and some of the ideas go forward in lean startup fashion.

I will be giving few classes on the topic real soon. Check if this would work for you:

http://www.wakaru.fi/koulutuskalenteri.php?kat=liiketoiminta

 

Jukka

In the last post we examined how to use Lean Startup practices. We assumed a mailbox based banking product, and it looked not to be enough of an innovation to succeed. And that Google's Pony Express has somewhat a similar idea. (It is not public so we do not know exactly).

Additionally we claimed that you might have the wrong approach, if your front-end solely consist of backlogs owned by PO (Product Owner in Agile methodology). So even if you fulfill agile methodologies by using a PO and backlog, you might have missed it.

Let's go forward in our thinking and examine these further.

Our textbooks have taught us that the road to success is to fulfill customers either known (or at the time un-known, latent) needs with our product. But who is my customer?

Lack of customer focus is offered as a reason for Nokia (mobile) downfall in many articles written on the topic. But one could argue that Nokia did focus on customers. And it did. It had hundreds if not few thousands of operator requirements fullfilled in Symbian SW. Remember at that time the phone business was such that in order to get into subsidized operator sales channel the operator technical team was the gatekeeper. You fulfill our reqs, and you get into the sales channel.

Right, but the requirements were the operator technical team's small changes to Nokia's requirement set, not the holistic user experience that the end user wants. What Apple did was not to mind any of those and they by-passed the operator channel completely. Because the opinion of the operators was not seen important. Looking the results one might argue that Apple selected customer that was "more right".

So how should I approach this?

Let's remember here the Geoffrey Moore's technology adaptation life-cycle (you can google it) defines the user segments as: 

  • Techies - just try it
  • Visionaries - the lead users
  • Pragmatics - follow the herd
  • Conservatives - use only proven things
  • Skeptics - no I do not believe in it

You can keep these as your default user classes. You and your PO should use them as to understand your customer and what would be your targets. Now often the technology apps and innovations are directed to techies, but be aware that if you have difficulties in expanding your user base, you might target the wrong segment and needs.

Let's come back to this email based banking example. It is perfect for Google, they like owning your mailbox. It adds stickiness into their email and extends it to new business areas. But you should think it other way around. How to find a banking solution for the visionaries and pragmatics, which you want to target as they are a large potential user base. Everyone in that segment has a smartphone, or at least a camera in the phone. So you should test a banking app where you take few pictures on the bill you should pay, and the app has magic image processing technology which combines the pictures in a one clear shot, and sends that into the bank to be paid. Could be useful?

Is that a killer app? We do not know. Make a Lean Startup MVP (Minimum Viable Product) to test your idea. MVP is to be used to see if your idea flies. The MVP does not need to work, but it is more for validating our grand idea here above. And if some aspect needs to be changed, you can test it again in a cheap and quick way.

Once you know you customer and have validated you visions with them you are in the clear and can start the more traditional product development cycle.

It is not always obvious - Let's be careful out there!

Jukka

Most of the readers are familiar with Agile methods, and most companies even know how to implement them in practice. (Not all do, but that is another topic and another post). Agile methodologies have improved SW development efficiency as an operation, one can argue. But how to be sure that what one develops delivers the best VALUE? Or that one creates truly innovative products, not just copying features from someone else? In short: how to succeed?

I told in my last post that even if one has a proper agile operation with themes, Epics well basically PO (product owner) and prioritized backlog, one can miss the mark. WHY? You might have the wrong backlog or the wrong product.

Lean startup methodology has a few but important, interesting concepts to add in to your product development front-end. Let's examine them further:

Of course, one should always to have a vision to start with. You have an innovation or an interesting concept you think will be big. You might be right, but how can you tell? Ask the user? But what and how? We do not have any customers yet.

In lean startup methodology one creates a set of assumptions that one tests with a MVP - minimum viable product.

Lets take an example. I have this vision that people could pay their bills straight from their email. The insurance/ gas etc company emails the bills, and they get paid digitally by users. First I create a set of assumptions that I need to test:

1. Banks would like this as less people would visit their physical branch offices and payments would happen remotely. Less money spent on bank walls.

2. People would like this as they would not need to visit the banks in person. Better experience as one needs to queue for a long time to get the turn at the bank desk.

3. Both banks and people would be willing to pay for this.

Now I need to test my assumptions, as we know not all we dream about are actually true. I need to build a MVP or several to test out my assumptions. You might spot that all the assumptions are on a quite high level, and a likely answer to those might be "yes, but it depends". The real product innovation lies in the implementation, and a more concrete test MVP is needed.

Let's assume I build a MVP, a product which is an email extension that fires up by clicking the bill attachment, and then guides me through the login process to the bank etc and lets me pay the bill. 

OK, now I need to get feedback to the concept and assumptions by interviewing people. As this is a fictive example, I do not have the real data.

But I would argue that answers would be:

Yes, this is fine, and the Bank likes this concept, but the innovation here is only that the attachment opens the bank's web service. No more. One can open the bank's current web bank page even without and pay the bill.

Not enough willingness to pay for the service. Users would think that banks would need to offer this kind of service for free or as a part of a service package. No space for startup revenue here.

As a total summary of this innovation it is unlikely that the assumptions would be met. People with a laptop and an email account, is not probably that segment of people that visits the bank offices and builds the long queues by wanting to pay for their bills in person. So even with an innovative implementation the end benefit would not have been fulfilled. So people with email account can use the bank's web service.

NOTE that the strategy of asking the users which features to add, we would be after the wrong segment. (We look this in more detail in the next post). 

So it is time to PIVOT. Pivoting is a lean startup term, and means that one needs to change the course - meaning to change one or several assumptions. 

In the next post we figure what to do next. This spec did not work for us.

- Jukka

ps. Google is working on this kind of banking service - you might want to google Pony Express

ps 2. Note the question 3. Not many innovations and startups have a solid concept for monetization. You should build that in to the set of assumptions. You test, you know.