What's my motivation?

I recently rediscovered the Cranky Product Manager and spent some time perusing her blog. A relatively recent post bemoans product managers that fail to define a product strategy. I’ve also experienced strategy-induced angst in the past but for more fundamental reasons. In my experience, terms like vision, mission and strategy have free-floating meetings that tend to create a lot of noise in related conversations as everyone involved has a slightly different intuition as to what each term means and how the concepts relate to each other. I was particularly irked at how often vision and strategy were used interchangeably. The first ray of hope I saw in addressing the fuzziness and resulting confusion around these terms was the Business Motivation Model (BMM) from the Object Management Group. This specification, updated in May of 2014, addresses the broader topic of what motivates business activity, wisely distinguishing between "means" (what an enterprise does) and "ends" (what an enterprise wants to be).

Here’s a quick rundown of the key concepts in the model with definitions copied from the spec (presented as an image from a PowerPoint I created. Thanks for the lack of tables Blogger. :P). I would highly recommend reading the entire spec -- it shows explicit relationships between these ideas and defines many more relevant concepts.

 

The following table, content copied from the spec, gives examples based on a car rental company.

I was recently asked to lead a working group that was revisiting an organization’s strategy. In the kickoff meeting, I introduced the OMG BMM and asked the team to adopt it as the framework for our deliverables. Being the reasonable folks they are, they agreed. One of the participants was familiar with the model and was glad to see us adopting it. Level-setting on they key concepts benefited the working group, comprising members of the board and extended board, in a few ways:

• We avoided talking past each other based on subtly different definitions and expectations about the relationships between concepts
• Understanding how objectives (measurable targets) are tied to the vision made it clear from the beginning that we would be able to measure progress once the motivation model was defined (the work group wasn’t engaged in busy work or making a token effort)
• Clear understanding of the concepts allowed us to parallelize some of the work, although there are clearly dependencies between the concepts.

As a product manager, motivation has relevance at at least a couple of levels. You should seriously consider defining a motivation model based on the BMM for your product. You should socialize the model to ensure executive leadership and other stakeholders understand it and agree with it. Remember that your vision should inspire stakeholders. Goals and objectives should ground the vision, demonstrating that it is measurable and thus achievable.

You should also ask for a motivation model for your company, participating in its creation if you can. Once you have a motivation model at both the enterprise and product level, you can begin the (now) relatively straightforward exercise of aligning them. Does your product vision contribute to the company vision in an obvious way? If not, one of the visions probably needs to be revisited. Do your goals and objectives align fairly clearly with the organization’s goals and objectives? If not, you and management may have some soul searching to do. Other products’ motivation models can also help you rationalize strategic alignment at the portfolio level.

Wrapping up, the OMG BMM made me aware of the concept of motivation and defines clear concepts that I find highly valuable. Would love to see tooling that would capture instances of the model as described in the spec and facilitate the type of alignment I describe above. Were you aware of this model? Do you think it could be valuable for your product and organization?

Is software product management waste in the Lean sense?

I became a big fan of Lean when it was adopted by the product development organization at a former employer. Leadership hoped the benefits that had historically been realized in manufacturing would translate to our business. As a matter of fact, a consulting organization belonging to one of Lean’s poster children was hired (likely at unimaginable expense) to help plan and execute the Lean transformation. One of the things I love about Lean is its focus on creating customer value. A Lean organization looks at all its activities and classifies them as creating direct customer value or generating “waste”. Some of Lean’s 7 Wastes are fairly obvious. Introducing defects into our products, for example, obviously doesn’t generate customer value. Other types of waste, like inventories, can be counter-intuitive as you begin exploring Lean.

Waste is a particularly tricky concept when Lean is introduced as the term is value-laden and can be perceived as threatening by some (remember this when you read the next paragraph). No one wants to think their work is waste, but to realize the value of the Lean perspective we need to put these preconceptions aside and take an honest look at what we’re doing to determine if or how it contributes to customer value. Lean acknowledges that some waste cannot be avoided, so called “necessary waste”. Identifying necessary waste encourages us to manage our investment in related activities carefully. Once again, an activity’s being wasteful does not mean that it’s not valuable. In practice, some waste is absolutely indispensable. For example, most large corporations would have extreme difficulty operating without an HR function. However, if you think about it, the customers of most software companies would not be interested in directly paying for the outputs of the HR department; they are interested in buying valuable products and services.

