The first stand-alone, eLearning software product that Industrial Logic produced in 2004 was a commercial failure that taught me some valuable lessons about being an entrepreneur and programmer.

The product was Refactoring to Patterns Interactive (RTPI), an eLearning class based on my best-selling book.

At the time, Industrial Logic made nearly 100% of its income from coaching and training in Extreme Programming.

We hoped to change that by producing a software product.

In hindsight, wanting to “produce a software product” isn’t the same as solving an important customer need. We would soon learn that…

Our busy schedules left us with small, precious pockets of time to develop a product.

We began development of RTPI in mid-2004.

Early on, I had some doubts about how well it would sell compared with my book.

Those doubts led me to focus mainly on the content of RTPI and much less so on the delivery mechanism (the code that served up the content).

Craftsmanship Friction

My focus on RTPI’s content, rather than its code, caused friction with my colleagues.

Being experienced and passionate extreme programmers and coaches, my colleagues wanted to produce an excellent, simple design via merciless refactoring.

I understood their impulse well, yet my misgivings about whether RTPI would be profitable caused me to think differently about our investment in it.

One day I came back from a few days of client work and found that almost no progress had been made on the iteration stories.

Instead, my fellow developers had spent 2-3 days learning and applying a newer, better way to interact with the object-oriented String Template Library we were using.

I expressed my unhappiness at this misuse of our precious product development time.

My colleagues protested that the new technique was better and was well worth the time.

We agreed to disagree and I reiterated that the content from RTPI was our real focus, while the delivery mechanism was secondary.

My colleagues yearned to be crafting code yet those yearnings were misaligned with our product development needs.

Failing Slowly

Having spent nearly 4 years writing a book part-time, I was used to toiling away at content in order to improve its quality.

I took that same work ethic and brought it to our fledgling product development.

While I could see the wisdom in not crafting an amazing software design given little evidence of decent ROI for RTPI, I blindly worked on crafting high quality content, assuming that it was critical to product success.

The big question we faced at the time was “How many patterns must we feature in RTPI in order for it to be successful?”

We decided to deliver many patterns, since we felt that more content would equal more product acceptance and commercial success.

That meant we moved slowly, since it took months to craft so much quality content.

We released RTPI in November, 2004.

One large corporation placed a 60K order and after that, we experienced some modest sales. (It is always hard for us to quantify sales, since we used products like RTPI in our in-person training classes. For this blog, I am focused on sales of the stand-alone, eLearning product, not sales gained from using the product in our in-person training classes).

Public feedback led us to demonstrate RTPI via a screencast.

Next, we began making screencasts that showed how we ourselves solved the refactoring to patterns exercises.

Those screencasts were a big hit within our small pool of customers.

We gradually added a C# edition of RTPI and again saw modest sales and usage in our in-person training workshops.

By late 2005, it was clear that the subject of refactoring to patterns was too advanced for most programmers who were starting their journey to Agile development.

It was then that my colleagues and I declared RTPI to be a commercial failure and extracted its valuable parts (including some code, automated tests and content) for use in our new next-generation eLearning product.

Lessons Learned from RTPI

Lessons Learned from RTPI

RTPI taught me that most folks needed basic training in Agile practices, not training in advanced subjects like refactoring to patterns.

It taught me that our customers loved our screencasts more than anything else we had produced.

It taught me that few students got through all of our content, and that lesson taught me that we needed less content and better engagement of our audience.

Above all, RTPI taught me to move quickly, to fail faster and learn faster, rather than guessing and moving slowly.

By the time Industrial Logic began our next-generation eLearning, called Greatest Hits, I had a far better understanding of our customers and solid evidence that there was a market for eLearning focused on teaching the basics of Agile development.

RTPI was an experiment, whereas Greatest Hits would be a product.

Given that knowledge, we deliberately invested in high-quality code for Greatest Hits.

We also focused on producing smaller quantities of high-quality content and getting fast feedback from real customers.

Finally, we did a good deal of usability testing to learn what engaged students.

Greatest Hits has gone on to be a commercial success.

Experimenting Vs. Productizing

Sufficient Design suggests that we adjust our work style based on context.

Experimenting on a product/feature requires a different working style than productizing that product/feature.

As an experiment, our work on RTPI needed to minimize costs and accelerate learning.

Crafting high quality code and large amounts of quality content for RTPI was at odds with the goal of accelerated learning.

Finely crafted code and content was essential to Greatest Hits as we strongly believed it would have a long shelf-life and become a core part of our business.

But that doesn’t mean that every line of our Greatest Hits code was mercilessly designed.

Within Greatest Hits, we perform experiments, like our playlist feature.

We make sure to value speed-of-delivery over elegant design for Greatest Hits experiments.

If/when we decide to fully productize those experiments, we craft them and get more and more merciless in our craftsmanship based on solid evidence of ROI.

Thus, our development style changes based on our context.

When designing commercial software, pay attention to whether you are experimenting or productizing and adjust your style accordingly.