Real Time Web Analytics

Marketing JUnit Max

My recent post on deadpooling JUnit Max generated several interesting comments. One thread that I found particularly thought-provoking was started by a comment from Andrew Binstock that I hadn’t really done any marketing or PR for Max. His comment was seconded by several others who were potential subscribers who only learned of Max on its demise.

On a few day’s reflection, I see the situation differently. I did market Max, just not in the same way that is appropriate for more mature products. Just as there are different engineering principles and practices for products at different stages, there are different marketing principles and practices. I’ll try to describe the differences & why I see my marketing of Max as successful.

Getting off the ground

I’m afraid this post is going to be analogy rich. One analogy is the flight of the startup, that startups go through distinct phases:

  • Taxi–identify a need
  • Takeoff–generate capital
  • Climb–achieve scale
  • Cruise–extract profit

Max got safely through the taxi phase: programmers relying on tests genuinely need better and faster feedback. It was the takeoff phase that I wasn’t able to get Max through.

In the takeoff phase you need to identify whether people will actually pay to have their (validated) need met. You need to find out how large the total market is. You need to begin selling enough to that market to generate capital to carry the product through to the next phase, either by bootstrapping or by attracting venture capital.

Prospecting

Here is the next analogy–marketing as mining. If marketing during climb and cruise is like strip-mining, extracting every last ounce of value, marketing during takeoff is more like prospecting. You drill a few holes and see what comes up (hence the opening picture). Is there revenue? How large is the total potential revenue? These are questions that can often be efficiently answered with certainty by actually marketing and selling.

If your first few holes don’t find any sales you haven’t proven there aren’t any sales, just that there aren’t any where you’ve drilled. My marketing campaign for Max was aimed at finding the size of the market. I used this blog, Twitter, and a mailing list to invite potential users into the “story of JUnit Max”. I wanted to see how far the product would spread. It isn’t until you get past the end of effective marketing that you actually know where the edges are.

Bonfires

One final analogy–product as bonfire. A product that solves the right problem for the right people at the right time is like touching a match to one twig in a really dry pile of brush. After that first touch you really don’t have much to do until it’s time to pile on more brush. Each burning piece sets off several around it.

At first Max looked like this. Friends told friends. Single sales turned into sales to whole teams. At one point a logarithmic graph of sales showed Max going cash-flow positive by August (of course, the same graph showed Max exceeding the entirely global economy in December 2010). Then the second derivative of sales went negative. Then the first derivative. No features I added or marketing activity I took had any effect.

That’s when I concluded that I had found the edges of the market. It wasn’t that I had “consumed” all the fuel, made every possible sale. Marketing and sales don’t work like that. They are necessarily stochastic. Perhaps I could have sold five times as many subscriptions by dint of hard work. By porting to other platforms like IntelliJ I could have doubled sales yet again. None of that added up to the 100x or 1000x I needed to sustain a business, though.

Marketing in Context

One of the emerging concepts in lean startups is separating the product launch from the marketing launch. Here are takes on this concept by Sean Ellis and Eric Ries. You don’t know how your product is going to be most valuable. You don’t know when your product is going to be most valuable. You don’t know to whom your product is going to be most valuable. A single launch compounds all your risks. As Cuil and Wolfram Alpha have showed most recently, even pretty good technology can’t survive a big-bang launch that doesn’t go just right. Risk management suggests staging the roll out to find answers to “how, when, and who” until the market practically demands a big launch.

Mass marketing, press releases to the mass media for example, is aimed at filling the sales pipeline. This is fine if you have a profitable product. However, Max was never profitable. Each user cost me more in support costs than I received. Max was valuable to an experienced user, but deploying it to a large audience of less dedicated testing programmers would have been ruinously expensive to me and disappointing to them.

Reflection (or rationalization)

Looking back I’m satisfied with my marketing of Max. I quickly and cheaply figured out the size of the paying market, the effects of pricing on sales, and made a small dribble of money in the process. I found that out without having the pay all the costs of engineering a completely reliable, performant Eclipse application.

In future I will use Twitter again to tell the story of development, with its ups and downs. I will use my blog to give more detailed and generally applicable lessons along the way. I will use a mailing list for product-specific discussions. All of these activities promote the product at hand, and, should it not go well, enhance any future products.

When I get to a product that is really catching fire, that’s when Andrew Binstock’s advice will come in handy. When the cost per customer has been driven down, when the benefit per customer has been driven up, when the potential market is large enough to sustain a business, that’s when pouring on kerosene makes sense. Do it too soon, though, and you just have a bunch of half-burned wood and no fire.

11 Comments

Jeff McKennaJuly 20th, 2009 at 12:03 pm

Ah, yes. I know this story well. LOL from sharing your pain. And a testing product at that!
J

KentBeckJuly 20th, 2009 at 12:34 pm

At least you had the good sense to sell a product that testers might use, too.

Andrew BinstockJuly 20th, 2009 at 5:39 pm

