When a feature goes horribly wrong...

I recently Tweeted (@gprickril) that we product managers as a community need to be more forthcoming in sharing our failures. Somewhat ironically, today I'd like to discuss what I consider someone else's failure. Although this post may seem on the surface to be a bit negative, the idea is to start a discussion and learn something. Let's face it: we learn way more from failure than from success.

I'm following a software train wreck that I thought would be interesting to address while it's in progress. Since the early days, I've been a user of Google's Chrome browser. Back then, it was lightning fast and had a clean UI that I like to this day. I have the feeling it's lost a bit of its speed and even grace over the years, but it is till my browser of choice for 95% of what I do.

Recently, the folks at Google decided to radically "improve" the bookmarking experience. Overnight, what had been a simple, albeit unsophisticated, experience became a quasi-graphical head-scratcher that left me wondering how it had ever escaped from the development lab. Imagine my surprise when out of the blue I clicked the Star in the address bar to bookmark a site and the following appeared:

What followed was a counter-intuitive "filing" experience that even after weeks I hadn't quite mastered. It would take several pages to describe the specifics of the experience (a bad sign already) so if you'd like to see it, simply install Chrome. I was so indignant that I went to the trouble of finding the appropriate support forum to voice my contempt. Turns out, I was not alone. Unofficial stats posted by a fellow user revealed "472 posts so far: fewer than 10 in favour of the new bookmarks, 50 don't like the new version very much, over 400 detest it". There's now a steady trickle of comments coming in, virtually all of them negative.

Unfortunately, not only is the basic bookmarking experience hopelessly flawed, the Bookmark Manager was also "improved" to the point of virtual uselessness. The default view shows you a graphical thumbnail for each link displayed in a flat list of all your bookmarks. For reasons that aren't quite clear to me, bookmarks not in folders seemed to have disappeared. I'm not sure I will ever understand this design decision.

Although these words sound harsh, I can assure I don't use them lightly. In my mind, this feature (or really feature area), as well-intentioned as it may have been, missed the mark by about a mile. I have to assume there was some greater vision guiding this design that was completely lost on us poor users trying to get stuff done today.

In Google's defense, you can disable the new experience and return to your comfort zone, although it's a multi-step process. Unfortunately, it sounds as if Chrome updates overwrite this setting.

So what can we learn from this ongoing saga? Here are my key takeaways so far:

• Some features don't require much innovation, even if they're not particularly exciting on the surface
• Given the competitiveness of the browser market, I have real trouble believing that the Bookmark Manager was Chrome's biggest issue: prioritizing is everything
• The prevalence of mobile devices is inspiring folks to make everything graphical -- we shouldn't assume such a change always represents progress.
• Giving folks a choice about adopting radical changes can save a lot of good will. This is a lesson that Google is learning and Microsoft has learned painfully on multiple occasions, e.g., Office Ribbon, Metro UI in Windows 8.

So what do you think of the new Bookmark Manager? What are your takeaways from the tsunami of negative responses to it?

Software Product Management Training and Certification

Product management is one of those complex roles that has to be learned by doing. Every situation is different and the skills required can vary between countries, companies and products. However, getting a comprehensive overview of product management and learning from others, whether an instructor or your peers, can help accelerate your learning and bring things to your attention you might have otherwise never considered.

In this spirit, I'm offering courses on product management based on the International Software Product Management Association's (ISPMA) Foundation-level Syllabus. This 3 day course gives you the "big picture" on software product management and covers many of the key processes that generate value for product development teams. It also gives insight into effective collaboration or "orchestration" with the other "functions" like development, marketing and support involved in building great products. Like most courses, there are challenging exercises that allow you to apply what you've learned and connect some of the "dots" that you are undoubtedly already familiar with.

While training cannot replace actual practice, bringing these two together in an intelligent way can strengthen both your knowledge and practice, making you a much more effective professional. Taking a course also exposes you to other professionals with similar interests and challenges. If I think about the professional training I've done in my life, I would say that networking was almost as important as what I learned from the instructor.

My courses also offer optional certification, again based on ISPMA's approach. Passing the certification exam demonstrates that you understand what you've learned and shows others, including potential employers, that you are dedicated to growing as a professional.

In the coming days, I'll announce more public courses, primarily in Europe (where I live). I also enjoy giving these courses "behind the firewall" for individual companies and organizations. You can discover more about what I do on my site, www.prickril.com.

Promoting Product Management

In an earlier post, I described "product promotion" as one of product management's "Dimensions of Competency". I believe that although we're not marketing professionals, it is critical that we as product managers help get the word out about our products to external audiences such as customers, partners and analysts. In this post, I'd like to talk about an activity that is very often overlooked in product development organizations: promoting product management itself. Having helped strengthen and even implement product management multiple times, I've become keenly aware of the need in some (most?) instances to explicitly educate my coworkers about what product managers do and how we add value. As I've said before in this blog, what we deliver as product managers can itself be thought of as a product. What product manager worth her salt doesn't promote her product?

This idea may sound odd to those who work in healthy organizations with a well-established product management organization full of high achievers that have developed the referent power they need to drive their product's success. But imagine organizations that have a weak product management function or, even worse, lack one altogether. I've been a member of such organizations, fighting hard to establish our discipline only to discover that to many, it was still a poorly understood "stealth" role. I would add that I believe this topic is valid at some level for all product managers. The upshot is that tactfully making your contribution transparent to the organization is rarely a bad idea.

If your organization has recently rolled out or significantly strengthened product management, you should not rely on word of mouth or a "re-org" memo to educate others about what you do. Consider your key stakeholders, carve time out of your overloaded schedule and find a way to get in front of them personally to explain the basics: your role, your plans and how you'll measure success. I typically start with development, although, quite frankly, they typically have the greatest exposure to your work. Even so, you would be amazed at the misperceptions that can develop over time regarding what product management is or should be doing.  One approach is to ask for a slot in one of their standard meetings and clearly explain how you intend to contribute to the success of the product. Being aligned with development leadership is obviously an important prerequisite. Do the same with marketing, support and other important internal stakeholders.

Another approach is to schedule a brief meeting, perhaps 30 minutes, and invite virtually the entire product development organization. Create a 10 slide deck that that covers "the basics" (from above) and leave plenty of time for questions.

If your organization has a more mature product management role, don't assume everyone understands it. Regularly addressing people from other disciplines or even product groups face-to-face and sharing your challenges and successes can give these audiences a better appreciation for what you do. It also demonstrates a level of professionalism that will usually impress.

I also like the idea of having a wiki that provides transparency on the product management team and their activities. I've also resorted to hanging posters displaying goals, accomplishments and other interesting information in hallways to make sure product management's contribution was reasonably conspicuous.

I know many of you are thinking that nothing promotes product management like success in the market and I agree wholeheartedly. But I would still challenge you to provide others involved in product development with greater insight into your contribution via more channels and with greater frequency than quarterly revenue reports.

Promoting product management is an ongoing activity that you should actively pursue and manage -- just like promoting your product; the work never really ends. In rare cases, you may be making such a spooky contribution that your rock god status speaks for itself. The truth is, these situations are rare a primarily an illusion dreamed up by product managers who have gotten out of touch.

So what do you do to promote product management within your product development organizations? What experiences can you share?

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?