Category Archives: Wily Technology

Disruptive business model: Lew Cirne, serial entrepreneur on the future of Enterprise Software

Lewis Cirne (@sweetlew) believes that enterprise software needs to change, and his latest venture, New Relic, has blazed a path to do just that.

DOWNLOAD AND LISTEN to the interview with Lewis Cirne.

Lew’s first company, Wily Technology, was a classic garage-based tech startup (actually started in his living room in Santa Cruz) that grew from one person to 300+ people before being acquired by CA in 2006 for $375M. (Full disclosure: I worked for Wily as director of strategy from 2003 through the exit.)

After a year with CA and some time off to reflect, Lew started again, solving a similar business problem, but with a mission to hack out the massive cost of sales associated with most enterprise software.  Lew points his team to the craftsmanship of the iPhone, and the friction-free design of Facebook and Twitter as models for New Relic’s enterprise offering, and in fact his lead investor is Peter Fenton of Benchmark Capital who also led a huge round for Twitter in 2009.

New Relic is now 2 years old and has over 4,200 customers*. Lew tells us that this approach eliminates as much as 80% of the delivery costs, and takes months out of the innovation cycle. Is the model sustainable? What kind of exits are available to SaaS-based enterprise software companies? What does this model mean to the future of enterprise software?

Check out Lew’s answers in this episode of Take 5: our conversation on leadership, technology, and product management.

DOWNLOAD AND LISTEN to the full interview with Lewis Cirne.

* Errata: The audio uses the number of 40,000 websites; this was my error. Lew wrote me to clear this up: “We collect data on more than 40,000 JVM’s or Ruby Instances every minute, which does not correlate 1:1 with applications. (Many apps aggregate across multiple JVM’s or Ruby runtimes.) I use the 40,000 number to talk about the scale of the data we collect, rather than the size of our customer base. I don’t have up-to-date numbers on the number of actual apps we collect data on, but I would imagine that it’s over 5,000 since we have nearly 4200 production customers now and some of them have multiple apps (some have dozens in a single account). Anyway, just want to be sure we’re not over-representing ourselves.)”
Thanks Lew! Alan

Advertisements

Primary product requirements

Some products seem to fail at their primary requirements. What is the primary requirement of your product? Here are a couple of examples from everyday life. I hope these examples help you reflect on the primary use case of your product and how well it delivers.Which one is the salt spreader?

Example 1: Salt Spreader

This past Sunday I arrived at church and found the parking lot to be one big sheet of ice. It was worse than a skating rink because the temperature was above freezing, so the ice was thick but melting and thus wet. Some cars were sliding around with no traction whatsoever. Worried about the others arriving, I quickly found the salt spreader, pictured here alongside the tool that I ultimately used to spread the salt. You see, the salt spreader (blue) works very well when you have traction; when you push the spreader, salt falls through a hole in the bottom of the basin and a spinning disk throws the salt horizontally and very effectively distributes the salt across a wide area. The trouble is that when the spreader is on ice, the spreader simply slides along the ice, the wheels don’t have traction, don’t turn, and therefore the spreading disc doesn’t turn. This renders the tool completely ineffective. I believe I could spread salt on a surface of dry pavement, and no doubt it would work to spread grass seed on soil. But that’s not the primary use case! Normally when you’re spreading salt, you’re spreading it on a sheet of ice.

Faced with this deficiency, I pulled out the large snow shovel, filled it with salt, poured concentrated salt on the ice, and then went back with a push broom and spread the salt.

The snow shovel became my salt spreader, and the spreader sat idle, no doubt completely ashamed of itself and resentful of the designers who failed to take into account the most common use case.

Can’t you just picture the design requirements?

  1. Spreader must carry two full bags of salt.
  2. Spreader must throw salt to a radius of 10 feet when pushed.
  3. Spreader must allow user to select salt concentration. (There is an adjustment to control the size of the opening in the basin through which the salt falls.)
  4. etc …

Provided with these requirements, the engineers noticed that they had a grass seed spreader that could be easily modified to spread salt rather than seed. The hole and spreader geometry were adjusted to handle salt, and voilá, the product is ready to ship!

