01
Oct 13

## Product Management Rule of Thumb: Revenue To Developer Ratio Should be About One-to-One

One million dollars! (CC 2.0 license, some rights reserved, by Steve Rhodes)

There’s a simple rule of thumb you can use to gauge the financial health of a software product company (yours, or someone else’s): The number of developers in a software company should be about equal to the the company’s revenue in millions. If the company has \$10 million in annual revenue, then it should have about ten developers. For a startup in growth mode, you can use the revenue run rate rather than the revenue to date.

A couple of caveats:

• A company smaller than \$5 million in revenues is likely to have different ratios. The revenue per developer will be lower, since the rest of the business’s expenses will be much lower. In other words, a \$1 million revenue software company might have two or more developers.
• The revenue to developer ratio is per company, not per product. There’s another rule of thumb that suggests that until you have achieved a \$10-20 million run rate you shouldn’t consider adding another product, but once you have achieved that company size, you need to start working on a new product offering. Obviously, it will get investment far beyond its (so far non-existent) revenue, meaning that the older product will get a somewhat reduced investment ratio – say 15 developers for a \$20 million product, with five developers devoted to the new product.

Note that once you have a \$20 million product you can’t bootstrap a new product in the same way you did your first one. You’ll probably need five developers to get the new product off the ground, not just one or two. For example, you may need to integrate the new product with the old product. And you probably need to make their user experiences comparable – you can’t put a V1.0 user experience on a new product if you already have a v4.0 user experience on an existing product with which it interfaces.

### How To Use This Rule of Thumb

How do you use this \$one million-to-one developer ratio?

• First, it’s a good reality check on your own organization. If you are investing in your product at a higher rate than that, it’s unlikely to be sustainable for long. If you are investing at a lower rate, then you can start taking steps to ensure the investment rate becomes more equitable.
• It can give you insight into your competitors. If your competitor has \$60 million in annual revenue, and you have \$10 million in annual revenue, it means they have six times as many developers as you do. I would use this information to help me prioritize what I’m going to do to beat them, and when.
• If you are interviewing for a new job, you should attempt to understand the ratio in effect at the new company. You can infer a lot – whether the product is profitable, whether the company is investing correctly, whether the company thinks of the product you will be working with as a growth area or a cost-center.
• It can help you understand how you need to allocate your resources as you develop new products that don’t yet have revenue while keeping existing products competitive and growing.

Do you have finance-related rules of thumb you use or recommend? Let me know about them in the comments!

28
Jun 13

## The real target of product optimization

As a product team we should focus on maximizing the ratio of value the product delivers divided by the user’s effort to get the value. Or to put that mathematically, the objective function we want to optimize is:

$dfrac {V}{E_ {u}}$

($V$ is value delivered and $E_{u}$ is user effort to get the value.)

Development activities that result in more value, while not increasing the user’s effort, are desirable, as are activities that reduce the user’s effort while not decreasing the value. Obviously, if you can do both you might have a winner.

But development teams naturally gravitate to another, pernicious type of optimization. Here’s an example that happened to me recently. As a side effect of improving a feature, an engineer modified a report, making it worse from the user’s perspective – harder to use and understand. The reason was “It was easier [for the developer] and eliminated a join.” The problem was that the engineer was optimizing the wrong thing – his time. Time is certainly a constraint on a product team, but it’s not what we want to optimize.

## Product optimization, put another way

My new proposed objective function, ${V}/{E_ {u}}$, is another statement of my three rules of thumb for a successful product:

The most important takeaway (I wrote about this a few months ago) is that you can’t get order of magnitude performance improvements by simply tweaking the existing code. Instead, to get improvements that are more than percentages, you need to change your algorithm. This applies to product value as well – you can’t get an order of magnitude more value by simply doing things the same old way but faster. You need to create something new – and that’s not easy. And optimizing the product team’s time usually works against that goal.

Optimization is an important goal for product teams, but we have to focus on optimizing the right thing.

