Psychologists have moved on to a new model, and it’s all about fundamental motives.

Way back in 1943, Abraham Maslow published his “Hierarchy of Needs” – a pyramid describing the forces that motivate us, and the order in which we strive to meet them. For many designers, this 76-year-old model still informs the design decisions we make every day. But did you know that Maslow moved on to an updated model only a few years later? Or that psychologists stopped using Maslow’s pyramid years ago?

In the past few decades, advancements in evolutionary biology have shown that while the pyramid we all know and love was definitely on to something, the model sorely needed an update. Fundamental Motives, a framework developed by Vlad Griskevicius and Douglas Kendrik, is a better reflection of psychologists’ current understanding of what motivates human behavior.

This new model includes 7 “motives” (rather than 5 needs):

Human beings are driven by the motivation to…

...evade physical danger to remain safe. (Self-Protection)\ ...avoid infections to stay healthy. (Disease Avoidance)\ ...form and maintain cooperative alliances. (Affiliation)\ ...gain and maintain prestige and respect. (Status)\ ...acquire a desirable romantic partner. (Mate Acquisition)\ ...foster a long-term mating bond. (Mate Retention)\ ...invest in, and care for, offspring and family. (Kin Care)

Additionally, this new framework does away with the concept that one “need” or “motive” has to be met before the next can be achieved. In fact, this new understanding tells us that our motivations are often in conflict with one another. The order is simply determined by age. An infant starts their life with only the motivation of their immediate physiological needs, but quickly incorporates new motivators into the balance as they develop.

Say you landed a date with someone you met online. The date is tonight, but at the last moment they warn you that they are coming down with something and are not well... but they are willing if you are. Do you go? According to the Hierarchy of Needs, your personal safety would need to be secured before taking the risk of reaching for love and belonging. But according to the Fundamental Motives, these motivations are caught in a headlock. The motivation from childhood to avoid disease is battling it out against the newer, but just as strong, motivation to acquire a mate. Subtle details in context will determine whether you will choose a night out or another at home in front of the TV, not a predefined ranking.

So when it comes to our motivations, think of seven motives in conflict with one another rather than a hierarchy of five needs. And the next time you look to psychology to back up your design decisions, make sure you pull out the latest and greatest that the psychologist today use. 😉

Oh... So you’re still using Maslow’s Hierarchy of Needs? Awkward...

Dette er del 1 av 6 kaffeprater om Smidig organisering. Vi er innom ekte kundeorientering, raske læringssykluser, og stiller spørsmålet om hvorfor ingen har laget en vaskemaskinstol enda. Altså en kombinasjon av en vaskemaskin og stol.

Smidig organisering, del 1: Kundeorientering og hvorfor har ingen laget en vaskemaskinstol?

When using open source code you might encounter bugs in this code. Since it's open source, you can find the faulty code and the fix it yourself. The right thing to do next is of course to submit an issue and/or a pull request on the project. But what if the project maintainers don't answer you, the project is deprecated or if the fix is planned, but not due for quite a while? In this article I’ll teach you the strategy of patching dependencies in node_modules by using patch files.

A patch file represents a change to a file and looks like a git diff. Patch files can be kept in source control, and the application of them can be automated in a postinstall script such as npm postinstall. The advantages of this is that you can persist some small changes to your dependencies without all the work of forking the repo, or waiting for the maintainers to release a new version. But use this strategy sparingly, though! If the dependency gets an update, the patch might not work anymore and you might have to update it. Consider it a temporary workaround.

Creating a patch file

So, you’ve encountered a bug in your app. After some investigation you’ve found that the bug is located in the code of the npm package buggybug, which your app is strongly dependent on. By editing the relevant file in the node_modules/buggybug directory, you fix the evil line of code. Great! But since node_modules is included in your .gitignore file, how do you let your teammates enjoy your fix as well? You decide to create a patch file.

Create a patches directory in the root of your repo:

Copy the fixed file into your patches directory

Now we want our node_modules to be "clean" again, so why not run a good old

After that’s done, let’s create the patch file:

This will create a file called buggybug-index.patch that contains the diff of our change. To apply it to the actual buggybug in node_modules, we use