I take a pretty hard line when it comes to waste. In a recent conversation with another Lean zealot (coming from a development perspective), we agreed that based on the Lean definition, software product management is waste. I know that statement may seem simultaneously radical, threatening and obnoxious, but I don’t think it’s unfounded. While we agreed that the role of SPMs is important or even critical in mosts contexts, we believe most customers wouldn’t directly pay for the things we SPMs deliver, e.g., specs, roadmaps, vision, good will. Customers pay for working software solutions, which is what development delivers. I can point to software products that made it to market and were even successful without SPMs, but none that were delivered without development. To be a bit more precise, I would categorize SPM as necessary waste.

Once again, I am NOT implying that SPM isn’t important or even critical -- it’s what I’ve built a career doing and I’ve never been more committed to it or passionate about it. However, the truth is that customers don’t value my backlog much; they pay for functioning software that solves their problems. Although I feel I play a critical role in delivering the solutions they want, I clearly don’t directly create what they pay for. I find that the idea of waste as it relates to SPM probably has the intended effect in my case: it keeps me focused on customer value and grounds me with respect to the expected level of investment in SPM.

This post will almost certainly not sit well with some and that’s OK. I think it’s valuable for all professionals to think deeply about what they do and who values it. This type of soul searching can be particularly important for product managers and is something our community probably needs to spend more time doing.

So what do you think? Is SPM waste in the Lean sense?

Kicking the tires before you get hired...

Posted this on LinkedIn as it's not particularly product management-oriented. Decided it might still be interesting to some folks here.

I have a friend who is considering accepting a development leadership position in a software company with a hundred or so developers scattered over a few continents. We were chatting about rumors and other tidbits of information each of us had heard about his potential employer and started brainstorming on questions he should ask as the interview process proceeded with members of the senior leadership team and his potential directs. To put it bluntly, he was keen to know whether the development organization was a “fixer upper” or a lost cause.

Having been thinking quite a bit lately about performing audits (or as I prefer to call them “assessments”) of software product management (SPM) organizations, I suggested to my friend that he offer to do a mini-assessment of development practices at this company before he commits to joining. The idea is to spend a day or two on the ground with the development teams to get insight into their effectiveness, morale and key issues. It was at that point in the conversation that I realized how often we commit to a new job based on fairly limited information and, sometimes, no direct insight into challenges our future colleagues are facing day-to-day.

I feel like I may have stumbled onto a good practice, one that I’m surprised isn’t more mainstream, particularly in leadership positions. Once you get through the interviews with HR, your prospective management and peers, why not spend some quality time in the trenches understanding how things are really going from the people actually doing the work? Even the most well-intentioned hiring managers have a skewed and sometimes disconnected view of what’s happening day-to-day in their organizations. A company that is skittish about letting you spend some time with folks with whom you might work as they go about their daily routine should give you reason to think deeply about the motivation for their reluctance. From a potential employee’s perspective, a day or two of your time seeing your future co-workers “in the wild” seems like a sensible investment.

There could be IP issues of course, but an NDA should address most concerns. Regardless, I think this type of “mini-audit” would typically only be undertaken by candidates who had passed a couple of rounds of interviews and had probably been exposed to quite a bit of sensitive information. As an added benefit to the employer, the job candidate could share their findings with management even if they don’t accept the job, giving leadership insight from someone they thought of highly enough to seriously consider making an offer. BTW, if you’re not aware of glassdoor.com, it can be a great resource for discovering information about prospective employers from folks that have worked for them.

Hey product manager, who's your daddy?

It’s virtually impossible to read anything about software product management (SPM) that doesn’t mention the criticality of serving the customer. Based on the the justifiable obsession with customers in books, blogs, workshops and keynotes, one could easily get the idea that the key to becoming a successful SPM is to focus on what the customer wants or needs and then deliver it. Simple, right? Who could or would argue with that?

Well, the truth is, in may situations, simply making the customer happy, which is important or even critical, is insufficient to ensure your success as an SPM. That’s right, we don’t like to talk about it, but the customer is simply one of many product stakeholders and, hold your hat, sometimes they’re not even the most important one (short-term, anyway). I’m imagining a collective gasp across the Blogosphere as folks “clutch the pearls” en masse. “Heresy!” they’ll say. “He’s crazy!” they’ll whisper. However, in most of the places I’ve worked, I spent at least as much time understanding and delivering on the requirements of internal stakeholders as I did serving the customer.

Take a moment to catch your breath and allow me to explain.