04
Jun 13

## The Three Key Requirements For A Successful Product

A successful product meets three key requirements:

1. It significantly improves some important aspect of the customer’s process or life. For a top line improvement, aim for 20% or more (increase sales by 20%!). A bottom line improvement better be an order of magnitude (reduce errors by 90%!).
2. It works. Customers sometimes can live with imperfections, particularly early on when you’re delivering so much value they’re willing to take some limitations. But the product better not fail in stupid or obvious ways or you’ll never get a second sale.
3. It fits into the customer’s existing processes. There’s a process that precedes whatever your product does, and a process that follows it. Your product has to mesh with those, or it will be an orphan.

Make sure your product delivers on these requirements (and you can articulate how it does) to significantly increase its chances of success. (This is the TL;DR version of my Product Management Rules of Thumb series)

12
Jun 12

## Your Product Has a Job – It Better Do It

I just subscribed (again) to Mark Hurst’s “Good Experience” newsletter. He dropped me an email the other day asking how I’d heard about the list (I don’t remember, actually) and why I subscribed. As I wrote out my response, I thought it would be something worth posting as well.

My product philosophy holds that two critical factors for a product to be successful are

1. It has to work – to do what it’s supposed to do, to “do the job it was hired to do”
2. It has to be engaging – people should look forward to using the product

The “good experience” concept covers both of those factors. Hence, naturally, I want to continue to get information and inspiration about good experience.

There are other aspects to beating your competitors, but these two particular points seem particularly obvious to me. But, I’ve always been amazed at how many products don’t do well on either score.

## If The Other Product Fails To Work, That’s An Unbeatable Competitive Advantage

With my last product, we would go into head-to-head evaluations with our competitors, and our product would work in the evaluation phase, and theirs wouldn’t. Competitors failed along a continuum – from not being able to complete an installation in the first place, to not successfully performing the basic functions, its reason for being. If your product does not work during the evaluation, then you are likely not going to win the business!

## But If The Other Product Works, Yours Had Better Be More Engaging!

Some products failed later than others, but even if the other product didn’t fail, we almost always won the evaluation anyway. That’s because our product was better, in a key sense – it was more engaging to use. In that particular product space, most products approached the problem in a certain way that was, you might say, the “standard” approach. Our product approached the problem in a different way, one that turned out to be easier for customers both to understand initially, and to work with over time. So we not only won the evaluations because we worked, but because the customers liked us. As Kathy Sierra puts it, we made them feel like they rule!

06
Jun 12

## New Products Improve Processes

Earlier I mentioned one of the rules of thumb I use as a product manager to help me assess whether a product idea is worth pursuing – what I call the “order of magnitude” rule of thumb (in short, your product needs to offer an order of magnitude improvement over the status quo). Another simple rule of thumb I like to use is what I call the “three boxes rule” (even though the picture I draw actually has four boxes!).

The goal of your product is to improve some process of the customer’s. This is true even for innovative products like the iPod, which improves the “walking around” process by adding music to it. SAP improves the customer’s business management process overall by providing a central repository for the data and a predefined best practice workflow for doing back office information processing. Photoshop improves the photograph editing and manipulation process by taking it out of the darkroom and eliminating the need for scissors and paste.

The three boxes – make sure A still links effectively to B’, and B’ links effectively to C

Improving the process is all well and good. But this rule addresses the fact that processes don’t live on their own – there are processes that come before and that come after. In the case of Photoshop, for example, there is the predecessor process of taking the picture, and of getting it into the computer. And then, after using Photoshop, there is the process of putting the picture into a magazine or newspaper layout so it can be printed.

The diagram above summarizes the situation. Box A represents the predecessor process, box B is the process we’re going to improve with our product, and box C is the successor process. The improved version of B is shown as box B’.

