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

Product Management Metrics (part 2a)

My  conference call on PM Metrics with Tom Grant went quite well yesterday. It was a round table discussion with good points made by several participants.

While we did talk about a number of topics, the metrics discussion dominated the first 1/2 of the call.

One of the questions  — What metrics should be used to measure the effectiveness of Product Managers? — got me thinking a bit.

My answer on the call was that first the focus should be on metrics for the Product Management organization, and then a breakdown from there on metrics for individuals based on objectives and tasks that support the goals of the organization.

To me that seems like a logical approach, because all other organizations in a company, includes sales, marketing, technical support etc. have metrics defined and measured that way.

So what’s the problem?

So why is it so hard to come up with metrics for the Product Management organization? Well,  it goes to the heart of the major issue with hi-tech Product Management today.

And that is that most companies don’t look at Product Management as a holistic function within the company, but rather as a set of individuals or small teams working on a variety of product related tasks.

Look around and see how the focus of Product Management is different in different companies.

Look at how widely the reporting and organizational structures are for Product Management. It is part of Marketing in some companies, part of Engineering in others, a standalone department in others.

Look at the ongoing debates related to when Product Management roles should be defined and introduced in a company.

If you’ve worked in or have been exposed to Product Management in different companies, compare and contrast the tool sets (or lack of them) used by Product Management organizations versus the tools used by other departments to do their jobs.

And if people don’t look at Product Management and it’s objectives in any holistic and standard way, how can they set about defining and measuring key metrics for the Product Management organization?

Metrics should focus on measuring intended outcomes

For Sales organizations, the key metrics  (product sales/bookings etc.) are directly tied to the intended outcome of the function: generating sales and revenue.  There are numerous secondary metrics that are tracked such as  sales breakdown by product/product family, by deal size, by geography, by new vs. existing customer etc.

And don’t forget all the sales funnel metrics that are used to track progress and success, such as average time to close, win/loss ratio etc. The important metrics are clearly tied to the intended outcomes of the activity of the sales organization.

For marketers it’s a bit more complicated because there are different roles in marketing and different intended outcomes. The two primary outcomes that can be applied to marketing are related to lead generation and market/industry awareness.

And from there numerous metrics can be identified related to number of leads, cost per lead, lead quality, lead to prospect conversion ratio etc.

Metrics for awareness are numerous, but basic metrics focus on “mentions” by press, analysts and other influencers in publications, reports, blogs, and via social media such as Facebook and Twitter.

And what of Product Management?

What is the primary objective of Product Management? In a previous article on this blog entitled Product Management Metrics (part 1), I defined the mandate of Product Management as:

To optimize the business at a product, product line or product portfolio level over the product lifecycle.

Don Vendetti of Product Arts, wrote a series of guest posts, entitled Measuring Product Management. In part 3 of his series, he provided his definition of the Product Management mandate:

To deliver measurable business results through product solutions that meet both market needs and company goals.

I like Don’s definition.  Both definitions share the same spirit about business focus,  but Don’s phrasing is clearer and more explicit than mine. But I do think that mention of the product lifecycle is needed because that has a huge impact on the objectives and the required focus of Product Management.

Don’s use of the words “measurable business results” is crucial to this discussion.

So what are those business results? Well it depends on the business and the company goals. 🙂

Those goals depend on the many things. Some companies care about revenue. Others care about market share. Others care about profitability. Others only care about getting acquired. And those goals can change with time.

Some choose to be technology focused, while others are sales, marketing or market focused. Some companies have a single product, while others have portfolios of products.

Depending on the company’s goals, size and level of maturity, the market conditions, it’s financial status and it’s overall strategy, Product Management’s objectives will change and so the metrics to measure Product Management will also change.

I’ll stop here, but I’ll pick up this discussion in an upcoming, and long overdue post that will be entitled Product Management Metrics (part 3).

Make sure you read Part 1 and Part 2. 🙂

Saeed

Product Management metrics with Tom Grant

On Wed. May 5, I will be participating in a live teleconference with Forrester Analyst Tom Grant and a number of his clients.

We’ll be discussing a number of issues related to Product Management, but focusing on metrics that are important to the field of technology product management.

I’m looking forward to the discussion and hope to learn as much as I contribute.

You can find more information about the call on Tom’s Forrester blog.

Saeed

There is no such thing as bad press

OR: Misery loves company, especially company that can go onto your Twitter stream.

So assuming you’ve read the Interwebs lately you’ve hard the tale of how an Apple employee lost a next-generation iPhone test unit at a bar where it was found and sold to a gadget blog. Sordid stuff.

Many commenters immediately assumed that the person who lost the phone would be fired, but that has not yet been reported to happen. So perhaps he merely has to spend a few weeks in the penalty box at work.

(Note to the CrankyPM: Yes, your CEO can drop his laptop off his yacht without penalty, but if you lose a hotel receipt there’s hell to pay, right?)

