08
Jun 15

Take The Product Management Maturity Quiz

I’ve created this short quiz for you to test your product management maturity. If you read the questions carefully the “right” answers will be clear – but you should try to answer honestly, based on how your product management function currently works.

There are five questions, and you’ll get a score and an assessment at the end. After you’ve finished leave me a comment with your thoughts on the quiz and the scoring.

[WpProQuiz 1]

10
Feb 14

Prevent Product Management Fraud!

I claimed last week that one way to modernize a business process is to establish a system of record. And so I was thinking about systems of record, and why they are important. One big reason is that they help prevent fraud. At least that’s true of the system of record for accounting. Does that hold up when we start thinking about the system of record for product management? I think it does.

What does “fraud” mean in the context of product planning and decision-making? I think it means making decisions that either go against the data and information you have, or that are guesses because you haven’t done your customer development and all the other product management good practices. If you’re just making guesses, then you’re committing fraud on the investors. ([tweetthis hidden_hashtags=”#prodmgmt”]If you’re just making guesses, then you’re committing fraud on the investors.[/tweetthis])

Falling down building

Falling down building (CC 2.0 licensed, photo by Horia Varlan)

The problem with the product world is that even if you do everything right, there’s still a high chance of failure. But if you don’t do things right, you’re more likely to fail. It’s like when you’re building a building – if you ignore the laws of physics in your design, you might have a beautiful building, and you might even be able to build it (depending on how far off you are from the laws of physics) but eventually the building is going to fall down, catastrophically.

How does the system of record fit into this? In two ways:

  1. It captures the results of your good practices – conversations with customers and prospects, insights from the markets, etc.
  2. It allows you to use those explicitly to support your decision-making.

Coming back to the baseball metaphor I used when talking about “chunks of value,” the system of record is a bit like the box score for the product management game. You can always go back and see what actually happened, and make sure your decisions are aligned with what’s going on in reality.

 


05
Feb 14

Making Product Management a Modern Business Process

Central System of Record

Having a central record of truth – a system of record – has propelled the modernization of business processes over centuries, from the notion of “the ledger” in accounting, through ERP, to CRM, to the code repository for a software company. Product management is one of the last business organizations to work with ad hoc records – emails, Office documents, Post-it Notes, and wiki pages.

Not quite – this is a system of tape. We’re looking for a system of record. (CC 2.0 licensed by Dean Terry)

All the inputs to product management are ad hoc and random:

  • Emails
  • Documents
  • Tweets
  • Ideas from the idea management system
  • Phone calls
  • Defects from the defect tracking system
  • Enhancements from the defect tracking system
  • Support requests
  • Executive “suggestions”
  • And so on

These all need to brought into a single repository, and organized so they can be of use.

Simply making the step up to having a “source of truth” for all PM artifacts creates incredible advantages for product managers and their companies. And if the product management system of record actually understands product management processes, and how the different pieces of information interact, then so much the better.

This is an excerpt from my upcoming new book, a template that product management organizations can use to automate the PM process. Look for it soon from an e-book distributor near you. To be notified when it’s available, please sign up for my mailing list over in the right sidebar.


14
Jan 14

Start With The Simplest Thing That Could Possibly Work

Start with the simplest thing that could possibly work.

A simple, crappy sketch I made once

A simple, crappy sketch I made once

This is an agile concept (actually from Extreme Programming, technically), but it’s great for helping you get unstuck from any creative problem (see other tips here and here). You have to simply resolve to not worry about whether your design is going to be any good, and just go ahead and do the design. Or the writing. Or the coding. Whatever it might be. The goal is to get the first draft done. First drafts are usually awful, but you can’t get to a good second (or third, fourth, fifth, hundredth) draft until you’ve written the first draft.

For example, if I have to design a new user interface component (and I’m not a designer at all!) I will just take a pen and paper, or use Balsamiq, to create a rectangle that’s going to be the outside, and inside it I’ll put the buttons and fields that seem to me at that moment to need to be there. My only goal is to get something that could possibly, in some limited fashion, capture or present the information that was necessary.

This is the only effective way I’ve found to get going on design problems. Since I’m not a designer, I always have a “block” against designing. As a user of many many different interfaces I have some intuitive sense of what’s good and bad. But I try not to use that sense at all when doing this exercise, because my goal is only to get something that could possibly work down on paper (or into Balsamiq).

Once I have that first crappy design, then I can start mucking with it, improving it, reviewing it with others, and so on. In fact, by getting started in this way, if all the other conditions are right (i.e., it’s not too noisy and I don’t have other distractions) I sometimes go into a flow state and get very involved in creating an actually good design. But I have to start with the first draft, which I know is going to be terrible, and is just something that could possibly work.

What do you use to get unstuck?


07
Jun 12

How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able to do them all. Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities, and what you ask from your developers (i.e., in terms of features), but you also have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.

Priority!

Prioritization is a critical capability for product managers

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give a number of techniques that (typically in combination) you can use to help you make better decisions about what to do. Better, at any rate, than simply flipping a coin. Of course, nothing is guaranteed – as many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But if you want to have the best shot, here are some of the things you should think about.

Techniques of prioritization

I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that you have specific expertise about the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent. On the other hand, if you’re like me, you want something more concrete to backup your decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course – people use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model, to tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value. Analytics are the best tool in your toolbox for defending and justifying your decisions.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then ignore everything in that list after the first ten items. This is a fundamental technique from agile software development – once you have decided what is the most important feature to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), then you can revisit the stack-ranked list, review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment, which in the world of lean software development has come to be called an MVP – a minimum viable product. The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.” Sometimes an MVP is as simple as a webpage, while sometimes it can be a complete development project in itself – it completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers, and one way to test whether your prioritization is correct is to do a thought experiment. For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career – your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization – you might still cut it, but you need to have an especially strong story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release, or in general how to prioritize anything in your career (or life). Let me know in the comments if you make use of these techniques or if you have other prioritization tools you like to use.


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