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

Guest Post: To Kill a Product: Why, When and How part 3/3

Note: This is the 3rd of a 3 part series of articles by guest blogger Chris Brown. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

Part 3: How to Kill a Product

No one wants to manage a dying product. No one wants to sell, support or, certainly, buy a dying product, either. The role of the product manager includes performing the kill analysis – thoughtful, thorough and completely unbiased – and making a recommendation that is best for the business.

Time to Pull the Plug

The process of discontinuing a product will vary greatly by industry and company, depending on the structural makeup of the organization, the sales channels, the customers and, of course, the product itself. But there are some basic steps.

First, the product manager needs to perform the analysis described in the earlier posts. Once the decision has been made to kill a product, the product manager should provide a timeline with the following action items:

Communication plan. Work with the Marketing and Sales teams to create a plan that includes customer notification, internal communication (including FAQs), collateral updating, branding consideration. Make sure the tone and level of communication are appropriate. If the product is purely ancillary, the communications may not need to be extensive. If the product has a deep connection to the brand, for example, but is no longer performing, or is being killed for strategic reasons that may not be apparent, a more carefully considered story may need to be crafted.

Shut down marketing. Any outbound or customer acquisition efforts should cease on the prescribed date.

Sales and Finance. Work with the Finance and Sales teams to make sure sales goals are properly adjusted to account for the lost revenue. Review final billing procedures, outstanding receivables, etc., with Finance.

Provide support to Customer Support. The Support team will also need to be ready to field concerns and questions from customers, partners etc. Provide the necessary training and documents (FAQs, email response templates, talk-tracks, etc.).

Provide direction to the Technology team. If the product requires any ongoing technology, e.g. it is Web-based, make sure Technology knows when to permanently suspend functionality, and that doing so will not impact any other services. Have a plan for warehousing code and/or data, if necessary.

Make sure it’s all legal. Confirm you are within the bounds of any contracts with customers and suppliers, and that official cancellation notification is vetted or provided by the Legal team.

When working on these steps with internal teams, the product manager needs to make it clear why, at a high-level, this decision has been made. Don’t assume everyone from sales to tech knows the history of the product, or that, if they do, that they don’t have an attachment to it. A summary of the criteria that led to the decision will provide context and buy-in, which is very important since many of these people will have to do much of the dirty work of killing the product.

Product managers must make their kill recommendations by thoroughly and objectively examining the financial, organizational and strategic factors. Recommending the discontinuation of a product one manages can be a difficult prospect. But often the manager, especially a good one, will be the first to admit a product has run its course. This creates an opportunity to focus on more important, rewarding initiatives.

–  Chris Brown

Chris is vice president of product management at Apartments.com, a division of Classified Ventures, LLC. Email him at cbrown@apartments.com or follow him @Brown784

Previously:

Part 1 Why?: If it’s generating some revenue, even a little, why kill an underperforming product? Because ineffective products divert focus and resources from core and growth products, and ultimately dilute the overall value proposition of the business.

Part 2 When?: When is it time to kill a product? Part 2 offers up six areas to keep an eye on for telltale signs. It’s examining these areas that will help product managers build the case to kill or keep a product.

Guest Post: To Kill a Product: Why, When and How, Part 1/3

Note: This is the 1st of a 3 part series of articles by guest blogger Chris Brown. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

To Kill a Product, part 1: Why?

It’s there somewhere, in the quarterly business review, a line item that shows a couple dozen customers, down from a year ago, which was down from the year before. It brings in a little revenue, probably less than a percentage point of total, but revenue being revenue, why not keep cashing the checks?

“It,” of course, is the Product That Wouldn’t Die, its longevity no longer due to any real practical purpose but to management’s reluctance to pull the plug. But pull the plug they should. Even if costs are negligible (and sometimes they’re not), ineffective products divert focus and resources from core and growth products, and ultimately dilute the overall value proposition of the business.

The role of the product manager includes performing the kill analysis – thoughtful, thorough and completely unbiased – and, if necessary, making a recommendation that is best for the business.

Why the hard decision might be the right decision

Why should an organization kill a product, particularly if it generates even a small amount of incremental revenue? The first reason should be obvious: The product isn’t profitable. But products that are clearly bleeding money are not what we’re really discussing here. The harder decisions have to be made for products that have some revenue, some customers, have low or justifiable costs, but no long-term plan, prospects or strategic relevance.

Here are some examples of how a moribund product can have a draining, distracting effect on an organization and its customers:

On the Product team: Product managers and analysts are required to field customer feedback, analyze market data and track KPIs for a product that most likely represents a tiny fraction of the company’s business, and takes focus off of supporting the profitable products and, more importantly, new product discovery and innovation. While the beleaguered product manager is trying to keep a past-its-prime product on life support, her competition is dreaming up the “next big thing.”