At any rate, of all the things that might come out of such an incident, this is an unlikely one: Lufthansa has offered to fly the person-who-lost-something (I hate to pile on by calling the poor guy a “loser”) to Munich.

You see, he lost the phone at a German-style bar, tenuous connection, etc.

Now, it takes a lot of nerve to offer this poor Apple employee a reward for making one of the biggest mistakes in recent company history (with the exception of MobileMe, zing!) but, the real question is: how much nerve does it take to accept the offer?

And is this a legitimate use of social media marketing or is it, as a Lufthansa employee would succinctly put it, just Schadenfreude?

The Bad of Product Management

Here’s part 2 of the results from my survey. Part 1 — the Good — was published last week.  Following the same format as Part 1, I’ve categorized the open ended answers into specific categories and the picked some of the most representative responses for each of those categories.

The question asked in this case was:

What are the top 3 things you *DON’T* like about your role? (The BAD)

NOTE: Please list things that you actually do in your job or are enabled to do.

NOTE: It was actually harder putting these responses into appropriate categories than it was for the Good. Sometimes responses straddled 2 or 3 categories that I had used. In the end, I did my best to be consistent about the categorizations.

And with that, here are the results:

Tactical Responsibilities

By far the most common thing disliked was having to do what can best be described as very tactical tasks. I don’t think this is unique to Product Management, but there was a really long list of these types of answers in the survey responses.

  • Writing detailed specifications
  • Bug triage
  • Product demos
  • Sales support
  • Writing collateral
  • Handling support escalations
  • Writing white papers
  • RFP responses
  • Mundane research
  • Creating data for customer demos

The general sense I had when reading these and other similar responses is that a lot of time is spent doing these things and that time could be better spent in more valuable tasks.

I’m surprised no one mentioned being responsible for the dreaded “Platform Availability Matrix”! 🙂

Lack of Authority

The next most common category was related to authority (0r more commonly the lack of it) for Product Managers. This is not news but it is not a good sign if this is still the case in many companies.

  • Little influence on R&D operationally
  • No ultimate decision making authority
  • Competing priorities when leaders/groups want to hedge their bets to avoid making final decisions
  • Realize very little of the planned funding for roadmap projects
  • Executive desire to control – effectively defeating a PMs authority/influence
  • Limited opportunity to affect business strategy
  • Micromanagement of products by upper level management
  • Too often the PM is charged with applying a thin veneer of the latest hot biz idea over current development efforts even when the idea conflicts with the product vision, core belief or functionality
  • Execs deciding strategy with no information or input

People Issues

This is a bit of a catch-all for things related to team work, interaction with other groups, organizational structure  etc.

  • Org structure that inhibits team participation by team members
  • Babysitting R&D (and/or sales)
  • Bad leadership, really bad
  • Responsiveness of the people I’m depending on
  • PM leadership directly converted from Engineering but pretend to be visionary PM
  • Having to manage under performing direct reports
  • Not having a mentor or someone to learn from
  • Mediating between conflicting departments re: product issues
  • Lack of strategic guidance from the executive team
  • Doing other people’s jobs to get the product out

The comment on mediating between conflicting departments is interesting. I don’t know how much mediating that person does or what kinds of conflicts occur, but I found that comment somewhat strange.

The fact that you’re being called to mediate shows those teams respect you enough to have you help them address these issues. At least that’s what I’ve seen in my experience. Not all PMs are called in for those situations, and if you are one, understand why.

Culture

Responses that sounded like they are part of the company culture ended up here. Culture plays a critical role in successful companies and it’s important that Sr. Management understands this and sets the right examples.

  • Ongoing dealings with unrealistic expectations internally
  • Working with teams who don’t care that much about the product
  • People more dedicated to processes and polices than actual outcomes
  • Organization tends to respect product managers who are into technical minutia, not strategic vision
  • Back and forth executive decisions
  • Working with R&D that is unable to make a design freeze
  • A slow inclination to change
  • Good ideas always take too long to reach the market
  • Everything is hurry up and wait

Politics

Where would product management be if it didn’t involve politics? Politics is not always a bad thing, but unfortunately, it’s human nature to take care of number 1 first, and then worry about what’s best for others.  Here are some of the responses:

  • Wresting with other teams to get things done
  • GMs so busy with politics and budgets that they forget about customers and users
  • Juggling the slate to accommodate politics or last minute requests
  • Politics of who owns design

Project Management

An oldie but a good. There were a number of respondents who simply wrote “Project Management” as one of their dislikes in the job.

OK everyone, repeat after me — A Project Manager is NOT a Product Manager. Again. Again. One final time. OK, problem solved?

Lack of Resources

  • Inability to allocate resources to my project
  • Not having enough resources
  • Lack of evangelism resource. To get product to market effectively, you need to help drive feature adoption

Lack of Direction/Definition

  • Lack of broader understanding of expections of Product Management
  • No being challenged enough by Management
  • Lack of definition of the role
  • I have so many different hats/roles to play

Lack of Customer Contact