If you inspect your node_modules after running this, you should see that buggybug/index.js is updated with your fixed version.

Now it's safe to delete your fixed copy. We only needed it to generate the patch file.

Applying it on postinstall

In order to automate the application of the patch, we'll add it to the postinstall script in package.json:

Since the postinstall script is run automatically after npm install, all your teammates need to do after a git pull is to run npm install, and your fix is applied. :tada: Test it yourself with rm -rf node_modules && npm install.

And hey! Remember to submit that issue and/or pull request to the dependency's repo!

Patching your node_modules

Tomorrow the festivities, that are KotlinConf 2019, are upon us. And in that spirit we take time to look back at last years conference and some of the informative, inspiring and fun talks we witnessed in Amsterdam.

KotlinConf 2018 was held over two days (not including workshops) in Beurs van Berlage in central Amsterdam. After the keynote kicked off the conference, there were four talks in parallel trough-out. This presented a problem, as it was not easy to choose which talks to attend (or even more so, write about). Even still, we will try to present some of the talks here.

Representing the State

Representing the state of a program in the code can be difficult work, and is a discipline prone to errors. In this talk Christina Lee presented how the use of primitives and strings can be problematic when used to represent state. Both because their meaning may change over time and because they quickly (or even initially) will have the ability to represent invalid states when code changes.

So what is the solution? As always, that depends on the application. But Christina recommends using bounded types, and in Kotlin that means Sealed classes everywhere!

Representing State: the Kotlin Edition by Christina Lee

Making Noise

Do you like Kotlin, music, or at least abstract sounds, and electronics then look no further. Josh showed us a very fun use case for the Kotlin/Native technology. A synthesiser aquarium! He explained how he had used C-libraries in Kotlin/Native to make a small music/ascii art program, and explained how he was able to compile Kotlin/Native to a Raspberry PI. Amazing stuff!

Making Noise with Kotlin Native by Josh Skeen

Best Practises for Unit Testing

During any conference, some talks are fun, some are inspiring and some are downright useful. While this talk may fall into the two first categories, it definitely belongs in the third one. Especially if you are a developer migrating to Kotlin from the Java-world.

Phillipp Hauer gave many useful tips on how to use the features of Kotlin when writing tests. This included how one can avoid using statics, using the strengths of data classes and how well Kotlin works with JUnit 5. He also presented some of the many different libraries for testing, assertions and mocking.

Best Practices for Unit Testing in Kotlin by Philipp Hauer

The related blog post is also a recommended read.

Kotlin Puzzlers

A tradition in the making? This was the second edition of the Kotlin Puzzlers, and the schedule confirms that there will be a third edition this year. Anton Keks presented absurd snippets of code and challenged the audience to vote for the correct result when running the code. After the answer was reviled, an audience member volunteered to explain the result.

This was the first puzzler, can you explain what answer it will give and why? There may be some Estonian liqueur in it for you if you do...

For more puzzlers: Kotlin Puzzlers, vol 2 by Anton Keks

... and so much more!

If your are interested in more, you can find videos (and some slides) from KotlinConf 2018 here. And there will of course be more Kotlin in Copenhagen the next couple of days. We hope to see you there!

Happy KotlinConf!

'Twas the night before KotlinConf

Every object in Java has a toString() method which can be called to get a String-representation of any object at hand. If left unoverridden, it only yields a description of its class and hash code, and not really useful for much.

You probably have many classes representing something that needs to be encoded as a String, say for persisting, for API requests, transfering state to other non-related classes, or else. Examples coming to mind are national identity numbers, telephone numbers, countries, cities, anything. It may be tempting to override the toString() method of your Country class to simply yield the name of the country. It seems like the method is already in place for just this kind of use. This conveniently enables instances of Country to be give meaningful information in concatenating log strings, and for any parts of our application requiring the name of the country as a plain String we can just call toString().

Using the output from toString() for anything behaviour related comes with a risk of silently breaking the behaviour, since all objects in Java has this method. If you call toString() anywhere to get the name of a country, there is nothing in the type system enforcing that it is in fact a country you are getting the name of.

