Category Archives for "Rules of Thumb"

To 10x Your Profits Start With Retrospectives

20% is boring

As many of you know, there’s a technique called a “retrospective” in scrum, or you might call it a debrief. After each sprint the team spends a short amount of time reviewing what went well, what could be improved, and what they should stop doing. The goal is for the team to learn quickly from each sprint.

So, let’s say I really wanted my team to start doing retrospectives, and the team is unwilling. So I share this little bit of research with them:

In a meta-analysis of 46 studies on debriefs (also called after action reviews or lessons learned), Scott Tannenbaum and Christopher Cerasoli found that when appropriately conducted, debriefs can lead to a 20-25% average improvement in performance.  The authors found performance improvements in the use of debriefs with both teams and individuals.  (Thanks to the Center For Evidence Based Management for sharing this study.)

Obviously, based on this data retrospectives and debriefs should be a no-brainer. They are easy and they make your team 20% more effective. But this data still doesn’t motivate most teams to act. Why not?

Because a 20% improvement isn’t enough to get the team to change its behavior.

I need a 10x benefit

This is a general problem for product managers. 20% improvements aren’t interesting to people, whether they’re your customers or your team members. One of my product management rules of thumb is the “Factor of 10 rule” – people aren’t willing to make a change – to a new product, to a new process – unless they get a 10x benefit on a metric they care about.

Back to my problem. I still think retrospectives are a good idea, because I want my team to learn faster. What if I can figure out how to pitch retrospectives as making an order of magnitude difference to something important?

When does 20% equal 10x?

Somehow, I have to make 20% appear to be 1000%.

And that’s what this post is about. (It’s not really about retrospectives.)

Let me tell you one of my favorite stories. At NetIQ we improved the uptime of Windows servers by 20%. That’s nice, but as I said above, it’s not compelling.

But by improving uptime, we also reduced downtime. If you do the math, we reduced it by a factor of nearly 100 – two orders of magnitude! And I can assure you that our customers cared a lot about having less downtime. That’s a story you can tell, and indeed at NetIQ we told that story well.

Can we apply the same kind of thinking to “20% performance improvement?” Somehow turn it into an order of magnitude improvement?

Well, here’s one way. It’s similar to the “downtime/uptime” calculation we did at NetIQ.

Teams improve by learning faster

How fast will the team learn if they don’t do retrospectives? I assume the team’s performance will increase over time naturally, but kind of slowly. Let’s call it 2%. So, if retrospectives increase that rate to 20% … I get a factor of 10x right there.

With this data I can say, “I recommend the team start doing retrospectives – your performance will improve 10x faster.” Retrospectives accelerate the team’s learning, and they accelerate it by a factor of 10. That’s a much better pitch. And learning faster is a benefit that most teams consider important.

How does 10x faster learning affect the bottom line?

But now let’s make the problem a little harder. I don’t just want the team to do retrospectives, which are free. I want the company to buy the team a tool to support retrospectives. And unfortunately, the execs don’t care that much about team learning, no matter what they say about “the company’s people are our most important asset!”

So I have to go to the next step. I need to show a dollars-and-cents business benefit of “improving performance 10x faster.”

What happens when you accelerate your learning by a factor of 10? Well, the whole point of having a higher performing team is to release higher quality products faster.

And what happens when you introduce higher quality products to market faster? You get more revenue faster.

What happens when you get more revenue faster, but with the same team and the same level of effort? All the additional revenue goes straight to the bottom line. So your profit grows, and it grows faster than it would have.

Triple profit for almost no cost

Let’s put some numbers around that. Let’s say that improving the team’s performance results in a 10% improvement in time to market, which results in a 10% improvement in being able to close sales. In any period I get 10% more sales than I would have.

Let’s also assume that our profit margin was 5% before. If I had $10 million in revenue in a quarter, our quarterly profit was $500,000.