In large companies with big (or massive) portfolios, your product might very well be a relatively small piece of the puzzle. This is especially true if you’re incubating new ideas or working on a product that hasn’t reached the maturity segment on the life cycle curve. In these situations, the survival of your product and, of course, your success as an SPM will depend on your ability to serve the needs of stakeholders such as executive leadership and other product teams. In extreme cases, even widespread customer delight with your product may not be enough to ensure your team retains its charter and budget.

I can think of numerous situations I’ve observed first-hand in which focusing on the customer at the expense of other critical stakeholders has wrought havoc on a product team. In one case, an innovative new product that had appeal that was independent of the company’s best-known offering was run through a gauntlet that almost killed it even though some big, important customers were clamoring for it. In this case, the product team thought of themselves as providing exciting new capability that would help modernize the company’s portfolio. Although their perception may have been accurate, by not developing positioning that clearly demonstrated how the product could also help deliver on the company’s traditional vision and mission, their product was seen as a threat and became the target of direct attacks and indifference that seriously compromised the  team’s ability to acquire or even retain the resources they needed to be successful. Turns out that the leaders of other product teams in the portfolio were stakeholders as important as end customers in ensuring our success in the first couple of releases (yep, I was part of the team).

In many cases, managing executive leadership’s expectations can be as important as managing those of the customer. We would like to believe that if we delight customers and exceed business goals, our execs will be forever indebted to us (or at least to the end of the quarter). While that’s generally true, failure to understand what executive leadership wants, needs and expects can result in resources being allocated elsewhere or your product’s being classified as not being on vision, regardless of what customers think about it. In extreme cases (yet again culled from my sometimes dysfunctional experience), customer response and input from the market may be virtually meaningless to executive leadership. Leaders who consider themselves radical innovators or disruptors can have surprisingly little regard for anyone else’s requirements or desires, even if the other parties are customers. This approach has a fairly obvious downside long-term (most business leaders are NOT Steve Jobs!), but as a product manager you can very easily find yourself managing irrational and tactical forces you have little control over that can impact your success quickly and significantly.

I realize this post seems unorthodox, so let be clear that the long-term success of products is highly dependent on your ability to find customers willing to pay for your solution to their problems. In the short- and mid-term though, you need to be acutely aware of stakeholders other than customers and make sure you’re serving them as well. To better understand your stakeholders and their needs, I highly recommend a thorough stakeholder analysis. I’ll write a bit more on that in the coming weeks.

Dimensions of PM Competency

I recently spoke to a company interested in improving their product management (PM) proficiency. Speaking to the executive sponsor underscored the different priorities relative to PM competencies that I’ve encountered during my career working with a wide variety of software organizations. In this company’s case, for example, product managers are given direct profit/loss responsibility for the products they manage.

I’ve spent most of my career at mega-vendors (IBM, Microsoft, SAP) and realized that truth be told, I didn’t have the same kind of business responsibility for my products. In these massive companies, there was usually a general manager who was more directly involved with setting and tracking business goals, budgeting etc. Although I engaged with sales regularly and participated in business reviews, I can’t honestly say that I was driving the business day to day. I spent my time defining and promoting the product (and trying to put out raging tire fires with a rolled up newspaper). As a matter of fact, the generally accepted paradigm at one company was that certain roles were responsible for getting the product on the shelf, while others were responsible for getting it off the shelf. This division of labor in no way meant that I didn’t care about my product’s business performance (my goals and objectives were somewhat product performance-related), but the truth was that my calendar was overflowing with meetings related to defining the product, not directly driving the business.

If you read the literature on SM and the role of a product manager as “mini-CEO”, my words seem almost heretical. However, MASSIVE amounts of revenue are driven around the world with the arrangement I described.

After spending some time pondering how I could capture these differences I perceived in PM competencies, I developed a simple model that describes software product management competencies along three key “dimensions”. Each of these dimensions requires different competencies and skills and, in my experience, each organization assigns them different relative priorities.

The Dimensions

This diagram depicts the three dimensions I’ve identified. The areas overlap in the diagram as they are typically closely related.

• The business leadership dimension captures competencies and accountabilities related to business performance. Although in many organizations the business is managed by a general manager or similar executive, in other organizations this accountability is the clear domain of product management, consuming a significant proportion of software product managers’ time. These PMs spend their days ensuring that costs are managed and that revenue, adoption or other business goals are reached. While much of the literature on PM would indicate that this is a core accountability of all product managers, my personal experience and that of many folks I know demonstrates that many PMs have more of an arm’s length influence on the business. Typical activities related to the business leadership dimension are:

