The Realist’s Guide to Emerging Technologies

A construction company called a fleet operator with a question: was anyone coming to collect the large digger that had been sitting on its site for six months? Hod Fleishman recalls the story from field research into off-highway equipment. The problem was not a lack of impressive machinery. It was knowing where equipment was and how it was being used.

His team developed a sensor box that attached to a machine with magnets, providing information about location and utilization without the complexity of a traditional hardwired setup. In this episode of Innovation Rockstars, the BCG venture builder uses examples like this to explain his approach to emerging technology. Understanding the problem, judging what a technology can actually do and building with the people who know the business are all part of the same task.

Spend longer on the problem

Fleishman's first recommendation is to give problem definition more time. A team can expend considerable effort debating solutions while still misunderstanding the difficulty it needs to address.

The fleet example shows why observation matters. Research revealed equipment left running and poor visibility into its use and whereabouts. Those findings gave the team a practical target. The solution could be judged by whether it made managing a fleet easier, rather than by the sophistication of the technology alone.

He makes a related point about protecting early ideas. A concept can be easy to dismiss before it has enough detail to withstand scrutiny.

“You should give these early ideas a chance.”

This is not a reason to avoid testing. It is a reason to let an idea develop enough substance to be tested usefully. The work moves between understanding the problem and refining a possible response, rather than expecting a fully convincing solution at the first discussion.

Match the technology to the time available

Fleishman distinguishes technologies still in laboratories, those gaining market momentum, those ready to scale and those already commoditized. The relevant choice depends partly on the company's time horizon and willingness to take risk.

A business that needs to launch in six months faces different options from one exploring what could become possible several years ahead. The same problem may support different solutions depending on that constraint. Assessing maturity therefore belongs alongside the discussion of market opportunity.

He also points out that unfamiliar technologies bring unfamiliar design questions. In a conventional app, many interface choices are well established. In an immersive environment, even deciding where a settings or contact function belongs can require exploration.

For R&D leaders, the implication is to examine what remains unknown at more than one level. Technical performance matters, but so do user behavior, the interaction design and the practical route to delivering the product. Excitement about a capability does not settle those questions.

Put business knowledge and technical knowledge in the same room

Fleishman describes venture building as a shared activity. Engineers, designers and business specialists work with people from the client organization who understand its operations and customers. That involvement begins with concepts and continues through validation, development and launch.

The team has to connect two perspectives. Business ambition can outrun what a technology can deliver. Technical enthusiasm can also move ahead without a clear view of who would pay or why. Fleishman's role is to help find a concept that joins a meaningful need to something the team can build and test.

The company's existing assets matter in that assessment. A venture should make use of something distinctive about the organization, rather than becoming an unrelated idea that any company could pursue equally well. Understanding those assets often requires looking closely at what happens inside the business, including its data and operational practices.

Look for a change in the user's work

Another project Fleishman describes involved voice transcription for laboratory scientists. Someone handling equipment and working at a microscope also needed to record what they were doing. The team developed a voice-based approach to note-taking and, in some cases, equipment operation.

The example makes the opportunity specific. It changes how a scientist interacts with the tools and information needed during work. A separate project used computer vision and connected devices to identify hazardous situations in industrial environments and alert people nearby. Fleishman presents both as applications developed around concrete operational problems.

He argues for considering advanced technology where it could offer meaningful differentiation, with validation throughout development.

“You actually test, and you build as you go along.”

For a team considering a new capability, his examples suggest two productive questions: could it improve something that already exists, and could it make something possible that could not be built before? Either question becomes more useful when attached to a person, a setting and a problem understood in detail.

Keep the outcome tangible

When Fleishman needs a break from digital innovation, he works on a 1973 Volvo station wagon. Rebuilding an old car provides an unusually analog counterpoint to his day job. It also fits the emphasis on making things work that runs through the conversation.

His proudest startup memory is similarly concrete: the first large customer deal. What mattered was the realization that someone had chosen to spend money on what the team had created, despite having other ways to solve the problem.

That is the destination behind the technology assessment and experimentation. A venture becomes meaningful when the proposed capability reaches a user and proves worth choosing. The forgotten digger, the scientist's notes and the first customer contract make that test easier to picture than any broad claim about a technology changing the world.