Lessons for Product Managers from Cannon Films

I recently watched an entertaining and informative documentary on Cannon Films, a movie studio responsible for some of the most questionable cinematic endeavors of the early 80s. Films such as the "Death Wish" series,"Breakin’, Breakin’ 2: Electric Boogaloo", and "American Ninja" sealed this firm's reputation as purveyors of possibly some of the worst motion pictures ever released. While watching this fascinating story, I realized that I interpret almost everything I see and hear in terms of product management (sad but true!). In this case, the parallels with my chosen career were surprisingly obvious. Here are a few product-related lessons and insights driven home by "Electric Boogaloo: The Wild, Untold Story of Cannon Films".

Sell first, develop later
Cannon would sell a film to international distributors before they shot the first frame. While obviously risky, I've found myself doing the same thing with courses I've developed. This principle of ensuring a viable market before investing in development is an approach that should guide virtually all product development.

Make a powerful emotional connection with buyers using simple collateral
Menahem Golan, chairman of the board, would often secure international sales for unmade movies by developing a poster that could make an emotional connection with buyers. His strong personality and charisma notwithstanding, the ability to concisely represent the value of a product (whether it exists or not) is a skill every product manager should hone. I've previously written about one approach to doing this by writing a press release for a software release before development starts.

Empathy for your customers is crucial
During its most infamous period, Cannon was run by a couple of entrepreneurial Israelis who, while successful in their homeland, probably lacked an adequate understanding of the American movie-goer to be successful in this competitive market. This lack of empathy made decisions on subject matter and trade-offs between quality and budget constraints precarious at best. The result was inexpensive movies that, over time, became a joke in the industry and with audiences. We as product managers must continually make the same types of trade-offs so must have deep empathy for our product's stakeholders, especially customers.

Speed is no substitute for quality
Again and again, Cannon sacrificed quality in an attempt to get products out the door as fast as possible, often in response to competitive pressure. While a healthy company can withstand one of the mistakes every few release cycles, there is no getting around the minimum quality bar expected by the market.

Follow your passion
Despite their missteps, all who knew Golan recognized his absolute passion for movie making. Whether directing or running the studio, he worked tirelessly to make movies that he hoped would entertain the masses (and make him massively rich!). There is no doubt in my mind Cannon Films managed to survive as long as it did to a great extent due to the "power of passion". It makes me wonder about the impact they could have had if they hadn't suffered from some of the other challenges enumerated above.

In closing, we product people have a lot to learn from industries outside of our own. I would say the points above apply to virtually any product. Do they apply to yours? What is your favorite Cannon Films creation?

For more information on my consulting, training and coaching services, please see my site.

Future Trends in Enterprise Software Product Management

It's the time of year when we become inundated with articles and blog posts about what we can expect in 2016. Some brave folks even make predictions, something I am loathe to do as, let's face it, they will be wrong and nobody will remember I made them by the middle of February. Here's a list of topics I see impacting software product management in enterprise shops in the next few years (I believe there's no shortage of similar start-up-centric discussion these days). In the interest of brevity and to stimulate discussion, some of these points are made more "matter of fact-ly" than is probably appropriate. I'm looking forward to others' chiming in.

Internet of Things and SaaS
From a technology perspective, IoT and SaaS will continue to change the way product managers work and think. One might assume that these trends are reaching saturation based on the amount of ink they're getting in ICT press. One would be wrong. There is still a huge number of product managers that haven't yet made the leap to these new technologies/approaches or the changes they will inevitably bring to our profession.

Lean Startup in the Enterprise
Lean startup thinking pervades the startup world but is still somewhat foreign to more traditional organizations, especially the really big ones. In the next year or two, we'll see these concepts evolve and mature, becoming more prominent in "big shops" (not that they're entirely absent now). Radical ideas like "learning" being a reasonable objective for an early release will gain mainstream traction and we'll see some conspicuous success stories attributed to Lean Startup thinking in big shops.

Business-minded Development
The next few years will see more and more organizations investing directly in ensuring their engineers understand the business implications of their work. This knowledge will help them build solutions that better meet customers' needs and are more flexible over their lifetime. It will also increase the conflict in many organizations regarding who defines the product and where the line of demarcation between development and product management lies.

Subscription Fatigue
For enterprise vendors weary of their customers' slow, arcane capital investment processes, the recurring revenue that comes from a subscription model was as close to a blessing as one can expect in the software industry. However, both the consumer and enterprise markets are beginning to suffer from "subscription fatigue" as individuals and organizations take stock, adding up what they are spending on software every month. We will see more companies offering traditional pricing models to differentiate themselves from the subscription soup we are beginning to drown in.

Beyond "Pure" Scrum
Scrum has clearly reached a saturation point in the software industry. Over the next few years, we will see reinterpretations and extensions of Scrum become even more prominent in the enterprise, with proper methodologies filling in white space left by Scrum's "framework". Approaches to scaling Scrum that help resolve charter conflict on development teams will get the most traction.

