Welcome to Product Management Challenges!

03029 That Sisyphean Task of Change

Some of you may be familiar with Sisyphus, the Greek king who was punished in the afterlife by being condemned to roll a boulder up a hill. Whenever he neared the top of the hill, the stone would roll all the way back down to the bottom again.

For those Product Managers who are only just now learning about Sisyphus, you’ve probably bonded with him already, right? Sometimes it seems like product management amounts to pushing a boulder uphill, only to find you’re back where you started.

Today’s topic is designed to be a little encouragement to Product Managers who are dealing with the tough task of getting things to change - because that’s their job, basically - in a world that doesn’t want change.

It’s always so much easier to provide advice and encouragement from the sidelines than to stay enthusiastic when you’re knee deep in the mud and trying to slog ahead.

So take a look at the words of wisdom below every now and then when you need a little cheering on.
(more…)

03028 Clarifying the Why of Requirements

(Today’s issue has a fun challenge question that demonstrates just how much the software industry has changed in the past 20 years. See Can You Answer This? below.)

Requirements are the fuel that Product Managers produce to feed the company’s software development engine. As part of refining the quality of those requirements, it’s helpful to understand that requirements don’t all serve the same purpose.

In fact, there are different types or categories of requirements, designed to obtain different types of results. For example, some requirements dazzle prospects during demos, although they are rarely implemented when these same prospects become customers (yet they became customers partly because of those dazzling features). Others represent solid new functionality that will be used to the hilt.

When presenting a requirement, Product Managers benefit from clearly determining its purpose and discussing it with the team. A clear understanding of the goal of the requirement reduces debate and confusion when it is being designed and implemented.

It’s a balancing act to include requirements from all the various categories, yet that’s exactly what is necessary to ensure that you don’t neglect an important aspect of the product as you improve it.

As the Product Manager, you are in the position to develop requirements that reflect the goals of the entire company, assisting its ability to sell, ability to deliver, and ability to service the product. Amid the advocates from individual departments like Marketing, Engineering, and Sales, you may be the only one who makes sure the entire company’s needs are represented in the product.

Read on below for a discussion of the various categories of - or reasons for - requirements.
(more…)

03027 Requirements: Envisioning the Product

With product requirements, one temptation a Product Manager has to fight is the desire to jump into the details. You already know what you want, lord knows you’ve heard what people want often enough, someone’s got to actually put them on paper, and that someone is you, so you might as well get started.

But there’s an important step to requirements that you as the Product Manager must facilitate with the executive or management team. This takes place before getting into detailed suggestions from the market, sales reps, consultants, etc.

I haven’t really heard anyone give a name to this. It’s like a Requirements Executive Meeting. Perhaps “Envisioning Meeting” would be the best term. Its purpose is to have a panoramic discussion of the product, one that takes into account all the different departments and functions the product touches.

The Envisioning Meeting is not about developing a product vision, nor is it the creation of a product road map. It’s about having a thorough discussion between all members of the management team about what is needed - or what might be needed - by each department.

The goal of holding an Envisioning Meeting is to have a product that is designed to be good for the company, not just one that sells well. What I mean by that is that it’s vital to make sure that the product does not neglect a critical function of the company in a way that costs the organization.

Say the product has great new capabilities with each release, but the installation process isn’t automated. It’s a time consuming and money-losing activity draining the profitability of the company.

This is where the Envisioning Meeting serves as the place where Professional Services can address this with the entire team. Read on for some ideas on holding an Envisioning Meeting.
(more…)

03026 Losing the Battle to Win the War

Product Managers are tasked with managing a product. Yet they do not have control over the many departments who do the work of building, marketing, selling, and delivering the product. This means that Product Managers must learn to manage by influence.

For Product Managers, having to manage by influence can lead to a mindset where they view every project on their list of product goals as a war where they must outsmart, outflank, and outlast other managers and departments in order to prevail.

It’s important for a Product Manager to prevail, not for the pleasure of it - although like any job it can be a source of great pride to see your personal stamp on the product - but because the Product Manager is approaching the product from a broader perspective than any single department. Ensuring that this broader perspective gets reflected in the software is critical to the product’s success.

But it can be a problem when you develop a war mentality.

Sometimes the only way you will prevail and benefit over the long term - winning the war - is if you give in on some points in the short term - losing the battle. Read below for some questions to keep in mind to judge whether the battle you’re fighting is worth the victory.
(more…)