On Sales and Marketing: The sales team needs to be trained on a product that very few customers actually use. Often dying products are more complicated than they’re worth (hence, why they’re in decline) and therefore can require a disproportionate amount of time and knowledge to effectively sell and support. Marketing, in addition, needs to account for these products in their collateral and messaging, adding not only to expense, but to the clutter they’re continually tasked to cut through.

On Customer Support: The best customer support teams are fluent in all the products in your company’s portfolio, even those with a small number of customers. But customers of troubled products can often fill up a Customer Support’s team queue, generating a disproportionate number of phone and email support tickets. Meanwhile, customers of more profitable products are left on hold or waiting for their email response.

On Technology: Not only can there be hard technology costs associated with supporting a product, such as server and bandwidth expenses, but also the time required to maintain both internal and external (e.g. customer-facing) processes. After all, if a product breaks, even one with relatively few customers, someone has to fix it.

On customers: With customers there’s a risk that the poorly performing product becomes a customer’s focal point, and that its performance, presumably poor, will be used as ammunition in contract negotiations or, worse, as a proxy for all the company’s products. This can present considerable sales challenges and erode the company’s reputation.

All of these distractions have associated costs, which can be harder – though not impossible – to quantify. If a kill decision is particularly contentious, it may be necessary to put a dollar amount on these costs, which can be calculated by multiplying the number of hours spent supporting the product by the estimated hourly salary of the individuals doing the supporting.

The most important reason why ineffective products need to be killed, though, is because they dilute the company’s overall value proposition. If you can measure the total value your products deliver (and you should), perennially poor performing products will naturally drag down the sum of that equation. And with that downward pressure on value come declines in employee morale, confidence in senior management, and customer loyalty. No one wants to manage a dying product. No one wants to sell, support or, certainly, buy a dying product, either. To preserve its overall value, focus resources on core initiatives and customers, and maintain a vibrant workplace, a company should be willing and able to quickly put underperforming products to pasture.

–  Chris Brown

Chris is vice president of product management at Apartments.com, a division of Classified Ventures, LLC. Email him at cbrown@apartments.com or follow him @Brown784

Coming up in this series:

Part 2: When is it time to kill a product?
Part 2 offers up six areas to keep an eye on for telltale signs. It’s examining these areas that will help product managers build the case to kill or keep a product.

Part 3: How do you kill a product?
You’ve made the decision to pull the plug, now follow these steps to ensure a smooth sun-setting process.

Screw the Sales Process. Study the Buying Process

We spend way too much time in our companies designing, measuring, and enabling, the Sales Process.

Every time you hear those words (Sales Process), I want you to ask a question: Wouldn’t it be more useful if we talked about the Buying Process?

Does this difference – between Sales process and Buying process – sound like hair splitting?

It’s not. You can make up a Sales Process. You have to talk to actual buyers to map the Buying Process. When you do that, everything will change.

– Alan

Steve Johnson on Win/Loss, Ivan Chalif’s Digest, and Alan’s musings about the discipline of PM

Steve Johnson has probably taught 50,000 people how to do Win/Loss Analysis. Here are his views on Win/Loss Analysis. We couldn’t agree more.

Ivan Chalif at The Productologist has also posted a PM Digest for the week of August 4. Cool idea… here it is.

Ivan, thanks for including us. Steve, thanks for the plug.

I’ve been amazed recently at the growing buzz on Twitter and the growing number of PM-related blogs. For a long time I have felt that the discipline of Product Management is not improving much, despite the improvements made by indvidual Product Managers. Product Management as a discipline is still in its infancy, and still immature.

Is social media providing a light in the tunnel? I see Twitter beginning to help us all collaborate. If you are wondering what I mean, tune in to the #prodmgmt tag on Twitter.

Unconferences are also popping up all over North America (and Europe?) in much the same way that PM Associations were doing in the early 2000’s.

I wonder how we might accelerate this to collaborate on something even bigger. We (mostly Saeed) have talked in the past about the need for a PM Manifesto, akin to the Agile Manifesto. Perhaps this is a topic to pick up at the Austin Product Camp: How can we move our whole discipline forward? I might just propose a session. Tell me your thoughts.

– Alan

Upcoming ProductCamps

ProductCamp New York was last weekend and it appears to have been quite successful. Alan attended and wrote up this post about it.

If you missed the New York session and want another chance to attend one, there are 4 5 more in the works in the coming months, starting with ProductCamp Austin in only a few weeks.

ProductCamp Austin
Date: Saturday August 15, 2009
Location: The University of Texas at Austin, McCombs School of Business, Austin
More details: click here.

