Design Thinking and Product Management

As a strong proponent of Lean, I'm a bit embarrassed that, as a blogger, I maintain a bit of "inventory", i.e., posts in various states of completion that I intend to publish at some unspecified point in the future. One of the draft posts that's lingered the longest addresses the topic of Design Thinking (DT) as it relates to product management. I spent some time developing a course/workshop on this topic that I intend to complete and offer some day (mental inventory). I was therefore relieved when I saw that Mr. Roger Cauvin had beat me to the proverbial punch by publishing a thoroughly informative and entertaining post on his topic on this blog.

Roger's post does a great job of outlining DT basics and also provides a bit of compare/contrast with Agile and Lean Startup thinking. Since Roger has done such a good job laying the groundwork, I thought I'd change gears and chime in with a couple of more general musings of my own. My observations are based on the idea that organizations can benefit from some number of DT specialists (internal or otherwise) that act in a consulting role in product development companies.

I first came across DT when I signed up for a pilot course on the topic at SAP in 2008 or so. SAP founder Hasso Platner is a big proponent of DT and has championed significant investment across the company. I enjoyed the course but, quite honestly, didn't give it much though afterward. Design Thinking made it back on my radar when I met a friend of mine, Mr. Oliver Kempkens, an expert in this field in 2013. At the beginning of 2014, we toyed with the idea of developing a course or workshop on how DT can enhance product management activities and vice-versa.

My first insight into the similarities between these two fields came when I realized that both PMs and design thinkers are, above all else, problem solvers. In my mind, DT is a mindset that can be beneficial to PMs in general. However, a DT professional can be of particular value in the problem-solving phase of any of our activities. For example, I can imagine a dedicated DT professional could add massive value in the early stages of release planning, particularly for a release that intends to push the innovation bar. Helping to identify new, interesting problems, proposing solutions and validating them with customers and finally creating prototypes is something DT professionals typically do very well.

I must admit that the idea of a PM as primarily a problem solver was bit of an epiphany for me. I knew I'd solved problems most of my career, but hadn't characterized my work in this way. Product management is a complex discipline that can be characterized many ways based on many disparate dimensions of the job, e.g., business, customers, requirements etc. For some audiences, particularly novice ones, characterizing product managers as people who solve market problems can be highly intuitive.

The second key insight I had was how product management and DT compliment each other. While DT professionals are great at understanding problems and proposing customer-centric solutions, they are not, in my experience, experts at shipping mature products, a core competency of PMs. Although oversimplified, it's interesting to think in terms of DT professionals helping PMs solve problems in an innovative and customer-centric manner and PMs as helping make sure great solution ideas are developed and shipped to customers. In this respect, product development teams may not need a full-time DT professional, so a shared function that is engaged as needed can be an effective solution for many organizations.

What is your experience with DT? Does your organization make dedicated DT professionals available to product development teams? Do you use the DT approach in your work?

PM Accountability: What if your building crumbles?

I first became aware of Zaha Hadid, an Iraqi-British architect, when I came across pictures of the Dongdaemun Design Plaza in Seoul, South Korea. Over the years, she's become famous for her "neofuturistic" designs of structures all around the world.

I've always found it unfortunate that the term "architect" is overloaded in IT as in many cases the role a traditional architect plays is quite similar to that of a product manager. The architect seeks to understand the client's requirements and design something that exceeds their expectations. Sometimes wild creativity is called for (as is often the case with Ms. Hadid); sometimes the client requires pure utility. When it comes to big buildings, bridges etc., it is structural engineers that ensure the architect's design can be implemented in the real world (somewhat akin to the role of software engineers in software product development).

Reading about problems with one of Ms. Hadid's creations yesterday (pieces are falling off a library she designed in Vienna) caused me to consider the nature of the accountability a good product manager carries with respect to their product. Our job is to understand our customers' needs and, with the help of other disciplines like UX, design a solution that will make them happy (if we thrill or delight them, so much the better). Obviously, even the best design will disappoint if it is implemented poorly. Unfortunately, I've been in situations in my career in which software I've conceived and designed has begun "falling apart" once it made it out into the wild.

I assume I'm not alone.

The nature of our dependency on good implementation raises many critical questions for product managers and underscores the broad, sometimes nebulous nature of our responsibilities. Although we can't be expected to understand and supervise every aspect of our "baby's" implementation, to be successful, we must hold ourselves out as the single neck to strangle when customers start reporting "cracks" in our creations.