Now that we have our boxes, the rule of thumb is apparent: It doesn’t matter how good B’ is compared to B, if you can’t get from A to B’, or from B’ to C, your product will have a hard time succeeding. (This concept is related to the idea of the “whole product,” covered in many books about product development and management, such as Crossing the Chasm by Geoffrey A. Moore.)

## Example: Photoshop In Its Infancy

Photoshop is the product that got me thinking about this rule of thumb. Coming up with the idea for Photoshop required a flash of brilliance, as well as the availability of some technical capabilities like personal computers and GUIs. But once you have the idea, the details are going to work themselves out – “hmmm, I need to be able to crop, recolor, touch up, burn, dodge, copy a section from one picture to another picture, etc.” In fact, most of the functions of the original (20 years ago!) Photoshop were computer-based analogs of what photo editors were already doing in the darkroom or on a paste-up board. I don’t mean to minimize the work or design that went into the functions of Photoshop itself, but the reality is that the functions were secondary to a much bigger problem.

Before Photoshop, when you edited or retouched a photograph, you worked with … a photograph or a negative. A piece of paper or a piece of emulsion. For some activities you needed a separation – three pieces of plastic. To make a copy of a photograph you either printed a new one from the negative, or you took a picture (a photostat) of it. When you were finished editing it, you pasted it into a layout, then took another several pictures of the whole thing to create separations that could be used by a printer.

However, to work with a photograph using Photoshop, you had to have a digital version of the photograph. And at the end of using Photoshop, you still have a digital version. Nowadays that’s not such a big issue. But when Photoshop was first released, B’ was fantastic, but it had a severe impedance mismatch with A and C, which were based on paper.

## Mismatches To Watch Out For

There are lots of ways for impedance problems to arise between A and B’ and B’ and C. Some examples:

• Platform mismatch – the preceding process is on Windows, while your new and improved version of B is on the web.
• Technology change – this is the Photoshop example – the improved process uses a different type of data from its predecessor.
• Unfamiliar look and feel – the existing process lives in a client-server world, while the improved version is Web-based.
• Legacy data integration – my product replaces an existing solution, but the customer still needs to work with their old data.

Many products fail because, no matter how good a job they do at B’, customers can’t get to B’ from A or to C from B’.

Adobe realized that Photoshop could not be successful just by being a fantastic replacement for traditional photo retouching – it also had to address the interface with the old paper methods preceding and following the touchup process. Adobe managed this successfully, obviously, and that makes it an incredible example of the product manager’s art.

05
Jun 12

## Product Management Rules of Thumb 1: The “Order of Magnitude” Rule

Always aim for a factor of ten improvement

One of the problems we product managers face is that there are lots of interesting technologies and product ideas, but not many that can be successful in the market. I like to use the “order of magnitude” rule of thumb as a test to help determine if a new product has any chance of being successful. This isn’t the only metric for success, but I consider it a necessary condition — if you don’t pass this test it’s going to be difficult to get a customer to pay attention to you.

The rule says that a new product product needs to improve some significant process — defining “significant” takes some expertise! — by an order of magnitude. That is, it has to be ten times better in some dimension.

In most cases you can’t improve the overall process by an order of magnitude — for example, there aren’t many products that enable an organization to reduce the personnel required for some activity by 90%. Typically, you’re going to be improving some component metric by that factor. The original value proposition for system management and monitoring software was that it reduced downtime by a factor of ten — organizations went from as much as 20% downtime to 2% or less. (Note that you need to look at the improvement in downtime to see the huge benefit — uptime only improves by about 20%, from 80% to 98%.)

Often you can determine the value of your product — which drives pricing — using this rule of thumb, because as a side effect it can tell you how much the customer will save by using it.

For example, if your product reduces the number of failed transactions on a website, and you can relate the number of failed transactions to a number of shopping carts abandoned, you have an excellent basis for pricing your product. “Our product will reduce the number of failed transactions by a factor of ten, resulting in X% more sales on a weekly basis, at an average of \$Y per sale. At a price of \$Z, the system pays for itself in a few months.”