With my improved team performance, all the costs are the same, except I’m spending a little bit more on a tool – say that’s $3,000 per quarter. Otherwise, all I’m doing differently is having another short meeting every few weeks. I didn’t add anyone to the team. But now my revenue is $11 million in the quarter because I got better product to market faster. My profit is now $1,497,000.

Improving the team’s performance by 20% resulted in tripled profits!

Oh wait – did I say “triple?” How about 10x my profits?

This is even more impressive if the company is barely profitable. If our profit margin is only 1% before improving the team, then improving the team can increase my profits by a factor of 10.

Unwinding the example

If I want to pitch retrospectives. I’m going to use some of these ideas. If we do retrospectives or debriefs:

  • The team will learn 10x faster
  • Therefore, we will get better quality products to market faster
  • The result will be as much as 10x the profits

I illustrated this in terms of retrospectives. But the same kind of thinking can apply to many other kinds of improvement.

How to turn 20% into 1000%

  1. Find the baseline, call it X. In the example the baseline is the rate at which the team is improving without doing retrospectives. They’ll naturally improve some, but not as much. Let’s say it’s 2% (per year).
  2. Find the improvement to the baseline, call it Y. For retrospectives, it’s 20% per year.
  3. What’s the ratio between the improvement and the baseline (X/Y)? For retrospectives it’s 10. This means that in the retrospective case, the team is getting better 10x faster.
  4. Optional next step: What does that 10x improvement mean in terms of business results? There are a few big ways to improve the business – get to market faster, win more of the deals you get into, get into more deals, open a new segment, increase the total addressable market (TAM) of the segment you’re in. Improving the effectiveness of the development team can impact four of those five.
  5. Figure out how impacting one of more of those factors affects revenues and profits. Especially for profits, and especially if you are starting at a point of low profits, you can often get amazing multipliers for just improving your processes a little bit.


1 A Toolset For Getting Unstuck When Your Creativity Is Blocked

Penrose Triangle - A Very Creative Block

A Very Creative Block – Penrose Triangle by Wes Peck, CC 2.0 license

We product managers are inventing stuff most of the time. Whether it’s new features, or designs, or go to market materials, or just making decisions. And that means we are going to have creative blocks. A lot. That is, except for those times when we can steal stuff from others. Unfortunately, we can’t steal as much as I’d like!

A Toolset for Overcoming Creative Blocks

So, I’ve honed a set of “thinking tools” over the years to help me make progress in this invention process. Especially when I’m stuck (which happens all the time), I find I can often get unstuck using one or more of these techniques. This list includes:

  • Mindmaps – I have several product management-specific mindmap templates
  • My product management rules of thumb
  • The V.A.L.U.A.B.L.E. rubric for requirements
  • The Cynefin framework, especially the Complex quadrant
  • Asking good questions (open-ended, “5 Whys”)
  • Talking to other people, even people who don’t know anything about the topic and aren’t that interested – it turns out I “think by talking”
  • Creating a Powerpoint about the topic, and then presenting it (out loud, but only to myself)
  • Crappy first drafts and “Just get started” and “The simplest thing that could possibly work
  • Write the Amazon review first
  • Anthropology – getting back to the people whose problem I’m solving to make sure I really understand it. (Problems are much easier to solve when you understand them correctly!)
  • Sketching and mockups, even though I’m a terrible artist and designer. Simply putting something down on paper or in Balsamiq or Powerpoint often breaks down obstacles.
  • Appropriation – seeing how others have solved this problem, or finding out how similar problems are solved in a different domain. (“Good artists copy, great artists steal.”)

Especially if I’m stuck, I do some of these things and I find myself, against all odds, making progress.

Some of these I’ve discussed before (links provided above). But much of this post is only a tease. I plan to make follow on posts about my mindmaps. But let me know if you want me to drill down one of more of these ideas.



5 Surprising Ideas That Will Make Customers Love Your Products

