Strategic Software Product Management (SPM) White Paper

I've just finished a white paper on the strategic role of software product management in software product organizations. You can register for a free copy on my site, www.prickril.com. Looking forward to hearing your feedback!

What product managers need BEFORE they prioritize release investments

The fact that I see lots of blog posts and other content on feature prioritization makes sense -- it's generally considered one of the key accountabilities of product managers. There are all kinds of prioritization techniques, e.g., value vs. complexity, the Kano Model and MoSCoW,  that can help you focus on investments that are most likely to contribute to your product's success. Recently, I realized that I see much less emphasis placed on the preparation required to prioritize features, irrespective of the approach adopted. It also occurred to me that very often product managers are prioritizing the wrong things.

It is common for product managers to create lists of requirements or the associated features (requirements and features are *not* the same thing) and then try to prioritize or even stack rank them based on a combination of intuition and perhaps one or more of the prioritization techniques mentioned above. The problem with this approach is that individual features, by themselves, don't necessarily support a broader use case or scenario that actually delivers customer value. Imagine someone asking you as a car buyer if you prefer a stereo in the car *or* speakers. The truth is, your requirement is that you can listen to music. I was years into my career before I realized that I should be prioritizing use cases/scenarios rather than individual features. I must admit I'm a bit embarrassed that I regularly provided customers and partners with flat lists of features and asked them to prioritize them (sometimes based on a fake budget) without their having an understanding of how these features would work together to support their key scenarios. I realize now the results from such exercises were extremely suspect and often misleading.

So now that we know what to prioritize (use cases/user stories scanrios and not features), what do we need as input for the prioritization exercise regardless of the method we plan to use? I would suggest the following:

Business Motivation
Here I refer to the "why"aspect of product development, referring specifically to the OMG's Business Motivation Model, which defines key concepts such as vision, goals and objectives. Defining a product can be thought of as an exercise is balancing stakeholder needs with your product vision, which, if you desire to be innovative, will, by definition, imply investments in features your customers don't know they want yet! Understanding your vision and business objectives clearly is critical to prioritizing investments in your product.  I've written about the business motivation model in a previous post.

Stakeholder Analysis
The use cases or scenarios you're prioritizing should be a reflection of requirements you've gathered from all your stakeholders, including (but not limited to!) customers. Partners, executive management and even product managers of other products in the portfolio can have a profound impact on your product's success; don't overlook them! If you're not aware of all of your stakeholders or don't understand their influence on your product's success, there is a very good chance your prioritization efforts will yield half-baked results and ultimately, unhappy stakeholders. The stakeholder influence-impact grid can be a great start to understanding your stakeholders.

Implementation Estimates
You will need at least high level estimates of how much effort each use case will take to develop and test (development costs can be dwarfed by the cost of testing some features). It is impossible to reason over the net benefit of a given investment if you don't understand the cost side of the equation. Although accurate estimates can be hard to come by early in the release process, techniques such as t-shirt sizing can help.

Business Justification
Each user scenario you prioritize should be justified from a business perspective. I'm not referring here to a full-fledged business case, which can be difficult or impossible to reasonably develop at the feature level. What I mean is that you should have a sense of the likely business impact with enough detail that you can compare scenarios on this basis. Will the scenario increase adoption? Will it unblock a significant number of sales? Doing some thinking here can help exclude features that seem valuable but have questionable business impact and, of course, help determine which scenarios will give you the best bang for your buck.

What do you do to prepare for prioritizing release investments? What other types of data do you collect? What exactly do you prioritize?

Previous post: A simple life hack to deal with the mental "reminders" we receive on the verge of sleep

You can find more information about me (including upcoming training dates) at www.prickril.com.

A simple life hack to deal with the mental "reminders" we receive on the verge of sleep

One of the most annoying things about the way my brain works (there are many of them!) is that its task reminder mechanism works best when I lay down at night (usually exhausted). It seems that almost without fail, when I'm on the verge of sleep, I'll remember something critical that I should have done earlier in the day and need to do urgently when I get up. Until recently, thinking about how I could possibly remember these things in my sleepy state would keep me awake. I finally came up with a decent solution: I bought a pen that shines with a very dim red light. I keep it and a notebook by the side of my bed. The light doesn't wake me up and the peace of mind I get knowing I won't forget an important task is amazing. I realize this doesn't push the innovation envelope, but if you have the same problem, it's a pretty decent hack.

BTW, I have received no commercial consideration for the following link. :P

Are you managing your most valuable professional asset? You should be.

In my 20 year career, I've worked at 6 different companies ranging from multi-nationals to a tiny 2-person outfit run out of an apartment. I've worked in numerous cities on three contents, meeting innumerable other professionals in just about every professional context imaginable. I now realize that if there is one thing I wish I would have done differently throughout my career, it would have been to better manage my professional network.

