Category Archives: Enterprise Software

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

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

kambNo 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.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

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

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

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

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

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

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

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

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

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

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

Saeed