• Performance monitoring (KPI definition, business reviews etc.)
•  Budget planning
• Revenue forecasting
• Strategic relationship management/engagement (customers, executive leadership, marketing, sales)

• The product definition dimension captures activities that are almost universally accepted as part of PMs' jobs. These functionally-oriented activities include managing requirements (including stakeholder engagement), defining roadmaps and doing product and release planning, not to mention describing features to be implemented from a functional perspective. These are the activities that consumed most of my time as an PM and together can amount to more than a full-time job. Examples of typical activities related to the product definition dimension are:

• Requirements engineering from elicitation through selection for releases
• Backlog creation and grooming (in organizations using Scrum)
• Defining and documenting product vision and strategy
• Roadmapping
• Functional specification of features corresponding to selected requirements

• The product promotion dimension captures activities that are generally considered marketing-related such as engaging with analysts, participating in trade events and supporting core marketing activities such as the development of marketing campaigns, collateral and the like. I’ve used the term promotion as I believe that proper marketing requires dedicated professionals that have a skill set that is related but fundamentally different from that of a PM. I have encountered organizations, typically smaller in size (less than 100 people total, for example), that out of necessity expect PMs to do marketing. In my opinion, this approach is stop-gap -- not in any way ideal. Here are some typical examples activities exercised as part of the product promotion dimension are:

• Participating in trade shows as a speaker or by talking to participants at booths
• Addressing groups of customers at customer councils and the like
• Providing input to marketing on marketing materials such as press releases, brochures and competitive “battle cards” (without typically being accountable for creating these materials)
• Engaging with market analysts to evangelize your product, its roadmap and specific releases.

The Mix

A tacit assumption underpinning this model is that adequately covering these dimensions is typically more than a single person can handle. The model thus has implications for how product management teams are organized and for their collaboration model with other disciplines. For example, in organizations that emphasize the business leadership dimension, a greater proportion of product definition tasks are often relegated to others, including engineering. In my experience, few organizations maintain a perfect balance between the dimensions. Ascribing percentages to each dimension based on time invested can be an interesting exercise. For example, I would characterize my career (on average) thusly:

    •    Business leadership: 15%
    •    Product definition: 70%
    •    Product promotion: 15%

BTW, even though the percentage for product promotion seems small, I felt like I was much more involved in this dimension than many other product managers I knew. Once again, the low percentage spent on business leadership flies in the face of most of the idealistic literature on PM. Regardless, I worked on products that generated significant revenue.

This model also has implications for professional performance management for PMs. Those who are expected to spend the lion’s share of their time doing product definition but are rewarded based on business performance can often feel frustrated and un-empowered. PMs that aren’t directly incented to do product promotion, may de-emphasize this sometimes critical work. These dimensions could be used as the basis for a career ladder, defining expected competency at different job levels, e.g., junior PM, Senior PM.

Conclusion

I've discussed this model with other PMs and clients and so far, find it to be reasonably comprehensive. I would repeat that there is no idealized distribution among the dimensions -- each organization should determine what the appropriate distribution is, set goals appropriately and create a plan to move the organization toward this to-be state. Looking forward to hearing what you think.

High Plains Drifters

Perusing the blogosphere one can easily arrive at the conclusion that all the interesting work in software is being done at startups. When talking to various gurus and “serial entrepreneurs” creating much of the buzz around startups, one hears the phrase “in the valley” (as in Silicon Valley) bandied about quite a bit, e.g., “Every one in the valley knows me.” While there is absolutely no doubt that startups play a critical role in innovation (both of products and product development practice), I’ve spent most of my career slaving away as a semi-anonymous cog in much bigger wheels. I realize this post may seem a bit defensive, but I thought it worthwhile to call out that software product management has many flavors and adds tremendous value to software organizations of all sizes and levels of maturity. Innovation and entrepreneurship aren’t the exclusive domain of those huddled in colorfully decorated offices reeking of new carpet. If they’re successful, many of those working in today’s startups will eventually work in more mature organizations facing the particular set of challenges maturity typically brings.

While many of the “cool kids” will continue innovating down in the valley, many of us will continue fighting the good fight on the plains just beyond this storied land. Maybe we don’t get as much press and in many cases our products don’t have that startup sizzle, but the view on the plains can be every bit as exciting and challenging as the one from the valley (we even get to enjoy a sunset from time to time). Take heart fellow high plains drifters -- you’re important and the role you play just as critical as those managing products a bit further back in the product life cycle.

