Profitable Problem Solving in the AI Era

We're in a period of collective imagination.  The phenomenon is periodic in nature and at the heart of our economy.  A new idea comes in fashion, promising to stimulate innovation.  Capital chases it.  Markets expand in anticipation.  The idea may be little more than a fantasy at this point, "let's put people on the moon."

Where there's a will there's a way.  Engineers race to realize the vision and capture the business for their owners before the competition does.  Some time later, some black and white version of the dream is realized.  Maybe the vision is still colorful to the layman, but the engineer's broken it down and rendered it mundane.

It takes time to realize a vision.  Necessity is the mother of invention.  Innovation is problem solving.  Problem solving is a matter of fully exploring a problem space and understanding it.  This is primarily what engineers do, explore and define the boundaries of a problem space.  

AI can't solve problems, but it can help.  We can break problems into the following categories:

  1. Has your problem already been solved?
    1. AI can offer you the full solution and save you a lot of time and effort.  You probably won't directly profit from this though because someone else already has.
  2. Is your problem new, but has analogues or sub-problems that have been solved?
    1.   AI may help you research to identify those.  In this way it functions a powered up Web Search, which is itself a powered up Library.  The creative leap of identifying analogs, metaphors, and hierarchies is up to you as a human though.  If you can bridge the gap and create a functional composition of other solutions with AI's help, you may be able to profit.
  3. Is this truly an unprecedented problem?
    1. If so, it likely lies in the territory of academic research.  AI can likely help you apply #1 & #2 to sub-problems.  Profit is less likely here as the level of effort and therefore investment is high.

The business sweet spot lies in #2.  We use AI for speedy research so our imagination can flow.  We creatively bridge analogous problems and experiment with the application of their solutions.  We move from depth first problem space exploration to breadth first, relegating the deeper dives to AI wherever possible.  The value add is less computational and more intuitive.  However, we still have to fully explore the problem space and by force of will render it mundane.


Comments

Post a Comment

Popular posts from this blog

Engineering Truisms

This is a brief collection of quotes, laws, and truisms that I've gathered over the years.  I've kept those that have consistently proved themselves across organizations and projects during my career.
Read more

The Importance of Pace

Image
  In The Simpson's episode Homer's Enemy ,  Frank Grimes is a unlucky man who's worked hard his life but failed to reap any of the benefit.  When confronted with the inequity of his circumstances compared to Homer's he breaks down into a self destructive fit of jealousy that eventually ends his life prematurely.   The episode is a 1990s comedic expression of the general observation that life is not fair.  Several decades later, as income inequality has increased it's become a popular talking point that, "Hard work alone doesn't make you successful."  In Gen A slang a, "Try Hard" is someone like Frank Grimes who does himself discredit by giving it too much effort. For us conscientious types, this is not only counter intuitive but also elicits an emotional reaction.  Folk heroes like Rocky show us that while God may not have blessed us with any particularly useful talent, we can make up for it for it with heart.  Hercules taught us that even wi...
Read more

The Telescoping Constructor (Anti-Pattern)

Image
The Telescoping Constructor Looks like this: Widget(varA) {...} Widget(varA, varB) {...} Widget(varA, varB, varC) {...} or Widget widget = new Widget(x); widget.setVarA(...) widget.setVarB(...) widget.setVarC(...) There are both shared and specific problems for each variety.  Let's talk about both. The 1st case, supernumerary constructors. What's wrong with this? Well, the good news is you provide  quiet consumption since there's a bespoke constructor for every use case.  Rather than have noisy construction, where the consumer must fill in a bunch of nulls, you move the noise into the implementation.  We shouldn't make assumptions on how many times the class will be used, so keeping the complexity to ourselves is generous and will lead to a more maintainable macro system. However, one problem here is that the end consumer is not restricted in their choice of constructors.  Like shopping at the super ...
Read more