All of the requirments for this spreader could be stated in a single use case or problem statement:

  1. Spreader must allow user to distribute salt at a 10 feet radius while the user pushes the spreader across a sheer ice surface.

Example 2: My sock drawer

(These are not mine!)

How many unmatched socks do you have in your drawer? It absolutely mystifies me how this happens, but I have 25-30 single socks with no apparent matches. Somehow they disappear, and even when they don’t, I have arrays of similar-but-not-quite-matching socks, one array for each color; blue, black, beige, etc.

I don’t think I’m alone. In fact a search for “Lonely Socks Club” reveals that many people have written about the plight of the single sock that has lost its match. About 10 years ago a Canadian radio program had a feature where listeners could send in their unmatchable socks, and the radio host would diligently look through all the socks to match them up, and when matching socks were found, he would call the sock senders to piece together how these socks might have been separated. This segment was so popular that within a short time the radio station had to implore its listeners to stop sending the socks on threat of burning all socks. They ran a contest to determine what to do with the pile of socks, and the winning entrant proposed to mould the socks together into a couch!

All that to say that the lonely sock problem is pervasive.

So if you’re selling socks, what is your primary requirement, use case, or problem statement? Of course, socks need to be comfortable, withstand dozens of wearings without losing their ability to hug the calfs. But that ability is not a differentiator; it sounds like table stakes.

Color and fabric might be good buying features too, but all sock vendors have a variety of these.

For me, the primary requirement of socks is the ability to easily find its mate after the laundry is done!

Easy to match!

I realizePlain but still easy to matchd this when I bought the beauties on the left a few years ago. In the picture you can tell that I’ve nearly worn them out, probably because I like them so much. In all visible areas, they are plain black. But the toes, heels, and cuffs, are a distinctive color. I like to think of the color as my little secret under my shoes.

And if you don’t like that idea, on the right are some socks with a distinctive logo on the upper calf. Despite being plain black socks, I can always match these ones up without looking closely at the fabric.

So if you’re designing socks, here is your primary use case, after you talk about the “ilities” which in sock-land I suppose are wearability, breathability, and so on.

  1. User does laundry for 1, 2, or 5 people, producing a pile of socks. User wants to quickly match socks with identical matches without mistakes.
  2. User opens unsorted sock drawer in the morning, before putting on glasses, and before his morning coffee. The room is dark and he can’t turn on the light because someone else is sleeping in the room. User must be able to quickly find two socks that match. Bonus points for being able to identify whether the sock is blue, black, or some other dark shade, without benefit of good lighting.

When I shop for socks, I keep looking for socks that advertise themselves using the above use cases. I think socks with those features would outsell the competition, with little or no increase in manufacturing cost. Furthermore, the price sensitivity would also decrease, because I care more about matching socks in the fuzzy dark morning than I do about an extra buck for the pair of socks.

Does any of this matter for your product? Short answer: Yes.

When I was at Wily Technology (now part of CA), our systems management product had three fundamental capabilities that no competitor could match:

  1. Product worked in a production Java EE environment with near-zero impact on the running system.
  2. Never take the managed application down.
  3. Provide useful data immediately.

The early user interface was not as good as many competing products, and competitors had many other advantages. But these basics enabled our core buying use case:

  1. User has high-volume, high-value applications that exhibit problems only under real-world situations, and frequently only after hours or days of successful execution. The user must be able to monitor the running application in real time, under real-world production applications, and when problems occur, get diagnostic information quickly and easily. The problem may never be reproduced.

The company moved on to sell proactive monitoring and management, and this of course is necessary. (Monitoring commands a far higher price point and buyer profile than diagnostics.) But in the early days, and in fact for several years, Wily was the only player in the market that could satisfy the drop-dead diagnostic use case above. With that solved, buyers would spend big bucks to ensure they continued to have this ability.

In other companies that I wish I could name, I’ve seen products where we could do myriad impressive things, but we simply didn’t solve the primary problem, or enable the primary use-case of our buyers. That was, um, a much more difficult sale.

