Extreme Product Management

By Barbara Nelson, Stacey Mentzel

How to deliver products people want to buy in an agile development environment.

Rate

[PDF]
Definition of Extreme Product Management (XPM): XPM is using the minimum process and creating the minimum artifacts to deliver products people want to buy.

Writing this article feels like a development project. We are buried in the details. We each have hundreds of user stories in our heads on 3x5 cards. Some are related, others are not. Some are from personal experiences, others are from interviews and discussions with product managers. We could take an agile approach and just start writing content for each card. That’s basically what we’ve done. But so far, it isn’t readable by anyone but us. To further complicate things, we are writing this article together, have not seen each other in a few years, have only spoken a couple of times, and live on opposite sides of the country. In order to turn those user stories into a coherent article, we need some organization. We use FreeMind, a mind-mapping tool. Before you know it, we have almost as many nodes in FreeMind as we have user stories.

Minimally, XPM needs to define:

  • What problem are we trying to solve?
  • For whom are we trying to solve the problem?
  • How pervasive and valuable is solving the problem?
  • What is our vision of the solution?
  • What context do we need to communicate to drive the solution?
  • Can we solve it in its entirety or can we take a phased approach?

An overriding principle is that the solution has to be practical. As we implement, we move from more general to more specific. Here goes.

What problem are we trying to solve?

One of the biggest challenges today for product managers is clarifying the role of Product Management. In software companies, this is especially challenging as Development teams are adopting more agile or iterative development methodologies to meet the increased demands to develop more code faster. Where does Product Management end and Development begin?

The strategic role of Product Management is president of the product. Running the product as a business. Taking a market-driven approach to product management. Making decisions about the product to increase adoption across the market, delight customers, and ultimately deliver profitable products. Even if your product is “free,” it should contribute to profits somewhere in the company. This is what we mean by Extreme Product Management. Staying focused on the point. What is the single overriding point of what we do?

But instead of being “president of the product,” product managers often feel like “janitor of the product.” Cleaning up after everyone instead of leading the team. Picking out icons, writing error messages, answering 30 questions a day because the developers don’t want written requirements.

Product managers say:

“My developers are using Extreme Programming and it is creating chaos.”

“My developers want me available every minute of the day to answer their questions. I have no time to visit customers.”

“I’m being asked to rewrite our user stories to fit the sprint.”

“The developers are delivering code every two weeks, but it doesn’t seem like we are making any progress towards delivering a useful product.”

“My developers are being told to watch out for the product manager. What is my role in agile development?”

“It seems like agile development is the unionization of the developers. Resource allocation is done based on a 40-hour work week. Why am I putting in 60-70 hours a week to make this work?”

“How can I market a product when I have no idea what will be in it or when it will be available?”

In fairness, we also have to listen to the developers and why agile methodologies have sprung up in the first place.

Developers say:

“Product managers keep changing their mind. The churn is killing us.”

“We’re being asked to stop what we’re doing to respond to the deal of the day. We’d get something done if you’d just let us finish what you already asked us to do.”

“I have no idea what the product manager is asking for. Flexible and scalable are not requirements!”

“If the vision is going to change every quarter, what good is the vision?”

“Market Requirements Documents are so eighties. We’re agile.” [Translation: “We don’t need no stinkin’ requirements!”]

“How can I estimate how long something is going to take when I have no idea what I’m being asked to do?”

“We’re tired of getting beaten up by management for not meeting our dates. How can we be blamed when the target keeps moving?”

“It’s about time we took back control. Product managers don’t know what they want.”

Angst. Frustration. Conflict. Mistrust.

Let’s get back to basics here. What is the real problem? On the surface, the problem seems to be that Product Management and Development are each trying to wrestle control from the other. Product Management is frustrated at what appears to be a lack of commitment from Development. Development is frustrated because Product Management won’t commit to what they want and keep changing their minds. Even customers don’t know what they want.

Stop!

The real point of all of this is to build products people want to buy. Ultimately, we’re on the same side. Ultimately, we all want successful products that help us all make lots of money.

For whom are we trying to solve the problem?

There are a number of players or “personas” in this situation. But to bound this problem to fit into an article and not a book, let’s keep it simple: product managers and developers. (Yes, there are many roles in Development. Stay with us.)

How pervasive and valuable is solving the problem?

Every week in the Pragmatic Marketing product management seminars, a show of hands often yields 30-40% of the students struggle with what their role is in agile development. XP and other agile development methodologies have been enthusiastically adopted by multitudes of development teams in an attempt to address the problems of developing software. (On the surface, to someone not involved in software development, building products doesn’t look that hard. What’s the big deal? It’s just code! And yet a Google™ search of “software development challenges” yields 179 MILLION hits!)

Page 1 / 5

About the Authors

  • Barbara Nelson

    Pragmatic Marketing, Inc. has continuously delivered thought leadership in technology product management and marketing since it was founded in 1993.Today, we provide training and present at industry events around the world, conduct the industry’s largest annual survey and produce respected publications that are read by more than 100,000 product management and marketing professionals. Our thought-leadership portfolio includes the Pragmatic Marketing Framework, e-books, blogs, webinars, podcasts, newsletters, The Pragmatic Marketer magazine and the bestseller “Tuned In.”

    To learn more about our courses and join the growing international community of more than 80,000 product management and marketing professionals trained by Pragmatic Marketing, please click here.

  • Stacey Mentzel is a Director of Product Management at Business Objects, within the Enterprise Information Management area. Stacey has more than six years of experience in Product Management, along with experience in Product Testing. Contact Stacey at Stacey.Mentzel@businessobjects.com




Post a Comment

Comment

Allowed HTML: <b>, <i>, <u>

0 Comments