IT Integration and Product Management: A Lesson Learned from the Racetrack

I’m kind of a car nut in my spare time. I was reading through an article this week on how to be successful on the track, and it occurred to me that the same advice would apply to IT convergence and integration. The article is titled “Why Not Going Slow Is More Important Than Going Fast.” It talks about a common mistake by both professional and amateur drivers (I’ve made it myself): focusing on the wrong part of the racetrack.

In a converged infrastructure deployment or, come to think of it, in a go-to-market plan, we often make this same mistake. Let me explain.

Racing

Let’s start with the racing lesson to set the stage. Race car drivers like speed, so they often focus on power plays, living for that top speed on the straights because it is both the most exhilarating and, to be totally frank, the easiest part of a course. However, if you do the math, the car spends more time on the slow portions of a course than it does on straightaways. Increasing the speed 10 percent on the slow portions of the course will have a much bigger impact than working at top speed in the straights.

This isn’t obvious because you think faster is better, but it’s average speed you are working to increase not peak speed. When facing a choice, a race car driver is better off focusing on increasing their slow speed time than their top speed time.

PCs

I ran into a similar situation while doing my Windows 10 testing. I had a little Acer box with a Celeron processor that was painfully slow because it had a 500 GB magnetic drive and only 4 GB of memory. I swapped in an SSD drive and 16 GB of memory and found . . . it was still slow. I hadn’t realized the Celeron was not only relatively slow but single-core (it has been a long time since I’ve had a Celeron box). I should have focused on bringing the processor up to two cores first then looked at the memory and hard drive. I likely would have created a faster system for a lot less money.

Convergence/Integration

In any converged or complex system what you want to increase is the total system performance. It is really easy to buy and implement faster networking, faster memory and even faster processors, but in each instance the system is likely to bottleneck someplace else. We tend to become enamored with these new technologies which we toss at performance problems like folks playing darts when instead we should be focused on system metrics and overall system performance.

This is one of the reasons I historically prefer the VCE approach to creating a converged system. With VCE you start with a system, not a collection of often poorly matched components. The VCE approach results in better utilization because everything was designed to work together.

Product Planning

I see this all the time in product planning. A great deal of focus is spent on time-to-market but very little on building demand for the result or even assuring there is a market for the offering. Doing market research is time consuming, but if it isn’t done, not only could the product not reach its potential you may find, as I did at one time, that there was no conceivable customer that wanted to buy the damn thing.

We often tend to avoid the slow hard stuff (like vetting a name) in order to just get the product out the door quickly. We can see the result with products like the Apple Watch, which came to market quickly but is currently finding demand illusive and having to overcome a name that doesn’t have an “i” as the first letter. Google Glass was worse. Google was so aggressive at getting this product out the door they may have destroyed the consumer market for this entire class of products as a result. In this instance, the slow parts of this process may not be slowing the product to market, but they aren’t getting done. The result is poor market performance.

Advice for Any Process

I think this racing advice applies to any system or process. For instance a while back I suggested companies focus on tools like Experfy or BMC’s M-Control solution to correct the data scientist bottleneck.

The time spent identifying and speeding up the slowest parts of the process will have the greatest impact on overall process/system performance and thus should be prioritized even if they aren’t that much fun. Rather than making the fast parts of anything faster, focus on the slow parts, because that is where the best improvements will be found. Or just start with a system and focus on the system speed as a better way to identify the critical path that will provide the best return on your investment.

However you get there, focusing on not going slow will always be a better strategy than going fast.

Photo courtesy of Shutterstock.