Disruption and Denial 

When the Internet emerged in the mid-1990’s, it seemed clear to me and many others that we were entering a new era of technology, one where our devices and our servers would all be connected, and where data would largely be stored in the cloud.

The Internet was essentially a new platform, and a large part of my job (I had the role of VP Platform and Tools for Netscape Communications at the time), was to evangelize this new platform to developers and product companies, so that they could start building the new generation of connected products.

At the time, the single most common objection I would get is that so many people simply did not want to believe that the Internet both enabled and necessitated a very different approach to discovering, delivering and distributing our products.  So many people insisted that their old roles, and their old Waterfall ways of funding, building and shipping projects were still just fine.

The second most common objection I would get when I was explaining this new application architecture was “this is cool, but we can’t use this because our data is too sensitive to be stored in the cloud.” ¹

Now, we knew that not all new products would be connected products, but it seemed clear that you would still want to use the Internet to discover and deliver your product.

This was a big reason I decided to write the first edition of INSPIRED.  I felt I needed to talk about how different product development could and should be, when you’re using the Internet, to discover and deliver connected products.

Fast forward 25 years, and I’m seeing much the same dynamics with AI products.

The single most common objection I hear is that “yes, this is a very impressive new enabling technology, but nothing really changes. We still need to discover and deliver products much as we used to; and AI is essentially just another feature.”

The second most common objection I hear is that “this is cool, but we aren’t suitable for a probabilistic solution because [any one of a dozen common objections], and we simply can’t build on a technology that might hallucinate, or that we can’t test for all situations in advance.”

Much of my writing for the past year has been trying to speak to this first objection, and I have much more coming.  

I do understand the very human desire to want to believe that your job and your skills are secure, but there really are some very significant differences when discovering and delivering intelligent products, especially if you want that intelligent product to be perceived by customers as truly valuable.

I believe there are very substantial changes heading our way, to the topology of product teams, to the roles on the product team, and to how those product teams discover and deliver solutions.

I wrote about the second objection in the recent Creating Intelligent Products, I’m not trying to make light of behaviors such as hallucinations, but I’m also trying to show that strong product teams can and do use appropriate techniques to mitigate these risks.  

You can either start working to create these intelligent products yourselves, or continue to believe it’s not possible, until a new competitor comes along and shows your customers a dramatically better solution.

I’m fully aware that just like always, some companies, especially startups, will move quickly and aggressively to take advantage of the new opportunities, and some companies, especially large enterprises with much to lose, will find excuses to deny or resist.  So it goes in our industry.

1.  If you don’t know the origin story of salesforce.com, it was a great example of seeing the real opportunity the new enabling technology provided, well before most customers understood, and then riding the technology adoption curve as customers started to recognize the value.
   ↩︎