The trick is that you need to know what those problems and use cases are. Stacey at Pragmatic Marketing (channeled by Steve) wrote a great article about this point. Your job is NOT to gather requirements, but rather to observe them. The examples above show this clearly. If you talk to sock wearers (shouldn’t be hard to find a few), you’ll almost never get the differentiating use case that I suggest above! They’ll tell you about color, how the sock hugs the calf, stays up, but allows for circulation. I doubt you’ll have many sock-wearers tell you about the sorting problem.

What is your prospect’s primary use case or problem statement? Are you enabling the use case or solving that problem? Share your experience with us!

– Alan

PS: Win/Loss Analysis is a great way to start figuring out the primary use case of your buyers! Many of our readers complain that they are not allowed to do win/loss, or are simply too busy. If that’s your situation, here are some strategies that might help:

If only we had …

This is personal.

When you think back over your life, how many product ideas have slipped through your fingers? For me the number isn’t huge, but it’s not small either. Any one of those ideas could have been a huge success. In 2003, I remember starting a business plan about a product that would suggest new music to me based on things that I like, and better yet, things that others like me, like. Earlier this week, Apple introduced Genius, which is really a Genius, but it’s very similar to the idea I was toying with 5 years ago. My idea was focused on independent bands, and of course I would have struggled to get critical mass, which Apple has out of the gate.

And that’s just one of them. There are probably between 5 and 10 other really good ones.

I’m not bitter exactly. I know why I didn’t go for it. I was offered a great job, for which I moved to California, and I’m glad I did. The experience was awesome, and there was some great upside when Wily was acquired in 2006. I wouldn’t trade the experience living in the bay area.

And neither can I be certain that any of my ideas – especially my execution of the ideas – would have been successful.

But. But. But. I didn’t go for it. At the end of my life, am I going to look back and be glad I was safe? I know, I’ll be thinking about my kids, and their kids, and so on, but I’ll also be thinking about my career. And I think I’ll be disappointed if I hadn’t gone for it … at least once. Maybe more than once.

So right now I am stepping out. We’ll soon be launching some new consulting offerings from Eigen Partners. And we hope to develop products too. It won’t be easy, and it’ll be scary, and all that … but at least we’re going for it.

What about you? What’s holding you back? Share some of the product ideas you’ve had that could have been somthing, if you had gone for it. OR, better yet, if you went for it, how’s it going? Or how did it go?

Alan

Here’s the deal with Biz Dev (Part I)

Saeed has posted two fairly provocative items about business development. (Here are the first and the second.) Frankly, Saeed, you’re not following your own advice. To paraphrase you, “Enough with the missives about Biz Dev”.

If you’re getting annoyed by what’s going on in your company, then you have two choices — help fix it, or move on. There are a couple of other choices actually, such as do nothing, or complain about it on your blog, but to be honest, if that’s what you do, then you’re not as great a product manager as you think you are.

hmm.

Certainly it’s easy to poke a stick at biz dev, and I could tell a few stories of my own. Several years ago, Intel was courting my CEO to have us port my product line to the Itanium chip, and thankfully I got to meet the Intel guy with my CEO for espresso at the old Starbucks by Moscone before we committed to anything. We were interested seeing what Intel might offer us, and my CEO really wanted to ink a deal with them. As Saeed said, it was “strategic”, and the Intel logo would look really great on our investor slide deck, or so our CEO felt. As is well known, the Itanium chip was a failure. Thankfully we didn’t invest.

In fact when we poked at Intel’s proposal, we found that the market for our product on Itanium would have been tiny; it would have been a tool to help people writing apps directly to the Intel metal, a specious group who wasn’t likely to increase our revenue. I suggested that Intel could pay a very large sum for our source code with an exclusive license on its doomed chip, but Intel didn’t bite. At that point our CEO saw that the logo on the Powerpoint slide wasn’t worth the distraction.

But I have also seen business development add major value to a company. When I was at Wily Technology, I saw how business development could be used strategically to strap a rocket to the company and create the engine for the company’s phenomenal growth. (And it was phenomenal. Eventually we were acquired for $375M, greatly exceeding the multiples of our peer group.)
What’s the difference between Saeed’s experience with BD and the Wily success story? It boils down to strategy, alignment, and value creation.

I’ll elaborate in future posts on this topic, so please stay tuned.