One of the most obvious culprits is to change the signature of a method previously set to return a Country to instead return an Optional<Country>, and then change any code which now fails to compile to properly treat the returned instance as optional. But the code which converts the Country to a String will still work. If you used the returned Country to construct an API request including the name of the country, this will now produce strange countries named as “Optional[“Norway”]” or even “Optional.empty”, and the compiler happily accepts this. What should have been used was an appropriately named method, specific for the Country type, e.g. getName(), or anything more semantically useful if required.

The only appropriate use for toString() is really for human readable descriptions, and primarily technical personel responsible for the operations of the application. The obvious use case is logging, or any other text where the content is not meant to be parsed or handled in an automated fashion.

Never produce a String used for anything behavioral or business relevant data by overriding and then calling toString() or implicitly by concatenating any non-String value with a String.

Never use toString() for behaviour

It’s been six months since I’ve been introduced to CSS Grid and I just can't stop sharing how useful it is! It’s amazing when you’re in the need of a responsive layout!

So what is CSS Grid all about? Unlike Flexbox which was made for placing items in a single row or column, Grid can be called a 2-dimensional layout system that lets you place items across a number of rows and columns! Well, it sounds interesting enough! But how do you use it?

How to Grid

Grid is used like Flexbox by setting the container with display: grid. Then you got to define how many rows and columns you want your grid to have with grid-template-columns and grid-template-rows. For instance:

In this example, I have used 1fr (which stands for fraction) - to split the total space in the grid into three columns. This can also be written in a simpler way, by using repeat(3, 1fr) - which basically means repeat this column or row three times with the size of 1 fraction each.

After defining your columns and rows, you can decide whether to position your items by using grid lines or grid tracks. The numbers in the image below defines the grid lines for columns and rows, while tracks is the any group of cells.

With grid-lines, you place each item by defining from which column/row line to which column/row line you want your item stretch. For instance, if I want my .header item to stretch from the first grid line to the last grid line I could use: grid-column-start: 1 and grid-column-end: 4. However, I can also use a shorthand like grid-column: 1/4 . So instead of two codelines, you could use just one! Check out the example below:

To use grid tracks, you first have to define your grid-template-areas by naming each cell. Then tell your grid item which cell(s) it should cover with just one line, grid-area: header. I prefer this method as it is less code and easier to remember the cell names rather than the grid lines 😊.

If the placement of your grid items is not defined then all direct children of the container will automatically be placed inside of each cell in the grid. Simple, right? ✨

What is good about Grid?

Grid really shines when it comes to dividing your web page into different parts without letting your markup suffer! Imagine going from having a layout with loads of nested flexboxes:

To this simple pure grid markup:

Not only does a pure flexbox layout require nested divs, but it also require more CSS to get padding or margin between each flex item to add spacing between your items. With Grid you can simply use grid-gap. 💁

Of course, Grid is not here to replace Flexbox, but rather allow you to write concise and more semantically correct code! So instead of drowning in infinite nested flex boxer, how about you start using a combination of both Grid and Flexbox? You will definitiely reap of the results! ☺️ ✨



Oops! I Grid it again

This November, GitHub Actions moved to General Availability making another mark of GitHubs push towards eating more of the CI/CD ecosystem.

In this article I'll show you how you can start testing your code directly in GitHub.

First off, let's talk a little bit about what GitHub Actions actually is! GitHub describes it like this:

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want

Pretty sweet, right? The things that I'm usually using it for is build and deploy, and today we're going to focus on how to start testing your app with GitHub Actions.

First off, we need an app. The app we're looking at today is a basic Hello World Java app, that we're building with Gradle.

You can follow along with the code in this repo.

Take action

To get your app tested with GitHub Actions is actually quite simple. You need to place a YAML-file in the .github/workflows directory in your app, and then push your code and GitHub will run your workflow automatically on your event of choice. For our example, we will trigger the workflow on the push event.

For our example app, there is only a few steps that need to be run.

First we must tell GitHub Actions to check out our source code, then we must set up Java, and finally we can run our tests with Gradle. Luckily GitHub provides us with some helpful tools, and the runners contain a healthy list of pre-installed software.

That's actually all that is to it!

When you now push code to your repo, you can track the status of your workflow under the "Actions" tab. You'll also get the results directly in a related Pull Request, and even your commits will contain the status of the workflow. Pretty awesome, right?