That last phrase is probably worth dissecting. Firstly, I'm referring to my direct professional network, those with whom I've interacted enough that we would recognize each other's name . Some of these people were coworkers at all levels of the organizational hierarchy, others were customers and still others partners or consultants. When I say manage, I'm referring to the idea of treating that asset with the care and respect it deserves. Don't get me wrong: I have made efforts to network and keep in touch with folks, but if I'm honest with myself, I haven't  made an investment in managing this asset commensurate with its worth. Something that has become crystal clear to me in the last few years is that my professional network is probably the single most valuable professional asset I have. I'm writing this post primarily for people who are beginning their professional journey -- although I think these ideas apply to anyone. You're going to meet tons of people over your career -- managing these relationship can make a difference in your career that is difficult to overstate.

The first time the importance of my professional network dawned on me, someone I really respected left the first company that hired me. I mentioned how disappointed I was to an older co-worker and he said "Look at the bright side: You now have a good contact at Company X." (Whatever it was.) We were in a very competitive industry and job market so he went on to explain that, the way he looked at it, his network's "reach" was growing almost daily!

The problem with neglecting your network is that you can't recreate or easily invigorate it in short order when you need it most, typically when you desperately need expert advice on something or, even worse, need to find employment. On that note, staying in contact with folks just so they can help you out when you need it doesn't sit well with some and clearly shouldn't. You goal in maintaining your network should be to create a potentially mutually beneficial relationship. Indeed, one of the best ways to keep your network healthy is to be willing to help others.

So how do you go about actively managing your network? I would assume there a many approaches, but I'll share a simple practice that has worked for me. It starts by making sure you store people's contact information in a consistent system of record that doesn't change often. A lot of our contact information ends up in our-email client in the form of contact records. Make sure you take this information with you when you change employers! Regularly backing it up by exporting it is a good idea.

Once you have a system of record, you should keep notes on your contacts -- it's amazing what you'll forget after just a few weeks. It's also amazing how well people respond to your remembering a detail about them, whether it's about their job situation or their personal life.

The next step is to schedule "ticklers", reminders to contact folks every once in a while so you don't lose touch. I do this with private appointments in my Outlook calendar. If I work for a period of time with someone I really like or respect, I'll create an appointment for several months in the future to remind me to send a quick e-mail or make a quick call. Sometimes I'll just say "hey", asking them how they are and what they're up to. Other times I'll include a link to something online that is relevant to them or our work together. Either way, this simple gesture is often enough to sustain familiarity for years.

How often you contact folks is a matter of judgment. I would say that if you've been in the work world for more than 5 years, you could easily ping one or two people in your network every week or two. I can assure you that a few years down the road you'll be glad you did.

In closing, your professional network may be the most valuable professional asset you have -- manage it carefully. The brutal truth is that you either manage it or lose it.

You got a problem? Capturing the Problem Space

Of all the mistakes I've seen product managers make over the years (including me!), not sufficiently understanding the problem their product solves is perhaps the one that troubles me the most. Innumerable conversations with colleagues, acquaintances and students has taught me that asking a product manager to concisely express the key problem their product solves results in several seconds of silence followed by a significant amount of stammering. I guess it's understandable: I believe the tendency to think about solutions based on little more than an intuition regarding a problem is baked into the human psyche (quick thinking probably helped us avoid the "jaws of death" on a regular basis). As a product manager, it behooves us to overcome this "rush to a solution" and make sure that we not only understand precisely what problems our product address, but that the problem is expressed in a way that others can understand it too. In this post I'll talk about clear separation of problems and solutions and suggest a method for describing a problem holistically.

Allow me to begin by differentiating between the problem space, that is, a mental representation of a problem and its various states and the solution space, in the context of software products, the set of solutions that solve the problem. Keeping the problem and solution spaces separate is critical for a variety of reasons:

• Without understanding the problem space thoroughly, we may inadvertently only solve part of it or even solve the wrong problem
• For any given problem, there are typically multiple solutions. Picking the ideal solution in a given context can mean the difference between a successful product and one that fails (sometimes miserably)
• Taking a structured approach to this distinction can help us identify new problems that may be addressed by our solutions, uncovering opportunities to create customer value  far greater than we ever imagined.

If the problem space is a mental representation, a fair question would be how we can capture it so that others can grok and reason over it. Although there are plenty of templates for "problem statements", I find them insufficient. I feel so strongly about clearly capturing the problem space that I invented a "problem profile" that I believe provides critical information that cannot easily be captured in a simple statement. Whether you've identified a specific problem, have backed into one by imagining a cool solution or have an "old" solution at hand, capturing the following information regarding problems, a set of which can be thought of as being comprised by a problem space, can be an enlightening experience. The attributes of a problem profile are:

