Sep 16

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.



Jan 14

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. 

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!

Jul 13

Doug Hall’s Three Laws of Marketing Physics

As a product manager I use some 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 there’s a good chance of a product being successful.

Doug Hall has a great set of rules – actually, they are “laws,” according to their author – called the Three Laws of Marketing Physics. He describes them in his book Jump Start Your Business Brain, highly recommended and a great read for this and other reasons.

Innovation expertise, guaranteed

Hall is an innovation expert, the inventor of Innovation Engineering and founder of Eureka Ranch, where he and his team run Eureka Inventing, among other programs.  These are innovation and ideation sessions with teams from large and small companies who need to improve their product offerings. 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 your product being successful – they don’t guarantee success, but if you don’t have them your probably of success plummets:

  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 – “overtly.” 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 in this age where the buyer may have as much or more knowledge as the seller. 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 in order to win. But you may not realize how dramatic the difference needs to be – ten times bigger than you think, and focused directly on the Overt Benefit and the Real Reason To Believe.

It’s immediately obvious that a product that aligns with the three Laws will have a distinct advantage over products that don’t. But Doug 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, while 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 commensurately multiplicative effect on probability of success.

Over the next few days we’ll drill down on these Laws a bit more, with a few examples. In the meantime, if you’re a product person and you can’t articulate these three Laws for your product, you might have some woodshedding to do.

Jun 12

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!

Jun 12

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.

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