What's in it for me?

So you might ask yourself why you should care about GitHub Actions? I find that the most useful thing about it is to gather all of your building, testing and deployment within the same tool. GitHub Actions doesn't provide the polished user experience and speedy builds that for instance CircleCI can give you, but in return it is tightly integrated with the different events that is triggered when you push, deploy, open issues, close pull requests, etc.

All in all, I think that GitHub Actions is a promising addition to the GitHub product suite, that will challenge the competitors in the CI/CD landscape in the years to come.

Getting started with GitHub Actions

Okey, so you want to secure your app with a CSP-policy. Great! But where to start and what to do if some parts of your app is out of your control?

Start your CSP-policy with a default-src 'none' and see what breaks. Then add the different sections one by one to make your application work again. Adding i.e. script-src 'self' instead of having the default-src 'self' makes you conscious about what resources your application are actually using and if they are really needed. Oh, so you rely on some JavaScript snippets here and there? But do you really know that they are doing? What about moving that Google Analytics tracking snippet into a separate JS-file and actually initiate the tracking yourself!

I know, in many real world scenarios it is easier said than done to actually have a really strict CSP-policy. But it is not impossible! Sometimes we are forced to allow for some inline CSS and maybe inline JavaScript because of frameworks or platforms that are out of our reach or control. One example is if you rely on a CMS or other platform with a user interface. The publishing platform may rely on inline JavaScript to provide a certain interface for the editors. One solution to this scenario is to have different CSP-policies based on different parts of the solution. You can have a strict policy for all public clients (external users), but allow for some special rules if you are a logged in editor for example. Let not this be an excuse though! If you have a more relaxed policy on some parts you should have other measures to ensure that the risks of this being exploited will be as small as possible.

Also be aware that it is not possible to allow for 'unsafe-inline' for a specific external resource only. If you allow 'unsafe-inline' it actually covers all resources that are allowed for that specific part of the CSP. You have to ask yourself, do I really need this piece of code or this plugin that forces me to open up my app to be more vulnerable to attacks? My experience is that if you as a developer try to adhere to a strict policy (not using inline JS for example) it will make you think more about your code and make it more secure.

Happy CSP!

CSP - done right

Do you wake up at night fearing your app's dependencies might have scary vulnerabilities?

Should you be scared? For sure. I know lots of people who would love to hack my app. Sure, we've taken care to secure our site from the risks described in the OWASP Top Ten Project. But I'm still kind of worried about the integrity of the 1113634 (:scream:) packages our frontend app depends upon.

Each time I see the number of transitive dependencies in our app I get a little chill down my spine. Mostly because I don't really know how those packages are maintained. Who controls them? Are they maintained actively? NPMs package registry is centralized and privately controlled, which is not without its controversies. If you're interested in more about this, C J Silverio gave a talk about the economics of open source at this year's JSConfEU.

Luckily there are small steps we can take to at least be able to sleep at night! One of them is using npm audit.

What's that?

npm audit is a CLI command for NPM which scans your project for vulnerabilities and warns you if it finds something you should look into. If everything looks okay, you should get something like this:

Whew! :sweat_smile:

Well, what if it doesn't look okay?

If the vulnerability scan finds something dodgy, it will tell you what, where, and how to fix it:

The script has found a vulnerability in a package which is imported at a depth level of 7, which means that it is a dependency of a dependency of a dependency of a dependency of a dependency of a dependency of a dependency of our app :eyes:. To fix it manually we can run npm update and tell it the name of the package as well as the tree depth at which the package is found. To fix the vulnerability automagically, run npm audit fix.

Sometimes the warning makes you realize you have a dependency you don't actually need. We've definitely pruned a few unnecessary dependencies from our app this way that we weren't completely aware of having :grimacing:

What if it really doesn't look okay?

If your codebase hasn't been audited for a while you might be met by something that looks more like this:

Yeah. Not as nice. Most times these vulnerabilities are fixed in the next patch of the packages, but if it's been a while you might have to bump a minor or even major version. Your mileage may vary - and I would recommend that you run the audit script often, to avoid having to bump major versions of several packages at the same time. You might also be lucky and find that 130 of these vulnerabilities point to the same package and are solved by the same patch bump.