The other day someone asked me “how do I position my new enterprise software product for each of the three buyer types – user, buyer, and decider?” We had a half-hour discussion about this. It boiled down to a set of ideas, some of which I’ve talked about on the blog already, that comprise a powerful set of tools to help you think through your product offer, value proposition, and positioning.

  1. Goal-directed design – If your product helps users address their personal goals (“don’t let me look like an idiot,” “don’t make me do stupid stuff over and over again,” etc.), not just their practical goals (“getting the job done”) they will love it. (This concept is from Alan Cooper’s awesome The Inmates Are Running the Asylum – a must-read for anyone interested in making usable products that customers love.
  2. Order-of-magnitude rule – You have to find a way to describe your product as 10x better than what they currently use, otherwise it’s not worth it to them to buy and switch from the status quo.
  3. Core-vs-context – Context is what all the products do in the category. Core is what differentiates you from other products in the category. Your product has to deliver the context – these are “table stakes”. You have to have some differentiators, otherwise why would people buy your product instead of your competitors’?
  4. Process fit – There’s a process before yours that is feeding your product. There’s a process after yours that your product feeds. You must ensure your product can connect to the preceding and subsequent processes
  5. Build in knowledge – Customers are looking to vendors for knowledge, not capabilities. If you add knowledge into your product, it’s 90% likely to be a differentiator.

These five key ideas will help you validate your product idea, ensure users love your product, and beat competitors. 

1 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!

Doug Hall’s Three Laws of Marketing Physics

I like to use simple heuristics to help me think about product management problems or situations. I’ve written about my three product rules of thumb which can determine if a product can be successful. There’s also my take on agile, ways to get over creative blocks, and how to prioritize.

Another great heuristic I love is Doug Hall’s Three Laws of Marketing Physics. He describes them in his book Jump Start Your Business Brain. (Which I highly recommend – it’s a great read for this and many other great ideas.)

Innovation expertise, guaranteed

Hall is an innovation expert, the inventor of Innovation Engineering, and founder of Eureka Ranch. He and his team run Eureka Inventing, among other programs.  These are innovation sessions with teams from large and small companies who need to improve their products. It’s a 12-week process that “takes you from dreams and goals to a Meaningfully Unique Innovation that is highly protectable.”

The Three Laws of Marketing Physics capture the three things you need to maximize the likelihood of product success. They don’t guarantee success, but if you don’t have them your probability of success plummets.

The Three Laws of Marketing Physics

Your product must have:

  1. An Overt Benefit – what’s in it for the customer? What good thing – benefit – do they get from your product? You must be able to articulate this very clearly. You can’t depend on prospects to figure it out themselves, you have to tell them directly.
  2. A Real Reason to Believe – Persuasive credibility that your product can deliver what you’re promising with your Overt Benefit. Customer confidence is low, and distrust of vendors is high, especially nowadays. Your buyer may have as much or more knowledge as you do! You need highly credible and distinct evidence that the customer will gain the benefits you are promising.
  3. A Dramatic Difference – Of course you know you need to differentiate from your competitors to win. But you may not realize how dramatic the difference needs to be. See if you can make it ten times bigger than you think you need to. Focus it directly on the Overt Benefit and the Real Reason To Believe.

It’s not just a feeling, there’s data

It’s immediately obvious that a product that aligns with the Three Laws of Marketing Physics will have a distinct advantage. But Hall goes farther in his book and lays out exactly how much the advantage is. For example, a product with a low Dramatic Difference has a 15% likelihood of success. A product with a high Dramatic Difference has a 53% probability of success. And a product that combines all three – an Overt Benefit, a Real Reason To Believe, and a Dramatic Difference has a compounding effect on probability of success.

If you’re a product person and you can’t articulate these three Laws for your product, you have some woodshedding to do.

Product Management Rules of Thumb 3: It Has To Work

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!

Product Management Rules of Thumb 2: The Three Boxes Rule

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.

Actually four boxes illustrating the old process and the improved process.

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.

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