• Problem statement: A succinct representation of the problem that can be widely understood, capturing the what, who, when, how and why of the problem.
• Stakeholder pain: An articulation of the pain experience by problem stakeholders (typically a decomposition of "the who" from the problem statement)
• Supporting facts: Information relevant to the problem that proves or at least underscores its existence. The more quantitative the better
• Causes: The factors that contribute to the existence of the problem. This attribute is very important as often, the first problem we encounter is not the root cause of the stakeholder pain. Playing Five Whys can help here.
• Desired state: The desired state is the minimum set of conditions that must be satisfied for the problem to be considered solved. To the experienced eye, these conditions often appear to be high level requirements (they are!). These conditions will be used when evaluating alternate solutions to ensure that each indeed solves the problem
• Constraints: A constraint is an assumption that in effect reduces the solutions space. Constraints are important input to the solution definition task in that it helps to exclude solutions that aren't acceptable for reasons defined by the constraint. Constraints should be used very sparingly as they (obviously) have the effect of excluding solutions that might be outside our comfort zone.

Find below an example I created describing a problem I have experienced in real life.

Given my background, an obvious solution would be an app that provides parking information (I spent a few years working in the area of "smart cities"). However, who's to say that the obvious (to me) solution is actually the best one? Without a thorough analysis of the problem and all reasonable solutions, there's a good chance there will be a mismatch, even it it's partial, between the problem and the solution I design to solve it.

In future posts, I'll discuss how problem profiles can be used, including developing great products (and a reiteration of how I believe product management relates to the problem and solution states).

What do you think of the problem profile I've defined? Do you use something similar?

One Product Manager's Experience at "world's largest and most international computer expo"

Spent last Monday (March 16, 2015) at CeBIT in Hannover, Germany, which claims to be the "world's largest and most international computer expo". I've heard about it for years and finally wanted to experience it firsthand. I also thought I'd use the opportunity to spread the word about my product management consulting and training services. Here's a quick rundown of my experience:

• CeBIT is absolutely huge! I would say there were 10 exhibition buildings filled to the rafters with all kinds of high tech companies, from IBM and Microsoft to startups from Romania
• I didn't see anything that blew me away from a technology perspective, so it didn't have the feel (to me) of anything like a consumer electronics show
• The revenue this thing must generate is MIND-BLOWING. I'm sure there were several 6-digit vendor pods/booths/areas.

The most salient memory I took away was that virtually all of these people, each in the computer hardware or software business, knew NOTHING AT ALL ABOUT PRODUCT MANAGEMENT. Granted, the place was lousy with marketing and sales folks, which makes perfect sense. However, it was a bit disheartening that in discussions with folks in various positions (sales, HR, marketing) from organizations of all sizes from around the world, I basically had to start  from scratch with respect to explaining our profession. I didn't test the waters in this respect, but I'm convinced all those people would have claimed knowledge of other positions/disciplines in software such as CEO, developer, architect, sales, marketing and support.

Not exactly shocking, but it is clear we have our work cut out for us. Let's make 2015 the year PM emerges from the shadows.

Another Product Management Elevator Pitch

Gabriel Steinhardt of Blackblot recently had the great idea publishing an elevator pitch for product management. Being prepared to describe the value we add concisely and convincingly is, without a doubt, a great idea. As you can imagine, each of us has our own way of pitching what we do, which is probably a good thing. The fact is, different audiences need different pitches, depending on a myriad of factors including the motivation and experience of the audience (as with any presentation!).

As a long-time product manager and now a consultant and trainer, I've given this type of pitch innumerable times. As I thought about my (up to now tacit) traditional spiel, I thought about what I consider the key requirements for a great pitch. A great elevator pitch on product management should:

• Be brief. Hey, you're on an elevator and people are busy. Get to the point!
• Underscore the strategic importance of the role. Talking about daily tasks and other minutia should be avoided. More here.
• Communicate the key accountability(ies) of the role.

With these requirements in mind, I crafted my version of the product management elevator pitch (in a surprisingly short period of time and with few subsequent edits!):

"Everyone agrees that companies need a vision and strategy to guide their efforts and ensure expected business outcomes. In companies that sell products, a dedicated professional called a product manager is required to execute corporate strategy at the product level, ensuring investments in product development support the corporate vision and strategy. Product managers are experts at understanding market needs and turning ideas for solutions to these problems into sustainable, product-based businesses, managing these products throughout their life cycle. Product managers are accountable for making the right product available to the right markets at the right time at a cost that supports business success."

A few comments and observations:

• A piece of software becomes a product when it isdelivered to multiple customers in the same form and managed throughout its life cycle. More here.
• The terms "vision" and "strategy" come from the OMG BusinessMotivation Model
• This pitch probably applies to any organization that "sells" a "product" (not just commercial enterprises)

I've used some version of this pitch for some time and feel like it's been well received. In my mind, I met my own previously stated requirements. I was particularly happy I got it out in only 4 (admittedly lengthy) sentences!

What do you think of my elevator pitch? What's yours?