Deploying AI in your business

A bookseller with a problem

‍
So you’ve heard AI is revolutionising your life, your business and your cats. In boardrooms around the world there’s talk of ‘AI strategy’ and a new industry of consultants has popped up overnight.

‍
Early in my career someone told me there’s no such thing as artificial intelligence, only artificial stupidity. Now that I work in AI I’m not sure what to make of that.
I’m going to tell you a story about a hypothetical company called Sahara. Sahara sell books online, shipping them to millions of customers every year. Sometimes things go wrong and at Sahara’s scale even very unlikely events occur all the time. Pretty unlikely for the delivery van to be struck by lightning twice, but it happens. Unfortunately Sahara’s customers are unforgiving creatures; they’ve learnt to expect their orders in perfect condition, now.

‍
Sahara’s formidable yet fictitious leader Seth Kezos has an idea: if Sahara can predict when a customer is unhappy, they can intervene. Without intervention those customers might leave for a competitor. So here’s a business objective as old as business itself: don’t lose customers!

‍
Seth talks with the senior engineering team, a panel of very clever people who surely know the answer. We’ll need a machine learning model, they decide. Perhaps a deep neural network? Yeah that sounds about right. And tensors! Flowing tensors. It can of course be trained on customer return and complaint data — which everyone is fairly sure the customer service team collect, although no one has seen it. They’ll have the whole thing done in a Jupyter notebook in about eight weeks.

‍
Seth isn’t convinced.

‍

The design sprint

‍
We want to build something that’s genuinely useful to the business; anything else would be a waste of time and money. The business problem is undoubtedly legitimate and solving it will have a measurable impact on Sahara’s performance. But it’s also vague: don’t lose customers how? Which customers? At what cost? When? How will it be measured?

‍
What appeared to be a clear goal has turned decidedly murky. Luckily our CEO has been reading Sprint, a book from Google Ventures. According to https://www.thesprintbook.com:
‍

“The Design Sprint is a five-day process for solving problems and testing new ideas”

‍
Sounds great! Google Ventures work with all sorts of startups so for them being able to test a new idea rigorously in only five days holds a great deal of value. While Sahara is no startup a design sprint can help them too as they embark on their first AI project.

‍
Seth pulls together a team to engage in the week-long programme with the aim of figuring out what they really want to build. This team includes representatives from Customer Services, Software Engineering, Marketing, Logistics, as well as Seth himself. It’s important to have professional diversity as it mitigates bad assumptions. To ensure no time is wasted, Seth tells the team to cancel other meetings and set up out-of-office email replies. For most of the week no electronic devices are allowed.

‍

‍

‍

Monday

Map out the problem and choose a target to focus attention on.

‍
First a long-term goal is agreed. Next the team maps out the problem space, before narrowing it down to a specific target. An important part of the process is capturing information from experts.

Tuesday

Sketch out competing solutions

Following Monday’s sessions the team knows what their target problem is. Everybody takes part in solution sketching, because each person has a unique perspective. Team members are encouraged to seek inspiration from a variety of places — sometimes the best solutions come from a different industry. Solutions are drawn with pen and paper.

Wednesday

Decide on the best solution

The competing solutions developed on Tuesday are anonymous, so presentation and language is key to making them self-explanatory. On Wednesday the sketches are placed on the wall like exhibits in an art gallery. Out of these the team members choose the most interesting ideas and concepts. The designated ‘decider’ chooses the solution which will ultimately be used for prototyping.

Thursday

Prototype a solution

Often software prototypes eschew good engineering practice for the sake of speed, then the ‘prototype’ becomes production. Here prototyping has a singular purpose: to capture useful feedback from users. No code needed; the prototype can consist of crudely mocked-up user interfaces.

Friday

Validate the solution

Throughout the week there are a few things happening in the background, among which is the recruitment of ‘customers’ to participate in prototype testing. One member of the sprint team acts as the ‘interviewer’. The interviewer needs to be personable, because their role is to get honest feedback from the customer, which begins with making the customer feel at-ease. The rest of the team can observe from another room (with a video link).

After giving the customer the proper context the interviewer asks him or her to perform some tasks using the prototype and to think aloud while doing so. Afterwards the customer can provide further feedback on the prototype and the experience of using it.

The happiness engine

Fun fact: you’re about 850 words into this story, and I’m nearly finished, so bear with me. For an imaginary company like Sahara the outcomes are imaginary too, but let me tell you how I like to think the design sprint turned out.

Having considered business priorities and risks the team decided to focus on one small problem: customers who, having paid for one-day delivery, see their order arrive late. While Sahara already refunds the delivery cost in this situation, nothing more is done to make amends. The delivery refund is the least the business can do.

So the scenario which the team would like to test is simple: if customers are given gifts following a negative experience, will that leave them feeling happier?

Ok, I know, ‘if delivery late, give customer a voucher’ isn’t exactly ground-breaking AI (although it might at one time have been called that; goalposts shift), but it is something which can be prototyped and tested very quickly and if it works then we know it’s worth spending more resources on.

In time the ‘customer happiness engine’ can take into account more sources of data and make more sophisticated decisions — for instance getting a customer service agent to phone the most unhappy customers, providing insight into customer sentiment, and later on using buying behaviour to improve the model. From a vague idea we’ve ended up with a simple prototype and a set of testable hypotheses that tell Sahara what they should do next. Think of this as the first step towards something smarter.

What’s next?

There’s undoubtedly a great deal of hype surrounding artificial intelligence. While it’s an exciting field to work in it’s important to not let hype drive your decisions. Whether you’re using data to gain new insights into your customers, or building better user interfaces, or one of the many, many other applications of AI, the focus and discipline that comes with a design sprint can lead you to a solution that has genuine value to your business, with experimental evidence to back that up.