Mind Mapping – Idea Generation Process

Challenge & Selection

The tool I used was the Idea Generation process along with the Mind Mapping Tool to  understand how to grow our business.  This process fit nicely into an ongoing evaluation of our  products and services.  We are a technology services (consulting) and software company  focused on the banking markets (trading) and other market participants.  We sell a specialized  type of database used to support the most complex analytical requirements in the trading  industry and sell consulting services to build and maintain the software associated with the  database.      The Database ships with a proprietary development language that was very powerful but  difficult to learn and more difficult to staff.  There is a small die-hard community (devotees &  builders) that work with the technology daily.  These technology enthusiasts can be fickle and  difficult to work with; this is in contrast to the database query language SQL which is used by  probably millions of people daily. Consequently, most major banks have built their own  proprietary ecosystems around our database with the difficultly residing in maintaining a team  with very niche, very expensive and specialized skills.      The message more and more had become from our clients that they loved the results that our  technology produced but they deeply disliked the making of the results, i.e. having to maintain  an extremely specialized expensive team of resources, among other things. Our challenge was  to keep these clients happy while trying to drive adoption more broadly in the trading  community and into new business verticals.    Application    After meeting with many of our clients over a couple of months we gathered feedback and tried  to put messages, themes and ideas into different buckets to observe the feedback.  The first  message we received loud and clear was the need for some kind of interoperability with  Python.  Although our proprietary language was dramatically more powerful, recent grads and  a large globally community had essentially said Python was the de-facto analytical language.   The reality was we could somehow try to convince a global community to learn our language or  we could build interoperability with Python instantly making our product accessible to millions  of people in many industries.  This may seem like a no brainer, but it is complicated. Reaching a  global community would take some doing, but it was an achievable goal.    The second theme that arose was the “care and feeding” of these implementations.  Banks  were tired of building and maintain technology ecosystems; they wanted something off the  shelf.  We had developed some internal development frameworks and written some engines  (software code) that could be packaged together and productized.  With a little effort we could  productize these internal frameworks and have clients either start their relationships with our  technology or our larger clients could migrate to these frameworks.

These ideas we needed to flesh out from ideas to possible offerings.  For the easy fix (which not  what we were long for) to the paradigm shift in how we make money.  To answer some of  these questions we asked a small subsection of our own community to consultants who were  expert in our own technology and could also provide insight into what they saw day to day at  the clients (it’s amazing what a client will tell you in the conference room and what an onsite  consultant can observe).    We also approached our Core technical team to evaluate the feasibility of interoperability  would be and to capture pluses and minuses to make this technology interoperability happen.    Insight    These were some really big ideas at the firm.  For years technologists on Wall Street would  learn this exotic development language and deliver amazing insights into the markets.  There  was a high degree of “pride of ownership” and for years our firm had been content with making  money selling consulting.  If we could enable essentially anyone with a passing knowledge of  Python to yield similar results as our die-hard specialists, what would happen to the  community?    We wrestled with this question. What made our technology special was its unique power.  If  interoperability with Python resulted in an offering that was diminished, then our technology  would no longer be special and therefore there would be no reason to use our technology.     The second idea, to offer a Product that was powered by our database and analogous to what  our community built and supported (essentially competing with their livelihood) was another  risk- but a risk we needed to take.      Approach    In the future, I would have brought in clients to our offices to both hear what was both good  and bad about our technology but I would also have them brainstorm tools and ideas to see  what insights they would bring.  This done well could yield interesting results, done poorly and  it could devolve into a rudderless affair.


Mind Mapping – Idea Generation Process Challenge & Selection The tool I used was the Idea Generation process along with the Mind Mapping Tool to understand how to grow our business . This process fit nicely into an ongoing evaluation of our products and services . We are a technology services ( consulting ) and software company focused on the banking markets ( trading ) and other market participants . We sell a specialized type of database used to support the most complex analytical requirements in the trading industry and sell consulting services to build and maintain the software associated with the database . The Database ships with a proprietary development language that was very powerful but difficult to learn and more difficult to staff . There is a small die - hard community ( devotees & builders ) that work with the technology daily . These technology enthusiasts can be fickle and difficult to work with ; this is in contrast to the database query language SQL which is used by probably millions of people daily . Consequently , most major banks have built their own proprietary ecosystems around our database with the difficultly residing in maintaining a team with very niche , very expensive and specialized skills . The message more and more had become from our clients that they loved the results that our technology produced but they deeply disliked the making of the results , i.e. having to maintain an extremely specialized expensive team of resources , among other things . Our challenge was to keep these clients happy while trying to drive adoption more broadly in the trading community and into new business verticals . Application After meeting with many of our clients over a couple of months we gathered feedback and tried to put messages , themes and ideas into different buckets to observe the feedback . The first message we received loud and clear was the need for some kind of interoperability with Python . Although our proprietary language was dramatically more powerful , recent grads and a large globally community had essentially said Python was the de - facto analytical language . The reality was we could somehow try to convince a global community to learn our language or we could build interoperability with Python instantly making our product accessible to millions of people in many industries . This may seem like a no brainer , but it is complicated . Reaching a global community would take some doing , but it was an achievable goal . The second theme that arose was the “ care and feeding ” of these implementations . Banks were tired of building and maintain technology ecosystems ; they wanted something off the shelf . We had developed some internal development frameworks and written some engines ( software code ) that could be packaged together and productized . With a little effort we could productize these internal frameworks and have clients either start their relationships with our technology or our larger clients could migrate to these frameworks . These ideas we needed to flesh out from ideas to possible offerings . For the easy fix ( which not what we were long for ) to the paradigm shift in how we make money . To answer some of these questions we asked a small subsection of our own community to consultants who were expert in our own technology and could also provide insight into what they saw day to day at the clients ( it ’s amazing what a client will tell you in the conference room and what an onsite consultant can observe ) . We also approached our Core technical team to evaluate the feasibility of interoperability would be and to capture pluses and minuses to make this technology interoperability happen . Insight These were some really big ideas at the firm . For years technologists on Wall Street would learn this exotic development language and deliver amazing insights into the markets . There was a high degree of “ pride of ownership ” and for years our firm had been content with making money selling consulting . If we could enable essentially anyone with a passing knowledge of Python to yield similar results as our die - hard specialists , what would happen to the community ? We wrestled with this question . What made our technology special was its unique power . If interoperability with Python resulted in an offering that was diminished , then our technology would no longer be special and therefore there would be no reason to use our technology . The second idea , to offer a Product that was powered by our database and analogous to what our community built and supported ( essentially competing with their livelihood ) was another risk- but a risk we needed to take . Approach In the future , I would have brought in clients to our offices to both hear what was both good and bad about our technology but I would also have them brainstorm tools and ideas to see what insights they would bring . This done well could yield interesting results , done poorly and it could devolve into a rudderless affair .