In my last blog post, I explained how we had stumbled upon a manufacturing company that wanted to reduce the time it took to develop new products, but was unable to do so.  

However, we knew we couldn’t build a business on the basis of anecdotal evidence from just one company in one country.

Follow us on our journey at Unifize as we took Steve Blank’s advice to ‘get out of the building’ to the next level…in Vegas…

“The plural of anecdote is data”

– Raymond Wolfinger, although some statisticians contend that the word “anecdote” implies information surrendered, not collected, which can lead to reporting bias

A local problem?

You may not agree with the principles advocated by Eric Ries or Steve Blank.  If you don’t, my own experience tells me that you probably haven’t read their books, and feel comfortable judging them by their cover or, at least, their Amazon summaries.

Regardless, you will likely agree that it’s unwise to build a technology company which only solves a problem for one company.

At Unifize, we were mindful of this reality and apprehensive about leaping to broad conclusions on the basis of our interactions with a single manufacturer of wind, turbine and gas steam generators.  

So, armed with our own, well-thumbed copy of the Four Steps to the Epiphany, we visited 24 other manufacturing and engineering companies in India, only to discover a repeating pattern of failed product development objectives.

Maybe we were on to something?  Maybe not?

We hadn’t started Unifize to solve a local problem.  We not only needed to get out of the building. We also needed to get out of the country.

What goes on tour, validates a problem

I had been in touch with some of the Autodesk team since they had invited me to do a talk on design automation in Las Vegas at Autodesk University in 2015.

Autodesk University 2017 is about to start in Vegas.  There’ll be a bunch of manufacturing and engineering businesses there,” I suggested about two weeks before their opening day in November.

“What’s Autodesk University?” Lakshman said.

“Didn’t you hear me properly?  I said Vegas.”

After we had finished booking our tickets and a small booth, we spent the next few weeks hacking together wireframe mockups in InVision and some posters that showcased our cause.  

We had still not written a single line of code, but we needed to use this opportunity to accelerate the validation of our problem hypothesis and our embryonic solution.

It takes about 30 hours to fly from India to Las Vegas, so we arrived in a heap only a few hours before the trade show opened, and then had to go through all the usual panic of getting our booth up and running:

Our routine was to pounce on people who appeared to have interesting descriptions on their badges, haul them to our booth, ask them questions and show them a quick demo.

One of the first people we snagged was an engineer at BMW.

“Do you have a few minutes?” Lakshman said.

He looked us up and down and then glanced at our booth.

It’s chaos,” he said with teutonic dryness.

“The trade show? I know, the registrations desk this morning was a nightmare…” Lakshman said.

“No, communication at BMW.  Everything is done by email.  It’s all over the place.  It’s impossible to keep track of things.  Do you have an on-premise solution for this?” he said.

Over the next few days, we had 26 meaningful interactions with product design, manufacturing, architecture, engineering and companies from around the world of varying sizes, of which we identified 8 companies as early adopters of our solution.

And, since we were in Vegas, we took the opportunity to visit some museums and get to bed early.  The last thing we needed during three days of a trade show was a splitting hangover and the shame of having lost $760 on the last hand of poker at the Bellagio at 4am.

After Autodesk University, we spent some time on the East Coast and in the UK with companies like Raymarine, Hozelock, Cummins, and Cisco.  We then returned to India with new insights into both the problem and how we needed to build our solution.

A paradox revealed

While our problem discovery interviews in the US and Europe covered a number of topics, at their core we were trying to answer the following two questions:

  • Do you want to reduce your engineering cycle times?
  • Do you measure your engineering cycle times?

If the majority of manufacturing and engineering businesses didn’t measure their engineering cycle times even though they claimed they wanted to reduce them, this was a problem worth solving.

Furthermore, as we explained in an earlier blog, engineering is a communication process.  If we could provide these companies the communication tools to measure their engineering cycle times, we may even be able to solve the problem.

The following table summarizes the results of these questions:

A problem worth solving...

Approximately 80% of Indian and European businesses stated they wanted to reduce their engineering cycle times versus 100% in the US.  Out of all fifty companies, we only found one that was actually measuring its engineering cycle times.

The combined revenue of all these businesses was in excess of USD 200 bn.  How much value and opportunity cost was being wasted due to delays in product development cycle times?  

For example, a cookware manufacturer that does a third of its USD 360m in revenue from 80 new products a year can expect to improve its cash flow by USD 2.4m for each week of product development time saved, not to mention the additional cost reductions and profitability from achieving earlier market penetration.

That sounds like a problem worth solving!

Did you like this article?

Subscribe to receive our newsletter
Get the latest Unifize content delivered straight to your inbox

Leave a Comment

Sign up to receive our latest blogs!

Get the latest Unifize content delivered straight to your inbox