Followed by one in September.

ProductCamp RTP2
Date: Saturday September 26, 2009
Location: Cambria Suites, Raleigh-Durham Airport
More details. click here.

And 2 ProductCamps in October.

ProductCamp Toronto 2009
Date: Sunday October 4, 2009
Location: Ted Rogers School of Business @ Ryerson University
More details: click here.

ProductCamp Seattle
Date: Saturday October 10, 2009
Location: Amdocs, 2211 Elliott Ave, Seattle WA
More details: click here.

And to round the year off, Boston is holding their camp in November.

ProductCamp Boston
Date: November 7, 2009
Location: Microsoft New England R&D Center, Boston MA
More details: click here.

For information on these events as well as other events relevant to the Product Management, Product Marketing and Product Development communities, check out our Events page. And if you know of an event we should list, let us know in the comments of that page.

Saeed

Announcing ProductCamp Toronto 2009

The time and place for the next ProductCamp Toronto has been set.

It’s Sunday October 4, 2009 @ the Ted Rogers School of Business at Ryerson University in downtown Toronto.

This is the same location as the very successful first Product Camp in November of last year.

It’s a chance to come and meet, brainstorm, learn and network from your peers in a casual and engaging setting.

Here are some links to provide you with more information

• ProductCamp 2009 Homepage
• Pre-register for the Event (About 80 people have already done so!)
• Volunteer to help plan and hold the event (done via the pre-register process)
• Attend the planning and info pub night (July 22nd, 6PM, Fionn McCools) (map)
• Become an event sponsor (here’s who sponsored the event last year)
• Blog about it on your blog!
• Retweet it to your followers. Here’s the URL ( http://tr.im/pctor09)
• Use the #PCT2 hash tag and include @PCToronto.

We’ll keep you updated as things progress. Look forward to seeing as many of you as possible in October.

Saeed

http://barcamp.org/ProductTorontoSponsors

(How) do you measure customer satisfaction?

Dear Readers,

I will be writing an article on how to measure customer satisfaction in B2B software. To prepare for that article I would like to hear your experiences or read articles that you find useful.

If you have a useful article on the topic, or personal experience measuring customer satisfaction, I would love to hear from you. Please email me directly at customersat@eigenworks.com

Here are some focusing questions:

Do you measure customer satisfaction?

• Simple question: do you measure it?

What to measure

• what are your “leading indicators” of customer satisfaction?
• is customer satisfaction the right thing to measure? what about customer success?
• how do you measure for referenceability?
• how do you measure for customer’s liklihood of re-purchasing?

How do you take the measurements?

• Do you use quantitative measurements? If so, how do you administer these? Direct calls? Web surveys?
• What kind of response rates do you get to your web surveys? To your phone calls?
• Have you ever used an external agency? If so, which one(s)?

Have you read any good articles or books on this topic?

Thank you. I appreciate your responses.

– Alan

Tom Grant Kicks Some SaaS

Forrester’s Tom Grant has written 2 excellent pieces rebutting some rather uninformed blog posts and comments made by Rick Chapman over at SaaSUniversity.com. Many people, myself included, left comments directly against Rick’s blog post, to many of which Rick responded. But Tom wrote his posts to share his thoughts on the issue.

Tom maintains two blogs. His official Forrester Blog on Product Management, and a personal blog called The Heretech, and has posted SaaS Backwards and Making a SaaS of Yourself on The Heretech site.

A bit of background info

Rick Chapman posted this piece entitled:  SaaS Company? Thinking of Sending Your Product Managers for Formal Product Management Training and Certification? Don’t Waste Your Money on his blog.

Yes, that’s the title. Now, to be objective, the point I think Rick was trying to make was that existing Product Management training classes are best suited for more traditional packaged software companies, and there are important specifics about SaaS companies and their products that are not addressed by these classes.

Now if that truly was what Rick had argued, that wouldn’t have been too controversial. Training in general is a good thing, but not always critical.  PM Certification?…well, the value there is dubious.

But Rick very quickly started digging a hole for himself by completely misunderstanding or misrepresenting Product Management. For example, he writes:

The most important job traditionally performed by product managers is managing the tick list, that is the, the list of new features and abilities that will be added to new releases of the product (and ticked out as the latest and greatest in marketing collateral)

This statement alone shows that Rick really doesn’t understand what Product Management is.  I’ve written about this exact issue on this blog previously — Feature Prioritization doesn’t equal Product Management.

Later, Rick talks about MRDs (Market Requirements Documents) and states that they are becoming irrelevant to SaaS vendors because SaaS vendors typically have  releases many times per year. He writes:

The MRD is designed to provide a high-level business and marketing overview of a software product and tied closely to a product’s release cycle.

The issue here is that Rick (erroneously) assumes that MRDs are documents that must be tied to releases. The reality is that MRDs are tied to business cycles and market dynamics. If a company’s release cycle is long (i.e. 1 year or more) then there might be a relationship between the release and the MRD. But simply because an application has a short release cycle (several times per year), it doesn’t remove the need for an MRD (or equivalent business analysis document) on an annual or as needed basis, depending on market changes, business issues etc.

Rick also touted a SaaS company that manages approx. 100,000 feature requests “with no Product Managers”, as if this is a model to follow or that managing enormous lists of inbound feature requests is the only responsibility of PMs.

Anyway, you get the point here of the kinds of flaws in Rick Chapman’s understanding of Product Management.

So go read Tom’s posts — Making a SaaS of Yourself and Saas Backwards — and read Rick’s original article as well and let me know what you think.

Saeed

Who’s in charge of price? (Hint: It’s the person who speaks with the buyer.)

Eigenworks is shopping for a product. Over the last few months I’ve been looking to license some software from a vendor. The price is not astronomical, but it’s a significant chunk for a company of our size. If we license the product, the vendor will get a share of any profit we earn from the use of their product.

Over the last couple of weeks I was talking with the sales person about this purchase, and his responses made me wonder, again, just whose team is he on?

The Buyer Conversation

Buyer: “How much is your product?”

Seller: “$10,000 plus $1500 in maintenance and support, then we take 20% of your net profit. But if you really want to buy, I can get the up-front cost down for you substantially.”

So right there: He’s started discounting! The CFO’s ears are burning already.

Buyer: “Well that would be great because $10,000 up front is too much for me to spend. What can you do for me?”

Seller: “I could cut that in half.”

Buyer takes note: He cut the price in half before I even flinched at the price.

Yes, dear reader, I had this actual conversation with an actual sales person working for an actual software company, in the last few weeks.

Is this your pricing strategy?

Now perhaps, just maybe, possibly, the VP Sales, PM, and CFO have gotten together and decided that the street price will really be $4,000, or even less, but if they start with a $10k price and just discount the heck out of it, the buyer will feel superior for having negotiated such a discount. This is a possibility, and I could even go along with this strategy under some very specific conditions.

For example, perhaps we are seeding the market and we decide to give the product away for $1 for the first 3 months, but retain the $10k price to project value and protect the renewal fee. Yes, I could certainly support that strategy, again, under certain assumptions and with certain market conditions.

But I don’t think this is a coordinated strategy. This sales person is acting alone, perhaps even with the help of his sales manager. I can just hear the dialog in the sales meeting:

Seller: “People just won’t pay $10k for this product. I don’t even think I can get $5k for it. I think we should give it away for free.”

Manager: “I know, I know. I’ll take this back to the product manager and the CEO. See if you can get $5k, but don’t go lower than three grand.”

The rest of the conversation convinced me that this sales person is acting alone.

Buyer: “This pricing doesn’t make sense. You should give me this software and the royalties will more than make up for it.”

Seller: “I know Alan. I’ve been telling these guys the same thing for months now. No one will pay for this product. I haven’t sold one copy!”

Buyer takes note: Sales person wants to give this to me for free.

During the rest of the conversation, the seller told me that his company doesn’t really understand this new market that they are in. They are taking a product from a different market and porting it to this new market, and they just don’t get it. The economy has made the company look to go after short-term revenue rather than thinking about the big picture, he says.

I could continue, but the point is this: This seller is not happy with his company, and he’s hurting the company’s reputation, and revenue stream, with every word he speaks.

How do we monitor selling and buying conversations? How do we really know what is being said to our customers? The sad truth is that we really don’t know; in most cases, especially in B2B sales, we just don’t know. I’d like to have a tap on the line and a notice that says “this call will be recorded and monitored for discount prevention purposes.”

The price is set in the buying conversation

This is a caution to product organizations: when you hear reps complaining about price internally, they might be secretly eroding your street price by disclosing too much to your customers. They may be right, or they may be wrong, but regardless, the decision is not really theirs to make.

How can we fix this?

There are ways of measuring whether this is happening or not. Unfortunately it is not an easy task. You need to spend time speaking with buyers, and gain their trust so that they will open up to you. You need to talk with them about the buying process, not their final decision. What alternatives did they have, and what would they have done if discounts were not offered? Do they have ways of measuring cost/benefit of a purchase, and did the sales person help them do this? Who controls the purse strings? (Hint: It’s not usually your evaluator.) Was the business case presented to the person signing the check?

If you don’t learn the answers to these questions, your sales people will set your prices for you.

Alan