Addiction to Data
Delivery of software products via the Web has created an unprecedented opportunity to gather information about usage, primarily because users are blissfully unaware that their every click is being tracked! Understanding how to define, gather and analyze this usage data will become a critical competency in the enterprise. Beyond up-skilling both functional and technical roles in this area, organizations will have to be careful not to abandon other valuable channels for gathering user feedback, e.g., (snark alert!) actually talking to them.

The Role of Design
Over the next few years, we will see the role of design as a discipline evolve in software product development. To paraphrase Steve Jobs (as so many of us are wont to do), it's not just about how it looks: it's how it works. Design is a science with quite a history that, to a great extent, has been applied only superficially (literally) in software development. The ascendancy of design will create yet more confusion regarding accountabilities on product teams, e.g., where does UX design end.

So what do you think? Are these trends relevant in your situation? What have I overlooked?

You can find out more about me and my training and consulting services on my site.

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.

The critical accountabilities for product management effectiveness

I've written previously about product managers in name only, PMINOS. I would like to elaborate on those thoughts, this time focusing more at the organizational level. As part of my consulting practice, I regularly engage with software product organizations that have allocated product-related accountabilities in a way that I consider suboptimal. These experiences prompted me to describe the accountabilities I consider critical for product management to have the influence they should on the product business and life cycle long-term. To have an impact that significantly increases the long-term chances of product success, software products should have a product management function that unites accountability for:

• understanding customers and markets ("external perspective")
• defining and ensuring execution of product strategy
• operational oversight of development work outputs

Although some may consider the first point obvious, some organizations explicitly divide inbound and outbound perspectives in such a way that product managers spend little or no time talking to external stakeholders. I believe it is impossible to develop adequate empathy for stakeholders without direct exposure. Regardless of how tight the collaboration is with other professionals who engage with external stakeholders, PM cannot develop necessary customer understanding by proxy.

The definition and execution of product strategy may also seem like an obvious accountability to many, especially those in smaller product organizations. However, it is not at all uncommon to find product management organizations that are so overwhelmed by tactical challenges that they fail to define a compelling, explicit product strategy, leaving others to infer what they can or enabling others to define it for them. In terms of defining a strategy, I use the OMG Business Motivation Model as a reference model. It's worth noting that a lack of understanding and empathy for external stakeholders results in a strategy that is, put mildly, unlikely to increase the chances of commercial success. The product roadmap is the most practical expression of vision and strategy to all stakeholders. If PM doesn't own the roadmap, I would content there is no way for them to have the impact they should.

Operational oversight of development work outputs is a perhaps an overly fancy way of saying that someone with a strategic, customer-focused perspective needs to continuously engage with engineering as products are being developed to ensure the final product (or incremental product, for that matter) reflects customer wishes and organizational vision and strategy. Communicating insights regarding customer or market needs and educating engineering on business motivation in no way guarantees that development will stay on track as they, in good faith, set about developing complex products. Effective product managers spend a significant amount of their time assessing the work product of development and facilitating corrections as necessary. Offloading all oversight to a product owner who reports to development is a mistake that will eventually compromise execution strategy.

So there you have it, from an organizational perspective, leadership committed to long-term market success must ensure that these accountabilities are united in a healthy, empowered product management function. Would you agree? Is product management properly enabled in your organization? You can find more information on my offerings, including software product management training, on my site.

Reflections on (almost) a Year of Teaching Product Management

2015 is the first year that I delivered a software product management course that I developed. Aside from practical lessons in "instructional design"  and course promotion, experience with a multitude of students, both in public and "in-house" trainings, has given me insights into commonalities in PM experiences across countries, industries and company sizes and some surprises about the content that resonates most with folks.In terms of shared experience, it's clear to me now that most product managers are so mired in operational concerns that they've lost the reflex to take two steps back and think strategically. It's extremely gratifying to see people in the relative quiet of a classroom begin scribbling notes about strategic aspects of running a product they probably hadn't thought about in some time. Since most of my students were European, where product management maturity lags the US, it was also interesting to see them realize that they should be playing a clear leadership role in their organizations (and that no one will simply hand them that charter).

When I designed the course, I was concerned that participants would quickly become bored with theory, preferring insight on operational aspects of being a product manager. What I've found is that most practicing product managers have found their operational rhythm and can expect, at best, incremental improvements in this area. Much to my surprise, discussions about formally capturing "business motivation"  (vision, mission, objectives etc.) and aligning it across the organization generate much more discussion than approaches to release planning or managing requirements. This was a pleasant surprise as I believe thinking strategically is what separates most great product managers (and maybe professionals in general) from the rest.

BTW, at the "meta-level", I was surprised at how much value highly experienced software product managers got from an intensive three days of thinking about their job holistically. It turns out that this broad perspective (based on the ISPMAFramework) reminds them of aspects they don't typically think about and allows them to self-organize their accountabilities and priorities.If you're a practicing product manager or thinking about joining this profession, consider taking a course, even if it's billed as "basic" or "foundational". Getting out of the office and spending some time with folks who are facing similar challenges can be a great investment of a few days.

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