What more can it do?

There's more! You can make the script output JSON if you want to:

Or you could decide a threshold for the vulnerability level you want to be warned about:

There's a --parseable option as well, which is handy if you want to pipe the output along to another script.

Add auditing to your workflow :eyes:

If the audit finishes and has found vulnerable packages, the script will fail and exit. That's really neat, because it means that we can add npm audit to our app verification script, along with tests and linting. That way, we are forced to give attention to the warnings each time we want to make changes to our app. We've had this as part of our workflow for the past year and it does help us sleep at night. I hope you find it helpful too! :raised_hands:

Photo by Annie Spratt on Unsplash

Audit your app

TL;DR

I'm a sucker for math (not necessarily good at it, I just like it) and really dislike null pointer exceptions. If you can relate, then functional programming is probably something you will like too. Now I've (almost) replicated minesweeper in Elm, and I thought I'd write a little bit about it.

Background

Before I started working at Bekk I hadn't heard about functional programming. Mostly by coincidence I joined that group, and started practicing Elm. It was a struggle in the beginning. Actually for quite some time. After I had practiced for a while and maybe gotten past the noob level, I decided that I wanted to try and write the classic Minesweeper game in Elm. And I wanted to do so without getting any hints. Like following a tutorial of some sort. The idea was that if I did it that way, then through struggle I would have as steep a learning curve as I could get...hopefully.

I guess I believe that this is an efficient way to practice and learn new things, and thought I would try to persuade some of the readers to try something similar. Hopefully something that involves functional programming :)

The result

Here's what it looks like at the moment: 

There's still some stuff and features missing. And it's not exactly clean code. Far from it I'm afraid. But the point was to learn, fast, so I hope I'm excused ^^. The entire design is manually written in SVG. That part I'm pretty happy about.

If you want you can play it and check out/ help with the code

The biggest challenge

I thought that I would pick one part of the code and dig into it (instead of trying to cover too much). This is the part that I found to be most challenging. If you have a black belt in recursion, then this will most likely be an easy task for you. I was more of a white belt, maybe yellow. So it gave me one of those great nerd-rushes when I got it working in the end.

The task:

When I click a square which contains nothing, then all its neighbours should automatically open. And if any of those neighbours also contains nothing, then all their neighbours should automatically open. And so on. I can't just open all empty squares. It has to be only a collection of neighbours.

My solution:

I started out with this sketch:

My model is a matrix, where I use coordinates i and j, and every square has an id.

stepping through the example:

open 3

opening all neighbours

seeing that 9 is also an empty square

opening all neighbours of square 9

seeing that 16 is an empty neighbour of 9

opening all neighbours of square 16

...and so on

putting this into something which can be done recursively



open 3



open all neighbours (2, 4, 8, 9, 10)



save 3 to a list named something like list_of_completed_squares=[3]



save empty neighbours in a list named something like todo_list_of_empty_neighbours=[9], except those that are already in the list_of_completed_squares



case todo_list_of_empty_neighbours is empty ->

case todo_list_of_empty_neighbours is not empty ->

Here's how I wrote that in Elm:

If the list remaining_updated has any members left, then current_square_updated will be an actual Square (not Nothing) and "Just nextSquare" will be the case. Which leads to the stupidly named function goAgain calling itself :)

I take self criticism for bad naming and all messy things you can find. The name of the type 'AlgDat' for example is just a stupid name that I chose, since I didn't want to try and come up with something better. After I got it to work I should have cleaned it up. But.... I still havn't done that.

If could probably be more efficient. But I guess it could turn out to be a lot more inefficient as well, so I guess I'm happy with it at the moment.

At least it was a lot of fun, seriously :D

Some thoughts that I have

React+redux+typescript is great. That's what I mostly use at work. There's a ton of great modules that can so easily be used. It's so famous that it's hard to get the project to use anything else.

But then again, it is so hard not to create bugs! And many of them were/are my fault. I have to admit that. Often they are very hard to find. And it compiles anyway. Almost every time I track down bugs, usually something that caused something to be undefined or null, I dream of a compiler that tells me where it is.

Elm does that.

No forgotten side effects. No any type. No accidental mutations. Just pure functions that make it so much easier to get it to do what I wan't it to do.

