Case Study: Automated Warehouse

1. Introduction

A provider of fluids for the manufacturing industry wanted to increase fluid sales through a competitive advantage of making the re-ordering process of fluids as easy as possible for customers. It was clear that a solution will have to have something to do with sensors. What kind of offering to develop was not clear at the beginning. 

A highly motivated team started into a Business Design Sprint. Through interviews and onsite visits the team found out that re-ordering of fluids was indeed a task that consumed a certain time. However, the whole process of managing a warehouse full of many different fluids turned out to be a much greater challenge for customers and had a relevant impact on process security in manufacturing.

2. Prototyping in the Design Phase

Coming from the Discover Phase with above mentioned insight as well as insights from tech research the team set up a Business Model for an automated warehouse management for fluids. Defining a first Landing Page for internal use describing the offering was of great help for the team to quickly get a better picture of the main aspects of the Business Model. By discussing the content of the Landing Page the team became more and more precise: What the core value for customers really could be, what critical points exist regarding the integration in customer`s processes, innovative payment models and other aspects. The Landing Page was very helpful in making aspects of the Business Model tangible within only hours. And, equally important, through the Landing Page the team started to feel more and more attached to their idea.

3. Prototyping in the Validate Phase

Like always in such innovation sprints, there were quite a lot uncertainties in the Business Model. 

• Will customers rely on the new system?

• How much will the solution be worth to our customers?

• What do customers need to see on their dashboard?

• How long will the battery last in a sensor unit? A need for often recharging would not work in this environment. 

They formulated the following hypotheses:

• We believe that sensor units can measure fluid levels of interchangeable containers from 0 to 1000 liters.

• We believe that we can design sensor units in a way that we can build it with in-house capabilities.

• We believe that customers are wiling to pay amout X per month for the solution, so that it makes economical sense for us to provide the solution.

• We believe that we can build a sensor unit with a simple battery lasting minimum 3 months when sending a signal every 10 minutes.

Before investing time and money into functional prototypes with sensors the team first wanted to find out if there`s any interest in such an automated warehouse management system for fluids on customer`s side. The team iterated the already existing Landing Page and included renderings of sensor units. At this time no one knew how exactly the sensor units would look like in reality later on. But quickly made CAD files of imagined sensor unit designs were rendered and looked convincing enough. Also, a Click-Dummy of a user dashboard to monitor the sensor units in the warehouse was built.

In a first experiment, the Landing Page and Click-Dummy at hand, the team went out to propose this new solution to potential customers in an interview. The purpose was to get a first impression of potential customers reactions to built up enough confidence for the team and for the sponsor that this offering is interesting for customers. Also this touchpoint was used to get input from customers what they like, don't like or miss. Customers reactions were throughout positive and the team promised to contact them again in 4 weeks for the next steps.

Customer`s feedback was throughout positive which motivated the team and the sponsor to continue with the project. Also, the pressure was now rising to validate technical hypotheses and to adapt some details of the offering based on the customer feedback. The team conducted technical experiments to test functional aspects of the offering. Functional prototypes were built consisting of sensor units, data transmission and a dashboard. Besides clarifying technical questions these experiments were also used to see, if the hardware components could later be built in-house in series. Team members were quickly trained in building the sensor units themselves which also validated the hypotheses that the sensor units can be built in-house.

4. Building a Lean Offering

We only know for sure, if customers buy when they buy - the next stage of experimenting included the goal to get sufficient customer commitment.

In a second interview with the customers a few weeks later the team presented a functional prototype. This was then also the time to ask for customer commitment that would enable customers to actually use the proposed solution once it is ready to deliver. When customers liked the concept of the automated warehouse management system and the technical approach the team then proposed a pricing model and the option to sign a pilot customer agreement with a free trial phase and a binding annual payment after the trial phase. Two out of three contacted customers signed the contract.

The team was on fire. And now the pressure was really high to actually deliver the solution within weeks only. The software part (dashboard) was finalised and more sensor units were built in-house in a refined version.

5. Conclusion

This step by step approach gave the team needed self-assurance and security in justifying the commitment in front of the sponsor after each step. It was important not to dive into technical perfection here, this would have taken too long. All we needed was something that works for a certain time to get the business relevant customer commitment. It was clear that all technological aspects could and had to be improved for serial implementation, once we had the necessary feedback from the market. 

This project shows nicely how lean IoT Prototyping can be very useful to get business relevant feedback within a short time without investing a lot of money. And it shows that by just doing it and building prototypes the team learned even more about their own capabilities within the organisation and about the willingness of people in the organisation to commit.