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?

When a feature goes horribly wrong...

I recently Tweeted (@gprickril) that we product managers as a community need to be more forthcoming in sharing our failures. Somewhat ironically, today I'd like to discuss what I consider someone else's failure. Although this post may seem on the surface to be a bit negative, the idea is to start a discussion and learn something. Let's face it: we learn way more from failure than from success.

I'm following a software train wreck that I thought would be interesting to address while it's in progress. Since the early days, I've been a user of Google's Chrome browser. Back then, it was lightning fast and had a clean UI that I like to this day. I have the feeling it's lost a bit of its speed and even grace over the years, but it is till my browser of choice for 95% of what I do.

Recently, the folks at Google decided to radically "improve" the bookmarking experience. Overnight, what had been a simple, albeit unsophisticated, experience became a quasi-graphical head-scratcher that left me wondering how it had ever escaped from the development lab. Imagine my surprise when out of the blue I clicked the Star in the address bar to bookmark a site and the following appeared:

What followed was a counter-intuitive "filing" experience that even after weeks I hadn't quite mastered. It would take several pages to describe the specifics of the experience (a bad sign already) so if you'd like to see it, simply install Chrome. I was so indignant that I went to the trouble of finding the appropriate support forum to voice my contempt. Turns out, I was not alone. Unofficial stats posted by a fellow user revealed "472 posts so far: fewer than 10 in favour of the new bookmarks, 50 don't like the new version very much, over 400 detest it". There's now a steady trickle of comments coming in, virtually all of them negative.

Unfortunately, not only is the basic bookmarking experience hopelessly flawed, the Bookmark Manager was also "improved" to the point of virtual uselessness. The default view shows you a graphical thumbnail for each link displayed in a flat list of all your bookmarks. For reasons that aren't quite clear to me, bookmarks not in folders seemed to have disappeared. I'm not sure I will ever understand this design decision.

Although these words sound harsh, I can assure I don't use them lightly. In my mind, this feature (or really feature area), as well-intentioned as it may have been, missed the mark by about a mile. I have to assume there was some greater vision guiding this design that was completely lost on us poor users trying to get stuff done today.

In Google's defense, you can disable the new experience and return to your comfort zone, although it's a multi-step process. Unfortunately, it sounds as if Chrome updates overwrite this setting.

So what can we learn from this ongoing saga? Here are my key takeaways so far:

• Some features don't require much innovation, even if they're not particularly exciting on the surface
• Given the competitiveness of the browser market, I have real trouble believing that the Bookmark Manager was Chrome's biggest issue: prioritizing is everything
• The prevalence of mobile devices is inspiring folks to make everything graphical -- we shouldn't assume such a change always represents progress.
• Giving folks a choice about adopting radical changes can save a lot of good will. This is a lesson that Google is learning and Microsoft has learned painfully on multiple occasions, e.g., Office Ribbon, Metro UI in Windows 8.

So what do you think of the new Bookmark Manager? What are your takeaways from the tsunami of negative responses to it?

Software Product Management Training and Certification

Product management is one of those complex roles that has to be learned by doing. Every situation is different and the skills required can vary between countries, companies and products. However, getting a comprehensive overview of product management and learning from others, whether an instructor or your peers, can help accelerate your learning and bring things to your attention you might have otherwise never considered.

In this spirit, I'm offering courses on product management based on the International Software Product Management Association's (ISPMA) Foundation-level Syllabus. This 3 day course gives you the "big picture" on software product management and covers many of the key processes that generate value for product development teams. It also gives insight into effective collaboration or "orchestration" with the other "functions" like development, marketing and support involved in building great products. Like most courses, there are challenging exercises that allow you to apply what you've learned and connect some of the "dots" that you are undoubtedly already familiar with.

While training cannot replace actual practice, bringing these two together in an intelligent way can strengthen both your knowledge and practice, making you a much more effective professional. Taking a course also exposes you to other professionals with similar interests and challenges. If I think about the professional training I've done in my life, I would say that networking was almost as important as what I learned from the instructor.

My courses also offer optional certification, again based on ISPMA's approach. Passing the certification exam demonstrates that you understand what you've learned and shows others, including potential employers, that you are dedicated to growing as a professional.

In the coming days, I'll announce more public courses, primarily in Europe (where I live). I also enjoy giving these courses "behind the firewall" for individual companies and organizations. You can discover more about what I do on my site, www.prickril.com.

Promoting Product Management

In an earlier post, I described "product promotion" as one of product management's "Dimensions of Competency". I believe that although we're not marketing professionals, it is critical that we as product managers help get the word out about our products to external audiences such as customers, partners and analysts. In this post, I'd like to talk about an activity that is very often overlooked in product development organizations: promoting product management itself. Having helped strengthen and even implement product management multiple times, I've become keenly aware of the need in some (most?) instances to explicitly educate my coworkers about what product managers do and how we add value. As I've said before in this blog, what we deliver as product managers can itself be thought of as a product. What product manager worth her salt doesn't promote her product?