The "Piles" of Software Product Management

I often see people publishing lists of “pillars” related to a topic, implying that they’ve identified critical underlying concepts or ideas. In this post, I would like to introduce some ideas on software product management (SPM) that I think are even more fundamental than pillars. I call them “piles”. In case you’re not familiar with the term, a pile is a post that is driven through soft ground to more stable layers to support a structure (like a building). These ideas are so fundamental to me that  I often have difficulty discussing software product management theory with people who haven’t been exposed to them. 

Pile 1: Functional vs Technical Perspective

I find it very difficult to have a meaningful conceptual discussion about product management without establishing the difference between functional and technical perspectives. Taking a functional perspective means observing something based on it’s exterior characteristics or how it functions (like a customer does). One can have a deep functional understanding of an object or piece of software without knowing much at all about how it works “under the covers”. For example, I know how to use my laptop but can tell you very little about specifically how it stores data, displays images on the monitor, communicates with a wireless network etc.

By contrast, the technical perspective involves understanding how something works. Someone with a technical perspective sees my laptop as a set of interconnected components leveraging several different technologies to achieve some end.

The distinction between these two perspectives is critical to me because I believe that in the context of a software product, there should be separate accountabilities for each perspective. That means making one person ultimately accountable for the functional view of the product and another accountable for the technical view. In practice, people like software product manager and UX professional are responsible for defining what should be built. Development should be concerned with how to build it. While there is often a gray area between what is purely functional and purely technical, understanding the difference between them can help avoid conflict between functional and technical professionals by providing a framework for sensibly dividing labor and accountabilities. 

Pile 2: The why, the what and the how

We can assess virtually any activity in terms of why we’re doing it, what we should do and how we are going to do it. This paradigm is often referred to as “they why”, “the what” and “the how”. “The why” refers to our motivation for doing something (like building a product). I believe the why is the domain of software product managers. “The why” is often captured as a vision or strategy. “The what” describes what it is we will do or build. SPMs, with the help of UX and other functional professionals, are responsible for defining what a product should do. “The what” is typically captured in requirements, feature specifications and roadmaps (among other artifacts). “The how” represents how “the what” will be implemented. Technicians like developers and architects should be responsible for “the how” and given the freedom to make decisions regarding implementation. Both “the why” and “the what” can be though of as being functional in nature. “They how” is clearly technical (see Pile 1).

Understanding this paradigm can help you avoid the tendency (particularly in software) to immediately jump to “the how” based on some rough idea of a requirement without making sure we do due diligence on “the why” and/or “they what”. This “race to code” often results in features that don’t adequately address stakeholder requirements (although they might look great and function well). 

Pile 3: Requirements vs Features

I’m consistently amazed at how often the terms “requirement” and “feature” are used interchangeably. The distinction between these concepts is fundamental to product management

• A requirement is a statement of need. Period. “I need a place to put my cup while driving that will prevent it from spilling its contents.” is a requirement. It cannot be tested. It simply is. Requirements can be decomposed into almost infinite levels of details. For example, I might extend the “cup requirement” to include the size of cups (specified in centimeters of width)
• A feature is a characteristic of a product from the perspective of someone observing it. Features meet or satisfy requirements. For example, a cup holder could satisfy the requirement stated above. Features can be specified (described) and implemented (so they can also be tested!).

If we consider software product development artifacts, a single entity called a requirement may contain the statement of need and some level of specification regarding the feature or features that will satisfy it. Regardless, understanding and respecting the conceptual difference between this terms has important implications for SPMs. In general, SPMs should gather requirements from stakeholders, avoiding feature requests. Understanding what people’s needs are rather than how they imagine their needs being fulfilled allows SPMs to conceive of creative solutions to customer problems that also support other product goals, like minimizing the cost of development. In the future, I’ll write a post dissecting the use of requirements rather than features as the “currency” in interactions with stakeholders.

It is very likely that I will refer to these piles in future posts and very likely elaborate on them. Do you have piles of you own you can share?

About this blog

Welcome to the SPM Intersections blog! Although I’ll cover many of the basics of software product management (SPM), I’ll dedicate many posts to exploring the intersection of SPM with related areas such as Design Thinking, innovation and Lean.

I’ve been doing product management since 2000, mostly at very large companies (IBM, Microsoft and SAP). I’ve seen a lot of things done right in my career and, truth be told, many things done wrong. I believe my experience has give me an interesting (if not unique) perspective on software product development. I hope you agree!