Digital Transformation for a Top 3 Global Heavy Equipment Manufacturer

When you manufacture anything, let alone heavy equipment, there's a ton of things to consider to have a healthy business. From profitability to design to operations to inventory management to quality, it can be a huge balancing act. But what happens when you believe your products will become obsolete unless they have the critical digital tools to help our customers run their business?

The biggest issue with digital transformation at a big, traditional company is staying closely connected to lots of customers from the concept to the final release. Especially when the firm has been successful for decades using a waterfall approach to incremental improvements to a product line that hasn't changed significantly in over 50 years. During that waterfall approach the "Voice of Customer" or VOC should be included when choosing the right improvements to make, however, rarely is there any value confirmation from the customers before the field follow takes place just before the new piece of equipment goes to production. During that field follow the company is trying to answer the question "Does it work?" rather than "Does this really create the value for you that you said it would?"

Waterfall is the most efficient approach to product development when the problem and solution are known. When the problem is not known, waterfall has too much time between customer feedback loops and you'll pass the right customer problem like ships passing in the night.

In my case the problem was too broad to aim a develop team toward. "We will help customers be more efficient on their job site with data from our machines." Armed with our problem statement, we set forth to build a solution. Since our problem definition was too broad, we did not understand who we were building our solution for and what questions they were trying to answer to make their job site more efficient. What we ended up with was a dashboard with all the data you need to solve every problem for every person. Oh and by the way, we had no focus on customer experience so it was a miracle when a customer could actually log in to the tool. Our ship was sunk.

Where do we go next? It all starts with the customer problem. If you can admit that you don't know the problem you're trying to solve (at least to enough detail) the LeanInno framework can save the day. The customer problem statement template we use is [Customer segment] needs a better way to [complete job] because of [problem].

The first area is the customer segment. No I don't mean the traditional customer segmentation that has been used to sell heavy equipment for decades. It's the segmentation that's important to this project. We started by interviewing equipment managers. These are the guys usually sitting in an office that are managing the maintenance and repairs of the equipment. We quickly realized that these aren't the guys managing the operations of the customer job site. If the site produces one more ton per day, it doesn't affect these guys jobs at all. This was a huge success. We found out who is not a customer segment for this project.

We moved on to foremen, production superintendents and company executives, all of which had production goals in their direct or indirect job goals. These people have a job to track productivity and fix problems that result in lower job site production on a daily, weekly, and monthly basis. Now we were getting some where. We had a customer segment (operations and management personnel), and a job to be done (tracking and maximizing productivity on a daily, weekly, or monthly basis.)

Next we needed a problem. How are these jobs done today? What's difficult about them?

One asphalt plant superintendent told us that he needs to drive 2 hours away just to show his face and see for himself if the site was being productive or not. There's a joke that if you want to improve the productivity of your job site that all you need to do is park a pickup truck on the hill so the workers think they're being watched.

Another production superintendent told us he just wished people would stop calling him. He gets bothered too many times for production updates by his bosses and still has to deal with issues from workers reporting to him.

What if there was a better way? What if data coming from the heavy equipment could tell these managers and supervisors how well the sites were doing each day, week, & month?

This problem statement allowed us to focus on taking the data we had available and begin to create hand-sketched prototypes of a solution and learn more deeply about the value a solution would bring to users and helped us eventually build a solution that customers love.

Early sacrificial prototypes to better understand what users wanted from the app.

Key Take-aways

• Too broad of customer problems are just as dangerous (if not more) than no defined customer problem.

• You need to know the specific user and the job they need to complete before you can assign a problem or a solution.

• Just because certain users have used your digital tech in the past doesn't mean they'll be the ones to use it in the future.

• Iterating on early digital concepts, even on paper, really help you zero in on the value for users, or it will show you for minimal investment, if your idea needs to be shelved for later.