Without getting carried away and overextending this metaphor, I can think of a few important takeaways for product managers from Ms. Hadid's misfortune:

• You will be judged internally and externally for things you don't directly control. Be aware of what's happening on the implementation side of things and be prepared to go beyond the call of duty to avoid shipping a poor implementation of your ideas
• Be careful about what you sign up for in terms of accountabilities: You simply cannot control every aspect of your product, from architectural decisions to the coding of a specific algorithms. Do what you can to ensure quality (and other aspects of product development) and demand that the appropriate folks are also held accountable for it.
• Think deeply about your next step when you have the feeling a shaky building has been erected and will soon have its inauguration. If it starts to crumble, it's probably not development that will be in the headlines.

The architect metaphor can be a powerful one for discussing the accountabilities of product managers as they relate to other software product development disciplines. What do you think? How do you ensure customers are happy with "the building" your team delivers?

Training the Product Manager: An Inventory

I recently started a thread in the enormous LinkedIn Networking Product Management group about appropriate training "topics" for product managers. As a provider of product management training (see www.prickril.com for details), I've been trying to assess how broad the need for training is in the product management community. I seeded the discussion with what I considered a short list of no-brainers, expecting a few folks to chime in with another topic or two:

• Core product management (product life cycle, release management, product strategy etc)
• Negotiation
• Presentation Skills
• Leadership
• Business Planning
• Product marketing.

I was extremely gratified to see far more responses than I expected (in the low 20s as of this writing). In my original post, I committed to consolidating the results and publishing them. I captured feedback in a mind map in a public Google Drive folder so that it will be available to anyone interested as it evolves. I've posted it as a PDF and a native XMind file. You can view/edit the XMind map if you so choose with the free version of their software.

I added comments to many nodes, but the general categories of training I identified were:

• Product Management
• Adjacent (topics related to other disciplines like marketing and sales and general professional training)
• Technology
• Organization-specific
• Other

I wrestled with categorizing some of them so I'm sure others will have a different opinion. Based on feedback I get and new "discoveries", I'll update the map over time. My sincere thanks to all who chimed in and all that will.

I'm looking forward to seeing the map evolve with input from an even broader community!

Overview of a Product Management Assessment Framework

In a previous post, I enumerated what I consider to be the most important criteria for evaluating a framework for assessing a product management organization, particularly one focused on software. In this post, I'd like to outline the approach to product management assessments I've defined with these criteria in mind. I'm looking forward to feedback and discussion on the topic.

In an effort to be comprehensive, I've based the assessment approach on the idea of organizational maturity, a blanket concept that I think is reasonably intuitive. To keep things simple, the assessment generates a single value or score for the maturity of the product management organization. The organizational maturity score is a weighted average of 3 "dimensions" described below.

Dimension 1: Process Maturity

Process Maturity measures how well the organization understands, manages and executes its business processes. A business process converts business inputs to business outputs. Business processes don't have to be described with detailed graphical models and reams of documentation to be managed. What's important is that the organization understands which processes are important, have assigned ownership and is continuously improving them. I used ISPMA's framework to identify the "menu" of key process "elements" to be analyzed. Organizations should probably avoid analyzing more than 5-7 processes at the same time.

Each process can be assessed in general terms, e.g., is there a clear owner, as well as process-specific criteria, e.g., are roadmaps generated for different audiences (typically, a sign of maturity). These criteria can be scored, from 1 to 5 for example, so that an average or weighted average score can be calculated.

In terms of key process deliverables, I use a list of types of information organizations should be gathering rather than relying on a predefined set of artifacts. Checking process deliverables such as roadmaps and strategy papers for quality and completeness can help identify process that are suboptimal.

Dimension 2: Professional Competency

The professional competency dimension helps determine if the right people with the right knowledge and skills are executing the product management function. My framework uses a questionnaire that is filled out by product managers and their managers ranking their proficiency with various product management activities. My questionnaire is based on the Dimensions of Competency I've described in this blog (business leadership, product definition and product promotion).

Interviewing product managers, product management and executive leadership is also important, allowing an experienced assessor to determine if those doing product management have the appropriate background and personality to perform at a high level. There is clearly a subjective element to this dimension, but I don't believe any form or tool can replace experience and judgment. I also think it's important to interview members of other disciplines such as development, marketing and sales regarding the effectiveness of the product management organization.