I am not sure I agree, but I appreciate your thoughtful response. I hope this experience will not dissuade you from developing other tools in the future.

Ian SkerrettJuly 21st, 2009 at 5:16 am

Seems to me you are using the term ‘marketing’ when you really mean ‘market sizing’. You seem to have defined your addressable market as the people who follow your blog, twitter id and/or mailing list. This might be a limiting factor that effected your sales.

IMHO, any new product requires a LOT of patience and time before people start to accept it, talk about it and buy it. Behind every overnight sensation is a lot of hard work and time. Bonfires may happen but they never last long unless you keep feeding them…

KentBeckJuly 21st, 2009 at 5:48 am

Ian,

I agree that marketing for early-stage products is different than for more mature products. The goal in both cases is creating demand. In the early stages marketing creates demand for the purposes of generating seed capital and sizing the market. Too much demand, or demand from the wrong kind of customers, is as damaging to a product as too little. In later stages marketing creates demand in existing markets or opens a product to new markets.

The conundrum I faced was how to market without any cash. I do have my reputation–people will (briefly) listen to what I say. That’s why I used the media I used. Actually, if I had to do it over again I would attach my name less prominently to the product. Some people bought Max because it was a tool I produced, not because it was a tool they really thought they needed, and that delayed clear feedback. The signal that clinched the decision to deadpool Max was the lack of word-of-mouth. Subscribers were telling their friends, but their friends weren’t buying.

Regarding patience, I’ve seen products take a long time before they took off. As a penurious bootstrap startup, I don’t have time for that. I can’t afford the opportunity cost. Because Eclipse is so expensive to develop for, I couldn’t just let Max simmer. I needed several months of engineering to make Max solid and performant. Without early revenue to pay for that, I needed to move on.

KentBeckJuly 21st, 2009 at 5:55 am

Andrew,

I would like to hear more about how our perspectives differ. I do plan on developing tools in the future. I don’t like the uncertainty of product development, but it seems to offer me the best chance of being able to program for a living and live somewhere beautiful. Two lessons: sell to companies instead of individuals & include a service component from day 1.

Leif JantzenAugust 11th, 2009 at 1:08 pm

Kent, did you consider the Freemium model (http://en.wikipedia.org/wiki/Freemium) for Max, and if yes, why did you dismiss it?

In my opinion Max is sufficiently different from JUnit to require “user education” and community acceptance, just as JUnit did some moons ago. A free (beer) or open source entry level implementation would in my opinion build a user base and extend mindshare, paving the way for an advanced for-pay “enterprise” version. Or am I wrong?

KentBeckAugust 11th, 2009 at 2:02 pm

Leif,

Thanks for the thoughts. I did consider the freemium model. A freemium business needs to offer:
1) Value “for free” (that is, in exchange for users investing time but not money)
2) A “conversion moment”, where the obviously right thing to do is pay for even more value. The “15 SMS messages a day free” iPhone apps are like that. You’ve already sent 15 messages that day. You really want to send the 16th. $9.99? No problem.

#1 was easy. Around half of the people who tried Max really liked it (modulo scaling to large workspaces, which could have been solved with more engineering). #2, however, I never really figured out. What would be a good dividing line–# test runs/day? #tests/day? #tests total ever? I never found a “conversion moment” that was convincing to me.

Dividing “personal” and “enterprise” makes good sense. Again, though, I never figured out what the “enterprise” edition would include that would motivate a manager to buy it in his own self-interest.

Underpinning all of this is my suspicion that not that many Java programmers rely on tests for feedback minute-by-minute. Some, yes, but not a market’s worth.

spencerOctober 30th, 2009 at 1:47 pm

Kent,
You said the support costs for your product were too high, and it sounds like you were giving support away for free.
Now, I’m not sure what your product does exactly, but, if you were getting lots of feedback in the support channel, does that suggest that you could sell training/coaching/consulting? Could you have used this product to generate consulting business? My guess is that there are many companies out there that would like better testing tools and more testing knowledge. You said that experienced testers were fine with the product, but less experienced customers needed a lot of help. I just thought that you might be able to capitalize on that. Free product/Pay support is another revenue path for open source tools.

spencerOctober 30th, 2009 at 2:03 pm

Kent,
have you considered open-sourcing this work so it doesn’t die? I understand that you want to get paid, you can’t live other wise. Still would opening this product give you further acclaim increasing freelance programming/consulting opportunities?

KentBeckNovember 1st, 2009 at 7:40 am

Spencer,

Thanks for the idea. I have considered open source JUnit Max. However, it would require significant investment on my part (perhaps a month of work before it is ready to be shared) and significant on-going investment (open source projects need to be nurtured to live), all with no conceivable monetary payoff. It doesn’t make sense. It’s a pity that the code will die, but I hope that ideas of test prioritization and in-place feedback will be taken up by other IDE developers.

Leave a comment

Your comment