Welcome to Product Management Challenges!
Welcome to real-world advice for software product management! Subscribers have access to a treasure trove of over 100 articles covering the full range of topics that a product manager must master. Start your paid subscription to this unmatched content by clicking Subscribe to the right, under Log In.
I am attending Product Camp in NYC and have proposed a mini-workshop about applying risk management to your product. Attendees at Product Camp vote at the beginning of the event to select which proposed sessions will be presented. In the interest of providing a little more details about risk management and some of what I’ll cover in my workshop, I am sharing with you the article-in-progress below.
Applying Risk Management to Your Product
Lucky you! You could be reading an article about any number of fascinating topics – like Going Social With Tweeting Product Personas, or How Facebook Will Make Your Life Fun, Easy and Rich – but instead you’re reading about risk management. Lucky, lucky you! Risk management is a topic that somehow manages to strike people as both scary and boring at the same time – no easy feat. Go to a party and strike up a conversation with someone who tells you they do risk management. Feel your face fall. You’re sure you’re in for a dull conversation, something about bean counting and actuarial tables, maybe even life insurance? Will the conversation include the words “Have you thought about what would happen if you were to die tomorrow?” “Time for me to go refresh my drink,” you say.
But managing risk gets right to the heart of managing a product and the company which makes that product. It is the language of investors (shareholders, angel investors, and venture capitalists). It is also the language of executives and corporate governance, and because of this, it’s in your best interest to learn how to speak the language of risk management in order to be heard, understood, and effective at that level.
Scary and boring, you say? Well, I aim to change your mind. Risk management is too important for you to simply avoid for the rest of your working life. The good news is that it can be fruitfully applied to projects and products of all kinds. Once you go through an exercise in risk management, you go from scared and bored about risk – a heart beating too fast and a mind that is sluggish – to calm and engaged. And you’re ready for the curveballs that might come your way.
Read on for 10 Steps to a Risk Assessment.
Product Management Challenges now has over 118 articles on software product management, software requirements, technology marketing, software development, competitive analysis, product pricing, and more. Your subscription gives you easy access to this content whenever you need guidance on a specific topic.
My experience with Product Management has been one of trying to take the best ideas, and best practices, and applying them to each aspect of my job. It has involved lots of hard work. Yet with those top ideas and hard work, it seems as if it remains just as difficult to achieve results each time. With each time, for each release, with each marketing campaign, the results seem to have been just as vulnerable to failure.
Some of this ongoing difficulty is no doubt due to the downside of the flexibility I so prize. I have found that successful Product Management requires a generous portion of flexibility as a Product Manager moves from one product to another, and from company to company. Without the flexibility to adapt methods and processes to each new situation, Product Management becomes an exercise in forcing one’s will on a very unwilling organization. The negative momentum that results from such forcing can derail the results of a Product Manager’s most rigorous efforts.
Over the years I have gained experience with different products and organizations, and seen successes and failures through several attempts to help build flourishing businesses around software products. I have come to realize that there is a whole aspect to successful Product Management that is separate from, and in addition to, the many piece-meal strategies and tactics that I employ as a Product Manager. That aspect is the concept of a program approach to Product Management.
I have the Disaster Recovery and Business Continuity industry, the industry for the product I currently manage, to thank for introducing me to the program approach. The leading thinkers in Business Continuity Management advocate taking a program approach. Such an approach involves an ongoing effort that builds continuously on the previous years’ efforts.
By following a program approach, a Product Manager can tie together all the necessary and disparate efforts — product design and development, marketing, sales, delivery and service –- into a unified whole. By driving a program, a Product Manager can overcome some of the barriers to reaching common and very important Product Management goals.
Read on for an introduction to the program approach to Product Management.
Using references to talk to your prospects and endorse your software product can be the most effective way to close a sale and cut the length of the sales cycle. They reassure your prospect that his or her impending decision isn’t too risky. For large purchases of business software, references are the equivalent of the much-sought-after word-of-mouth marketing for consumer products.
But cultivating and using good references can be one of the most challenging tasks you may ever face. There are a number of barriers which get in the way of building a good stable of solid references. Read on for some pointers on how to use customer references to your full advantage.
In today’s issue I’m going to write about something that is near and dear to my heart, something that I have found tremendously helpful working with customers to implement new software and working on my own and with teammates to make important things happen. It’s a way to understand the psychological stages which you – and everyone else I have ever met – go through when you work on a major new undertaking such as buying and implementing a software product. I call it the Four Phases of Implementation.
The Four Phases of Implementation is by no means my original idea. I first read about it in a book about proposal writing, I believe, and I believe the author did not claim the idea as his own. Rather, he was passing along an idea that was widespread. I, however, had never heard it before, and have found it extremely helpful ever since.
I have found the Four Phases of Implementation to be so useful, in fact, that at my current company I started paying a visit to each and every class of trainees in our product for the express purpose of describing the Four Phases. I know that by imparting this information to my customers, I can help them better work through the implementation of our software product. Not only does it help them directly, but I charge them with taking the Four Phases idea and walking their teammates through it when they get back at the office, all in the interest of making our product easier to adopt and making its implementation more successful.
Read on below for a description of the Four Phases of Implementation.
Again and again, I see organizations struggle with requirements, that component of making software where the needs and desires for new and changed capabilities are defined and handed to Development to build into the product. The challenges stem from one or more important misconceptions about requirements. These misconceptions in turn prevent the team in various ways from providing, creating, selecting, or transmitting requirements so that work can begin on enhancing the product.
Read on for a discussion of ten common misconceptions about requirements that hold organizations back from good requirements and more effective product development.
With the holiday season upon us, I can’t help but think about what every Product Manager needs and wishes for in order to watch their product succeed and to flourish in their career.
Watching your product succeed provides plenty of gratification, and the success of the product rubs off on the Product Manager. Such wishes as Everyone’s Bright Ideas and Quality By Default aim at product success.
But it’s also important for a Product Manager to attain direct career success, sometimes despite the environment. That’s the reason for wishes such as A Guiding Light and A Measure of Success.
Read on below for A Product Manager’s Wish List.
Companies strive hard to create new software products that address an unfilled need in the market. When a product hits the mark, it enjoys success, and if it goes beyond innovative to transformational, it becomes an unqualified success. Just about every company and Product Manager hopes for such a product, one that brings in customer accolades, sales and profits.
What makes a product transformational is that it doesn’t just help people do their old job better. Rather, it lets people do their job in a whole new way. A transformational product comes with ideas for great new ways of doing the job, ideas which are built right in, so that the software reflects new approaches and best practices.
The new approaches and practices are woven right into the structure of the product, and reflected in specific capabilities. When customers buy your product, they are buying not only the software but also the built-in guidance, your company’s thought leadership.
But building thought leadership into your product presents an added challenge for customers who are faced with learning both a new tool and understanding new ways of doing their work. It can add a degree of difficulty to the implementation of the software that can threaten the whole project’s success.
Read on below for bright ideas and lessons learned about what is involved when you have built thought leadership into your product.
We’ve all heard of the “No job too small” attitude, where a person considers nothing beneath them or too trivial to tackle as part of getting their overall job accomplished. Well, it seems to me that Product Managers have to deal with a very different challenge, the “No job too big” issue, where it seems as if the Product Manager position has been defined to cover the scope of three, four, or five full time jobs. Product positioning? Marketing collateral? Sales tools? Demos? Requirements? Release planning? Quality Assurance? No job is too big for the Product Manager to tackle!
This means that a Product Manager is faced with a truly challenging situation. How can anybody possibly cover all the ground that needs to be covered? Is it a setup for failure?
Yet there are ways to deal with the “No job too big” challenge that Product Managers have used, consciously or not, to manage to do their oversized job successfully. Read on for some ideas about how you can accomplish the Product Management mission despite the fact that it seems entirely too much for one person to fulfill.
The previous article on Improving Product Performance must have hit home, because I received more responses to it than any other issue. This reinforces my belief that product performance is an area where there is very little guidance out there.
Not only do developers struggle with performance and scalability, often flying blind, but it spills over into product management, where it’s a struggle to figure out where performance issues fit in with the product roadmap and requirements.
Readers made some valuable points and asked some useful questions, and so today’s article provides a little more about improving product performance so that your software remains competitive.
Many thanks to those of you who wrote in!