Dimension 3: Organizational Setup Effectiveness

The effectiveness of the organizational setup is probably the most complex of the dimensions. At its heart, it explores if the organization is set up in a way that promotes success. For example, structural analysis looks at to which discipline the product management organization reports. I believe that, ideally, the functional and technical perspectives are separated organizationally. I talk about these different perspectives in my post about the "piles" of product management.

Organizational setup effectiveness also captures aspects such as professional development, engagement between functions, e.g., marketing, sales, and completeness of product development disciplines. For example, a highly effective product management discipline will ultimately fail if marketing or sales are underdeveloped or even absent.

Bringing it All Together: The Maturity Dashboard

Via simple tools, observation and interviews, scores are generated for each dimension. Weights are assigned for each dimension with the weighted average representing the organizational maturity score. Although this approach is not purely scientific, it is highly approachable and supports prioritization of improvement efforts, i.e., the efforts that have the highest impact on the organizational maturity score are those that should be addressed first. This idea is predicated on the idea that the dimensions and the information gathered truly represent critical aspects of the product management discipline.

The figure below shows a fairly simple representation of what can be a large, complex set of data. I've defined the different levels of overall maturity informed by the maturity levels found in the Capability Maturity Model (CMM).

Note the weights assigned to the dimensions to the left of the labels in the table at the bottom. These are examples of values that can be easily adjusted for a particular client. Some organizations might emphasize Professional Competency (or any of the other dimensions) more heavily so would adjust its weight accordingly. 

Assessing the maturity of an organization is an inherently complex problem. The framework I propose attempts to balance objective data with the judgment of an experienced assessor. A great deal of qualitative and quantitative data would, of course, accompany the dashboard.

So what do you think? Is it similar to other frameworks you've seen? What do you see as the biggest gaps? Do you think this approach could be valuable with your organization? 

Previous post: Does your organization really know what it's taking to market?

Does your organization really know what it's taking to market?

Having been exposed to a fairly large number of product organizations, I continue to be surprised at how rarely they explicitly define a set of concepts representing what it is they take to market. Terms like "product" and "solution" are bandied about but often it seems no one can point to a common definition, resulting in multiple people and organizations having their own definitions and associated expectations regarding these concepts. Having clear, consistent definitions for the things we take to market help keep the entire organization, from executive leadership to developers, on the same page and can have important implications for assigning accountabilities. In this post, I'd like to offer a set of simple concepts that have served me well. If used consistently, these definitions can alleviate some of the confusion I've seen time and time again in product organizations all over the planet.

• An offering is an umbrella concept representing anything that your organization takes to market for customers to consume. The rest of the concepts in this list are types of offerings.
• A product is a good, virtual or otherwise, that is developed and delivered to multiple customers in essentially the same form. Managing products throughout their life cycle presents challenges that I believe are an order of magnitude greater than managing deliverables from a customer-specific project. Transitioning from single-customer project deliverables to product delivery is a topic I've addressed previously in this blog.
• A service, in the context of offerings, is work performed by people for customers, whether it involves "knowledge work" or physical labor. Services are an under-served offering in many organizations, representing a way to add incremental customer value while strengthening customer relationships.
• A solution bundles products and services (and other solutions!) to solve customer problems. Solutions are very often customized heavily for individual customers. Market solutions are defined a priori and promoted in the market. Customer solutions are an instance of a solution delivered to a specific customer.

Based on these definitions, I've found that many product managers, especially those in the B2B space, are actually managing solutions. Acknowledging this fact can help everyone in the organization appreciate the scope and complexity of the work the product management organization is doing. 

I'm not sure that it's critical for every organization to adopt the exact same set of concepts or terminology, but it would be nice! I think it's more important that all product development disciplines (PM, marketing, sales) and executive leadership be on the same page. Ideally, this same or very similar terminology is used to describe offerings to customers and prospects.

What do you think of these definitions? Are they similar to the ones your organization uses? Does your organization have an explicit set of shared definitions?

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

Criteria for Assessing a Software Product Management Organization

In a previous post, I talked about assessing products as they are being developed. In this post, I'd like to talk about a different kind of assessment: assessing (or "auditing" as some others call it) a software product management organization. Formal assessments are often requested by leaders of an organization who are concerned about the performance of the product management function. What I've realized since I began thinking deeply about the topic is that every time I've joined a new company, I've done a mental assessment to size the place up. When I began developing my assessment framework, I found myself trying to articulate or externalize this tacit mental model.