This came up several times. If you are a PM and your company won’t let you talk to customers, the company doesn’t understand Product Management. You should try to help them understand, but if that fails, seriously consider changing employers. It’s not worth figuratively banging your head against a wall every day.

  • Not being able to talk to customers indirectly or directly
  • Not allowed to visit customers
  • Can only talk to customers when a sales rep is present

Other responses

There were quite a few responses that covered various themes such as workload, job pace, constraints, compensation etc.

  • Sometimes a dumping ground
  • Can be quite exhausting at times
  • A struggle to keep the respect of other departments
  • Working without enough data
  • PM is never really appreciated – [this person should read this post.]
  • All the blame, none of the glory – [and this person as well!]
  • Volume of email
  • Can’t get it all done – [prioritize! 🙂]
  • Not enough time for family and hobbies
  • Communication overload when every problem a stakeholder can’t figure out gets sent to your desk as you seem to know everyone
  • Lack of documentation for all the “gotchas” of our product. No simple way to communicate them to those who need to know
  • No documentation on the history of our products – what was added/changed in what release – [it should be in the release notes or ‘What’s new’ document 🙂 ]

The final set of results — what people want to change — will be published in the near future.

What are your thoughts on these responses? Do they mirror your environment? Any advice you want to give to the people who wrote these comments?

Saeed

Product Management in Pictures #5: If Hardware was built like Software

The Good of Product Management

Way back in February, I ask you to fill out a survey indicating the good, bad and ugly about your jobs. Well, a lot of you did just that, and I thank you for that.

Unfortunately, it’s taken me about 2 months to get around to analyzing the results and reporting them back to you.

Note to self — when you ask people to fill out a survey, don’t be surprised when a lot of people do, and your survey design means it will be quite time consuming to analyze the results.

OK. Now that I have that over with, I’ll get back to business. Here’s what I did with the responses.

There were 3 main questions asking what you liked, disliked and would change in your jobs. For each question, there was room for up to 3 responses.

Given they were free form answers,  I looked at each and tried to classify them in some logical category to identify patterns.

The first key question was:

What are the top 3 things you *like best* about your role? (The Good)
NOTE: Please list things that you actually do in your job or are enabled to do.

And here are the results. For each category, I’ve listed some of the actual responses from the respondents to give you a flavour of what people said.

Responsibilities

Not surprisingly, this was the most common category for responses. People in these jobs like it for the work they do.

  • Managing work that has a beginning, middle, and end with opportunities to sell excitement, problem solve, then celebrate success.
  • It’s a good balance of being social with being analytical
  • Working across all internal groups to educate and take a product to market
  • integrate viewpoints/biases of functional contributors
  • Building multidisciplinary teams without official authority
  • Bringing together and involving myself in every part of the company with the aim of getting everyone on board

Product

The next most common category was related to products and product development.

  • Building new products/solutions from the ground up
  • Work with the development team to assure the vision is turned into a viable product
  • Writing requirements for new features
  • Creating a product that solves customer problems
  • Releasing new product and seeing how it impacts our customers, users, partners.

Strategy

This category was quite common with many people indicating or implying they like the strategic nature of their work.

  • Ability to impact and participate in the corporate strategy
  • Creating vision
  • Guiding the direction of the product
  • Learning the business and strategizing for future
  • Big picture of the product
  • Seeing how it all fits together

Customers

Again, not surprisingly, a lot of responses related to customers

  • Really understand and translate customer needs
  • Customer visits
  • Lots of interaction with our customers
  • Interacting with clients and potential customers
  • Bonding with customers

Cross-team communication

  • Being communication channel between customers/sales and tech dev team
  • Variety of being the linchpin between all functions
  • Interacting with a variety of people internally & externally
  • Getting sales and customers excited about our stuff

Impact and Influence

  • Making things happen
  • My analysis and opinions are respected by senior executives
  • Being known throughout the company as an expert on the aspects of our product I am responsible
  • Can make an impact to the company

Market

  • Identifying market needs/problems
  • Researching unmet market needs
  • Create solutions to meet market/client needs
  • The market and technology are interesting and ever-changing

Creativity and Problem Solving

  • Solving conceptual challenges
  • Creativity required for marketing efforts
  • The opportunity to be creative and innovative
  • The Aha moments when I bring clarity to complex issues
  • Solving technical challenges

Other comments

Some of the other comments that did not fit into common categories include:

  • Crisis management – [NOTE: Someone likes this?]
  • Seriously work on business model & pricing forecasts
  • Getting into the details of use cases
  • Working with UX team on website design
  • Data mining to understand business patterns
  • Responsible for keeping current on web technology
  • Pricing
  • Learning something new on how NOT to do something, every day
  • Mentoring my reports
  • Constantly learning more about the web and analytics
  • Competitive analysis

So there you have it. A summary of what people like about Product Management. Nothing too surprising here. At least I hope not.

It will get more interesting in the near future, when I report on what people DON’T like and what they want to CHANGE in their roles.

As usual, if you have any comments or thoughts on the topic, please leave a comment.

Saeed