This idea may sound odd to those who work in healthy organizations with a well-established product management organization full of high achievers that have developed the referent power they need to drive their product's success. But imagine organizations that have a weak product management function or, even worse, lack one altogether. I've been a member of such organizations, fighting hard to establish our discipline only to discover that to many, it was still a poorly understood "stealth" role. I would add that I believe this topic is valid at some level for all product managers. The upshot is that tactfully making your contribution transparent to the organization is rarely a bad idea.

If your organization has recently rolled out or significantly strengthened product management, you should not rely on word of mouth or a "re-org" memo to educate others about what you do. Consider your key stakeholders, carve time out of your overloaded schedule and find a way to get in front of them personally to explain the basics: your role, your plans and how you'll measure success. I typically start with development, although, quite frankly, they typically have the greatest exposure to your work. Even so, you would be amazed at the misperceptions that can develop over time regarding what product management is or should be doing.  One approach is to ask for a slot in one of their standard meetings and clearly explain how you intend to contribute to the success of the product. Being aligned with development leadership is obviously an important prerequisite. Do the same with marketing, support and other important internal stakeholders.

Another approach is to schedule a brief meeting, perhaps 30 minutes, and invite virtually the entire product development organization. Create a 10 slide deck that that covers "the basics" (from above) and leave plenty of time for questions.

If your organization has a more mature product management role, don't assume everyone understands it. Regularly addressing people from other disciplines or even product groups face-to-face and sharing your challenges and successes can give these audiences a better appreciation for what you do. It also demonstrates a level of professionalism that will usually impress.

I also like the idea of having a wiki that provides transparency on the product management team and their activities. I've also resorted to hanging posters displaying goals, accomplishments and other interesting information in hallways to make sure product management's contribution was reasonably conspicuous.

I know many of you are thinking that nothing promotes product management like success in the market and I agree wholeheartedly. But I would still challenge you to provide others involved in product development with greater insight into your contribution via more channels and with greater frequency than quarterly revenue reports.

Promoting product management is an ongoing activity that you should actively pursue and manage -- just like promoting your product; the work never really ends. In rare cases, you may be making such a spooky contribution that your rock god status speaks for itself. The truth is, these situations are rare a primarily an illusion dreamed up by product managers who have gotten out of touch.

So what do you do to promote product management within your product development organizations? What experiences can you share?

My Wishes for Product Management in 2015

We're a few weeks into the new year and I, like many people, am planning for the year ahead. I became much more active in the international PM community last year as I began blogging, launched SPM Resources.com, promoted both on Twitter and began participating in PM-related LinkedIn groups. I even attended the Product Management Festival in Zurich.

I must admit I'm still a bit frustrated by the general lack of understanding of the value we add. I think we as a community need to own this problem and work together to resolve it. Toward that end, here are the developments I would like to see in our community 2015:

1. We stop referring to ourselves as mini-CEOs

I understand the motive for using this terminology: It somewhat captures the broad nature of our accountabilities and connotes leadership, a critical success factor in our profession. However, I also believe that in the long run this type of hyperbole does more to undermine our credibility than to help it. As I've said before, I believe that the vast majority of product managers have a reasonable amount of influence on getting products on the shelf, much less getting it in the hands of customers. By and large, we are not CEOs or even general managers and that's Ok - we still add massive value. Let's focus on helping people understand what product managers do and less time casting ourselves as something else.

2. We begin positioning our role as strategic (and walking the walk)

I wrote in an earlier post that the best way to describe product management to executive leadership is from a strategic perspective, i.e., product managers execute organizational strategy at the product level. I hope in 2015 more of us embrace this idea, demanding an organization strategy to guide us and creating a compelling product strategy that is aligned with it. I also hope more of us work the words "strategy" and "strategic" into our descriptions of our job. BTW, I don't consider this idea contradictory to the first point (you don't have to pretend to be a CEO to be strategic).

3. We move closer to a credible certification scheme

To say the least, there is no shortage of product management certifications available today. Most that I come across are offered by commercial organizations that also offer materials and preparation (often in the form of training) for their proprietary certification scheme. I would like to see an organization stand up as a non-profit and develop a certification program that is reasonably independent from commercial interests and mature and comprehensive enough to be valued by our community and those who hire us. Reasonably good analogs are the AICPA for certified public accountants in the US and PMI for project managers.

4. We help each other in more powerful ways

My recent foray into social media, groups on LinkedIn and event conferences has convinced me that there is a healthy community of PMs worldwide that is dedicated to helping its members evolve professionally. I hope in 2015 we see powerful mechanisms like mentoring grow significantly and that our community becomes even more active and united.

What do you think of these goals (or maybe just wishes). What would you like to see in 2015?

Previous Post:  Key to a better 2015? Pay yourself first.

Popular Posts

• Hitting the ground running as a new PM
• Design Thinking and Product Management
• PM Accountability: What if your building crumbles?