And I've just scratched the surface of functional programming. Applicatives, Functors, Monads. Don't know what they are yet. But I bet they are awesome.

Minesweeper in Elm

The American dictionary states that suspense means a feeling of excitement while waiting for something uncertain to happen. So, let’s get excited and learn about React.Suspense and how this helps us wait for something uncertain!

React.Suspense is a component that let you suspend, or delay, the component rendering if the components, or soon data, are imported from outside your loaded code. Later this December we may or may not, learn about Suspense for data fetching, but right now we are diving into how React.Suspense is used today with code splitting.

Code splitting

Code splitting is exactly as it sounds: splitting up your code. This might be on a route-level, meaning that each sub route in your application is its own part or chunk. This is a good place to begin, as it will make your split parts more even. The user experience will also be intact as users are already used to a page transition with a new render.

You can also split up your code at a component-level. You try to identify smaller parts of the application which is rarely used or shown to the user.

Optimize all the codes

As your application gets bigger, with code and features, your loading time will increase as well. Especially if you include multiple third-party libraries. The user today, is expecting fast applications with minimum loading time. Some even say that 53% of mobile users abandons sites that loads longer than 3 seconds. This is where code splitting comes to into play.

When you have divided your application code into chunks, you can reduce the initial loading time of your application dramatically by only loading the chunk necessary for the initial render. When the user navigates in your application the rest of the chunks can be loaded as needed.

Code splitting with Suspense

Code splitting is a feature supported by your bundler, like Webpack or Parcel. However, your code facilitates the actual import and use of these chunks. In React 16.6, Suspense for code splitting was released, and it makes the code splitting really easy.

Suspense handles the loading state and lets you delay the rendering of parts of the application tree. While the chunks are loading suspense shows a fallback component until the chunk is ready to render. This means that you do not have to have a local state checking if a component is loading or not and you do not have to clutter your render function with an if-statement checking this state. Suspense deals with all of this for you!

The actual import of these chunks is done by React.Lazy and dynamic imports. Let’s take a closer look how this is done:

The example shows a chunk named WishList and a chunk named GiftTable. Instead of a regular import statement we use React.lazy. React.lazy takes a function, that must call a dynamic import, as an argument. This returns a Promise which resolves to a module exporting a React component. If you want to know more about React.lazy, hang on a few more days for an article just about lazy loading in React!

Because WishList and GiftTable is dynamically imported, we wrap the components in Suspense. Suspense will try to render WishList and, of course GiftTable. If the chunks is not loaded completely, the Suspense component will render the fallback component until it can render the two child components successfully.

For simplicity, in this example the suspense component is an immediate parent of WishList and GiftTable. However, suspense can be placed anywhere above them in the tree, depending on how you want your loading state to be.

But, what if it fails?!

As earlier stated, Suspense only handles the loading state as you try to dynamically import a component, not errors that may occur. It is also a known fact that anything that can go wrong, will go wrong... at some point. Therefore, we need a way to handle the errors that may come as we are trying render our chunks. We also want the error handling in the same declarative way, we are used to in React. In comes error boundaries.

Error boundaries are components with special lifecycle functions like getDerivedStateFromError() or componentDidCatch(). These functions are there to catch errors in their child component tree, so you can render an error UI and log the specific error. In our example it will look like this:

Note that as suspense, the ErrorBoundary component does not have to be a direct parent. You can place it higher up in the tree if, for instance, the error UI should hide more than the actual component that crashed.

If you want to learn more about error bounderies and how to write them, Kristofer Selbekk made a smashing article about it in last years calendar. Take a look!

Suspense in the future

This was a "quick" intro to React.Suspense and how it is used with code splitting. However, tomorrow we will see what Suspense will become in the future. A hint – it will not only be used for code splitting, but so much more! We will also take a deep dive into what problems suspense tries to solve and how we structure our code to make a great user experience – so stay tuned!

Oh, the Suspense!

Up until now we have learnt what machine learning is and looked at some initial examples. But before we move on with more details of how to do machine learning we must first talk about why. In this blog post we‘ll present a high-level overview of practical application before diving into a real-life example from our work at the Center for Service Innovation (CSI) in Norway. The basic concept? It‘s all about business value!

