Recently I've been reading Ken Kocienda’s Creative Selection Book “Inside Apple Design Process”. From the title itself it might sound like a design book, but in reality it is an in depth look at how Apple ships new products and features. Ken is a software engineer, not a designer, but by reading the book it is clear how a professional like Ken takes into roles that are not common in other companies and how prototyping is embedded in Apple’s culture.

‍

One of the examples that took my attention in the book was when Ken was working on the keyboard for the Ipad. After the release of the Iphone, Apple was working on the Ipad and one of Ken’s tasks was thinking on how the keyboard would be displayed in such a device. Initially the design team had a proposal on how to display the keyboard, Ken discussed the solution and went on to build a functional keyboard in the device. After trying out the design Ken came up with a new proposal that included a more condensed keyword with bigger keys. He then went on to show the prototype to the design team and jointly agreed that they should have a key in the keyboard that could switch between the two different options. Users would love both they thought.

‍

After making some adjustments they went on to show the prototype to Steve Jobs. After Steve played around with the new keyboard he said “Do people need both?”. He then asked Ken which one he would choose and Ken opted for his option, not because of pure ego but because it was better. Jobs agreed.

‍

What I really liked about this example was that Ken was not only collaborating with other areas like design closely, he was actively involved in the design process and development. But most importantly Ken understood the importance of prototyping to test their ideas. Apple prototypes every single new feature, being hardware or software and one of the great things about it is that this prototyping process that includes several iterations starts early, with a raw first approach that continuously improves the product to be shipped.

‍

What can we extrapolate from this experience in the way Data Science teams build and deploy models today?

‍

Reality is Data Science teams today are siloed. Companies usually have a core data team that get a requirement from the business units and then work for months on a model that they can deploy. In a recent poll in a Data Science Slack channel the average time to deployment was 3 months. Close collaboration with business units and prototyping is almost non-existent and mostly it is due to the difficulties and resources needed to deploy models into business applications. Things like scaling machines, scheduling and API’s need to be built and a lot of times this is dependent on the availability of developers and ML engineers in the organization.

Business units then opt for excel files and simply not make the leap into a data driven organization.

‍

Currently more and more companies are opting for embedding data scientists or data analysts into business units which is a huge leap forward in terms of collaboration via a re-arrangement in the org chart. This is helping organizations to have a close relationship with their data teams but not only that, it is giving speed to the organization. Unfortunately only few companies with the budget can achieve this due to the scarcity of data professionals and limited budget. Now, companies that are doing this although are increasing collaboration still have a problem, the capacity to prototype and iterate the way Apple does. The ideal would be that the Data Scientists embedded in the business unit could build its model after discussing with the business leaders and then quickly and easily put the model into production without having to ask the core team for an API or a deployment. This would give the business team the capacity to get the feedback needed to iterate, adjust and re deploy their models. 

‍

After several iterations then the business unit could communicate the results to the core team who could then decide if they want to make the model core or as part of the core infrastructure.

‍

In conclusion, new technologies are needed in collaboration with core infrastructure to give teams such flexibility but we need to definitely change the way data teams and business units work together and prototype in order to adopt best practices and evolve in a world with more and more focus on data. Prototyping, time to market and speed of iteration will be key in the next phase of data science.

‍