Before sharing my approach, I thought it made sense to share what I consider the primary requirements or criteria I would use to determine if the framework was ready for primetime. Whether you eventually agree with my approach or not, I hope these criteria can help you assess the multiple assessment approaches you are likely to encounter in the market.

An assessment framework or approach should be:

Simple

I believe the approach or method used to assess the product management organization should be reasonably simple: not to many heady concepts or moving parts. This requirement helps ensure those commissioning the assessment can easily understand the approach and its outputs. It also allows one to deliver an engagement in a fairly short period of time. My goal was to be able to deliver an assessment within a couple of weeks or less.

Comprehensive

I've read about assessment approaches that focus on the knowledge and skills of product managers. Although I too think professional competency is critical, it is just one the elements that impacts organizational effectiveness. By the way, I believe that the goal of the assessment should be to measure the organization, not simply the people in it. For example, I've spent a lot of my career creating platforms that model and execute business processes, so understanding the maturity of processes is important to me (and most organizations, I believe).

Quantifiable

I decided early on that beyond the qualitative aspects I can assess based on experience and intuition, measuring subsequent improvement would require that key elements of the framework be reducible to values that could be measured. That doesn't necessarily mean that the values are valid from a purely scientific perspective, but that changes in performance, both positive and negative, can be tracked over time in a convincing way.

Flexible

Experience with quite a few product management organizations has taught me that each organization values different aspects of the discipline. An assessment framework should be flexible enough that it can be adapted to incorporate an organization's priorities and culture.

Transferable

Although I believe it's difficult to generate assessment results that support an "apples to apples" comparison of any two product management organizations, the framework should capture common aspects of the product management discipline in such a way that reasonable comparisons can be made. This criterion is particularly important when assessment multiple organizations in the same company, e.g., different business units.

In a future post, I'll enumerate the key elements or "dimensions" I've chosen for my framework based on these criteria. I've shared my approach with several people whose opinion I value and am so far encouraged.

What is your experience with assessing product management organizations (particularly in the software domain)? What requirements or criteria are important to you?

Previous post: Overlooked Sources of Product Management Power

Overlooked Sources of Product Management Power

The idea that knowledge is power is as true as it clichéd. I've noticed there are several sources of very powerful information that are often overlooked by product managers:

CRM System
If your organization has implemented and maintains a customer relationship management system, you should do your best to get access (even if it's "read only") and use it as a resource to understand what's going on with customers and prospects. You'll very quickly discover that the information stored in CRM can give insight unavailable almost anywhere else. Ideally, PMs should update CRM systems when they interact with customers so the entire account team is aware of discussions, issues etc. I'm amazed at how seldom this resource is leveraged (and how often customers get the impression that your company's right hand doesn't even know the left hand exists).

Customer Support Database
In my post on things to do when you take over a product as a PM, I discussed the importance to PMs of understanding support issues. If you're not browsing support tickets at least once a week and don't regularly engage with support to understand their pain, you're missing a massive learning experience. Investing 20 minutes a week reading about customer issues can inspire you with ideas and arm you with the data you need to influence others, whether they be execs, development or other PMs.

Business Motivation
Understanding the explicit vision, strategy and goals of your organization and/or company can give you insight that helps you define a product that is on-strategy and gives you an advantage when communicating with execs. Think about your most important executive sponsors and ask yourself "Do I really understand specifically what they're trying to achieve?" The sad truth is that most organizations don't have an explicit motivation model. In many cases, you'll have to use your network to get access to presentations or strategy papers that may not be widely disseminated. In others, you may have to ask execs verbally. Regardless, going a level deeper than the vision statement on your company's Web site can, at the very least, allow you to position yourself and your product much more convincingly.

Annual Report
Let's face it, almost no one reads a significant proportion of the content in an annual report. Regardless, as a PM you can often extract nice little nuggets of knowledge that help you understand the big picture, including a sense of the business performance of the entire company. It is not at all uncommon for us to be so focused on our product, that we forget the company is doing a million other important things. How many times have you been caught off-guard by a customer or another "external" that was more aware of developments at your company than you were? Taking time to read the annual report and memorize a few key factoids and maybe even a few financial figures may present you with the opportunity to demonstrate that you're a strategic thinker, impressing people with little more than an offhand comment about dwindling margins in Asia.

There you go, 4 sources of often untapped power. Happy reading! What other sources can you think of?