Being an effective product manager means saying "no" to more than scope

It's a well-worn truism that great product managers, perhaps more than other disciplines, need to know how and when to say "no". Typically, this "mandate to negate" is discussed in the context of product scope. Indeed, telling stakeholders (not just customers) that they won't get what they want when they want is as important as it is difficult. However, in this post, I'd like to explore a few areas in which "no" is just as important but that don't get the same press as "scope no".

Say "no" to "denial of service" scheduling

As product managers, we can get pulled in multiple directions by stakeholders who aren't even aware of each other. Our central role and broad accountabilities may lead us to believe that we need to be involved in all aspects of the product, business, functional and technical. I learned the hard way that the inability to regularly perform "brutal triage" on requests for your time can unleash a chain of events that undermines your credibility quickly and disastrously. A few tips:

• You can't be involved in everything. Having someone else, even from another organizational function like engineering, represent you, even at customer-facing meetings, may help others develop and allow you to focus on more critical immediate priorities.

• Look at your schedule every day and mark-up the meetings/activities that are strategic in nature. If you're not doing something strategic almost every day, there's a good chance you've been sucked into an operational death march at the expense of what your core competency should be: defining and driving product strategy.

• Be prepared to show clearly the opportunity costs involved when you have to resolve scheduling conflicts. Most of us have honed a similar skill when it comes to adding scope to a release ("OK. Now let's discuss what drops out.")

• Keep track weekly of roughly how much time you spend on key initiatives and make sure your investment is commensurate with their importance.

Say "no" to other professionals who expect you to do their jobs

Lots of lip service is paid to product managers' standing up and doing whatever's necessary to ensure product success, including doing marketing, support, sales or whatever else is required in a given situation. While these heroics may indeed be necessary from time to time, given the workload of all the product managers I know, consistently picking up the slack left by other disciplines is a recipe for disaster. Much better is to clearly articulate what you expect from these people and organizations and work with these other functions and their leadership to secure the necessary commitments. If these negotiations don't bear fruit, be prepared to articulate the impact of this work's not being done. In this unfortunate case, prioritize the gaps and do what is reasonable to fill them, never forgetting that neglecting your core duties to compensate for lack of organizational interest or investment is yet another (typically even more painful way) way to fail.

Say "no" to forgoing your life for your job

This one obviously isn't specific to product managers (perhaps the others aren't either). One thought that helps keep my priorities straight with respect to work/life balance is the realization that my grandkids won't care a bit about the projects I delivered during my career. Truth be told, there's a really good chance that I won't either! How much of yourself you give to your job and how much you give to the rest of your life is, over time, a decision.

What do you think? What other "dimensions of no" can you think of?

See my site for more information on my consulting and training services.

Titles related to product management matter and should reflect accountabilities

I enjoyed Hans-Bernd Kittlaus's blog post on titles ("names") and their significance (as I do most of what Hans-Bernd writes!). It turns out this subject is very topical with me as this question inevitably comes up when I'm working with consulting clients. My personal theory is that titles are important, but clear accountabilities in the organization are critical. When you consider that I believe that titles should reasonably reflect accountabilities, it becomes apparent why I recommend that software organizations not take this topic lightly.

I can remember in the 90s there was a brief trend to give oneself unconventional titles like "CEO and Bottle Washer" or "Chief Inspiration Officer". This relatively short-lived fad underscored one of the most important functions of titles: to communicate to internal and external audiences what you do (note the previous counter-examples).  Industry-standard titles like "product manager" or "solution manager" compensate with utility for their lack of sex appeal. These titles, however, beg more fundamental questions: What is a product and what is a solution?

I am consistently amazed that so many organizations that I encounter have no clear definition of what they take to market. I wrote an entire post on this topic almost a year ago, in which I proposed the following simple taxonomy:

• 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

I am a firm believer that from a functional definition perspective (product managers functionally design their product), it pays to be clear about your accountabilities. Are you defining a solution? Call yourself a solution manager or something similar. Same goes for products.  BTW, you should think about what you take to market from the perspective of you consumers. Even though a SaaS offering could be considered a service from a technical standpoint, per the definitions above, it is more likely to be considered a product by its consumers.

Does your title reflect your accountabilities? Do you have to explain what your really do every time you give someone your business card? Does the taxonomy I've proposed resonate with you? You can find out more about me and my offerings on my site.

SPM Intersections Video Blog: Is PM in the driver's seat?

You can find out more about me and my offerings on my site.