Challenge

My company sells subscriptions of specialized medical content to health institutions globally.  Many  of the buyers/administrators at the institutions complained that their users were not always aware of  the content they were subscribing to, so it often went unused.  This made it difficult to justify renewal  of the subscription.  The problem was also reflected in our analytics which showed heavy usage by a  very small percentage of an institution’s members and very little usage with the broader population.

We knew one option was to make the content discoverable on search engines like Google or other  platforms medical searchers used such as PubMed.  However, the technology of our current  platform prevented us from opening our site to Google’s crawlers to enable indexing of the content.   Initial estimates indicated it would be too costly to build an entirely new platform to meet this need.

Selection

We chose to use a learning launch to test.  Given the known popularity of Google amongst our  customers, we wanted to test for a solution that was within our capabilities and budget.  Since we  were uncertain Google would crawl us, and more importantly rank us well, we designed a simple,  iterative way to test our concepts while gathering data from real world users.  This would enable us  to determine our assumptions were correct (or not) and build a business case to secure additional  investment for the project.

Application

We decided to start as small as possible for our test.  Our hypothesis was: If we make a small set of  our content available on a platform that google could crawl and index, we could get one or more  users to click on it in search results.  The first iteration of this test was mostly manual with a very  simple interface.  We weren’t worrying about engagement or scale yet.  We just wanted to know if  we could get that one click.  The first iteration succeeded.  The next step was to make more content  available with a slightly more engaging interface.  We incrementally added more content and  features to the site as each step was successful.

As we began to see the success of the project, we devised a plan to scale the amount of content  and user load that would be put on the system.  We were able to make a case for this investment  since our ongoing learning had shown positive results.

Insight

The most important insight gained from this Build-Measure-Lean cycle was the cultural shift it  brought to the organization.  There was a realization that we need not make big, risky decisions, but  instead could step into a question methodically and scientifically.  The organization also realized the  importance of ensuring proper measurement tools were in place through initial launches.  In the  past, we had deferred tracking or analytics tools to subsequent releases, thinking it was more  important to get features in the market.  We realized it was more important to define the RIGHT  features rather then quickly release suboptimal features.

Approach

While the initiative was generally successful, there are a few things I would change next time.   Primarily, I would involve more people in the process, across different functions and including  executives.  As we sought to scale out as we learned, we found some in the organization challenged  our approach and findings.  They felt like they were being blindsided.  Another thing I would do

differently is to ensure that the organization knew that our initial launches were not inherently  scalable.  There was a misconception amongst some executives that we could simply “flip a switch”  to scale this out once we saw positive results from our initial tests.  This made our business case for  more investment more challenge, but not insurmountable.

