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?

Key to a better 2015? Pay yourself first.

I posted this on LinkedIn and figured I'd post it here too.

I've recently found myself frustrated by my lack of progress on several long-term goals. For example, I desperately need to improve my German (I live in Germany!). Learning a language is the kind of project that requires steady progress over a significant period of time. I have similar goals around working out, running, playing guitar, blogging etc. With all these activities, I'll make steady progress for some period of time and then get off track. I'm probably the only one that's experienced this. :)

Recently, my subconscious gave me a nudge that's helped me do a better job recently of staying on track. It (my subconscious) obviously has access to memories that have long faded from my conscious mind. This memory is about 20 years old, going all the way back to my short stint as a financial planner after I graduated college. Selling things like life insurance and mutual funds to my peers, folks used to quickly burning through all their money or saving it in a jar, requires a very simple set of messages or aphorisms to elicit a change in very myopic habits. One of my favorite little gems is that if you want to accumulate (save) money, you need to pay yourself first, i.e., before you pay anyone else. The idea is to determine how much you want to save every month and put it into a savings account (or an investment) before paying the electric bill, your landlord or the cable company. It seems very simple and perhaps obvious, but I've seen this simple approach change people's behavior for the better on several occasions

The applicability of this approach to other aspects of our lives should be fairly obvious. Every day I must do a non-trivial number of both personal and professional tasks for a plethora of folks, so much so that I sometimes (most times?) find myself with insufficient time to make progress on the aforementioned, longer-term goals.

I've recently changed my approach to these long-term goals to ensure I make progress on them before I do all the stuff I need to do for others. As one of those rare (and annoying to most) morning people, I make sure I study a little German before I do anything else, no matter how critical reading that first e-mail seems to be. The same approach also reminds me to take time out during the day to make progress on other goals -- paying myself with an investment in myself before investing precious time in what others need. So far, so good. For a few weeks I'm making consistent progress and feel that now force of habit will help see me through.

I realize this isn't earth shattering insight, but as I learned when trying to sell life insurance to people for whom it wasn't exactly a burning priority, sometimes a simple message or idea can make all the difference. Might work for you too.

How will you pay yourself first in 2015?

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?