###The business value of machine learning When people talk about the practical application of machine learning (ML) we often hear about the major events and the extremes. A lot of articles revolve around the history of machine learning and AI, from the turing test created in the wake of the WW2 codebreaking revolution, via computers beating grand masters at chess, to the creation of the self-driving cars of today. Interesting and cool stuff indeed, but most companies don‘t break codes, play chess or build inteligent cars. So when looking at practical application in this blog post we‘ll be targeting some more mainstream business challenges (Sorry, Tesla).

We‘ll start our story with the adoption of machine learning for the purpose of cost reduction and operational efficiency. Some of the first industries to find good use of machine learning were companies responsible for maintenance of physical objects, like elevators and wind turbines. In these early cases, sensor data was used to read patterns on well-functioning machine parts and replace them when this pattern was broken, so-called predictive maintenance. This as opposed to preventive maintenance, where critical parts are replaced at pre-defined intervals. The financial gains from this new way of thinking were massive, and other ways of using ML for operational analysis were soon developed, like demand forecasting, delay prediction and various types of process automation.

Gradually marketers and business developers also opened their eyes to ML, and new areas of application were born. In these use cases there are generally less focus on physical objects and more focus on the fuzzy, intangible asset called customers. Better value propositions to customers can be developed through for example automated a/b testing, personalized news feeds and market basket analysis (You know, that Netflix/Amazon recommendation thing everyone used to talk about). For those concerned with customer sales and revenue, well-known examples include churn detection, predict purchase and discrete choice analysis for price optimization.

Each of these use cases are in themselves pretty interesting, and we could easily go on and on to describe them more in detail. But that would require an unreasonable long blog post. So we‘ll instead leave you with a summary of some of the application areas we find most interesting, categorized according to the business value they provide (kind of), before providing a short example.

###Example: Using machine learning to increase customer profitability

One of the application areas described in the illustration above is to calculate Customer Lifetime Value or CLV. CLV can be defined as the future cash flow from a given customer relationship. The sum of CLVs for all current and future customers is called Customer Equity and represents the total value of a company’s customer base. CLV has several fields of application, including:

Identify the right customers to spend money on and where the potential for increased profitability is largest

Deliver personalized customer service and marketing to improve customer experience and boost sales

Create a business cases for investments, where ROI is represented as the change in Customer Equity

Estimate a company’s financial value (For service-oriented companies Customer Equity is considered to be a good proxy)

The importance of CLVs was one of the key factors in the work Bekk did for the Center for Service Innovation (CSI) at the Norwegian School of Economics (NHH) that recently finalized its work. Bekk had the main responsibility for one of the research themes at CSI (Service Innovation Economics), with the aim of developing methods to measure the financial effects of service innovations.

To summarize, our research required us to develop profitability models with customer-based logic, where CLV and Customer Equity are established as the basic measurements of profitability. However, the data needed to calculate CLV does not come for free. Even in its simplest form CLV requires estimation of future contribution margins (the yearly future profit from a customer) and retention rates (probability that a customer stays with us for another period), as well as a discount rate to create a cash flow, illustrated by the typical CLV definition below:

In practice we often also need more fine-grained representations of CLV to do real-life calculations. Hence, CLV is not a trivial number to estimate, and requires relatively complex modeling and calculation. Even though CLV is a well-established concept, we believe this is an important reason why CLV has had limited practical implementation.

Stuck with what seemed to be too complex calculations in our research; in came machine learning in white and shining amour. Without going into all the details: Based on available customer information, computers can identify patterns, build models and estimate CLV values – much faster and with more complexity than a human can handle. The model can also self-improve as more data becomes available. This represents a new way of working with CLV-calculations, where the model and key parameters are defined as we go along:

Too difficult and expensive, you say? Contrary to some beliefs such a model can be created and set up relatively easy, with low investment costs. In our research we also encountered Norwegian companies that already have a fully functional CLV-model running, with very promising results. And even better: When you have a ML model using customer data running, you have a good foundation for expanding your model to support other areas of application, as seen in the illustration further up.

That seems like an excellent platform for generating business value, wouldn’t you agree?

4-Dec

Today's posts