Yesterday we summarized “Reign Of Fire” In 10 Screencaps Or Less™. Now let’s extract a product management lesson from 2002’s most dragontastic action/sci-fi film.

One of Reign’s big conflicts is between Quinn (played by Christian Bale) and Van Zan (played by Matthew McConaughey). Quinn is trying to keep innocent people alive; Van Zan wants to kill the sole male dragon and drive the dragons to extinction.

The ongoing argument between Product Management and Agile Development is pretty similar, just minus all the incinerating.

To make sure we’re on the same page, we should first describe Agile Development:

The tenets of Agile Development are basically rooted in “uncovering better ways of developing software”. Their values are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

If you’re hearing a giant groan–that’s the sound of many traditional product managers responding viscerally to those thoughts. Frankly, it’s easy to see why: What we just described, to many PMs, sounds like complete CHAOS. And it could be.

When you boil things down, Agile Development seems to be a response to something other than just developing software. It looks like a direct response to ineffective management.

What’s ineffective management? Having engineers write documentation rather than code. Or having engineers generate time estimates for features that a) haven’t been thought out, so b) there’s now way anyone could reliably generate an accurate estimate on how long it will take to develop.

It’s easy to see how that kind of management could lead people to seek a different path, a different way to Get Things Done.

At the end of the day, the developers MUST make what the Product Managers have specified–that’s not up for debate. But that does put a greater emphasis and responsibility on the PM to make sure you’re doing a good job–both for the product, and also for your team.

If smaller iterations will help your team adapt to change more quickly, try it. If there’s a sense that there’s too much process or too much of a focus on perfect documentation, ease up on those things.

In Reign Of Fire, Quinn and Van Zan are most successful when they’re working together to defeat the dragons. They’re at they’re weakest when they’re competing for resources and working at cross-purposes.

Are product management and agile development natural born enemies? Not necessarily. Like anything you need to keep that balance: You need to complete the projects, and create product that meet the demands of your target market.

If pure Agile Development does that, great! If not, find another path together that leads where the product needs to be.

Remember: Keep the balance. Otherwise, someone’s going to be gobbled up by a dragon, and that’s no good for anyone.

Additional Resources

• Keep your mind open to agile product development
• Webinar: Living in an Agile World - The Role of Product Management When Development Goes Agile
• Agile development isn’t product management
• What’s Product Management like a Year after Implementing Agile?
• How Agile is Your Product Management?

How are agile development and product management balanced in your organization? Are they complementary or competitive?

“Reign Of Fire” is a 2002 sci-fi film about dragons taking over the world and humanity’s struggle to survive. Let’s summarize “Reign Of Fire”… In 10 Screencaps Or Less!™

< SPOILER WARNING >
Key plotpoints of this film are pictured below. You have been warned!
< / SPOILER WARNING >

Young Quinn Abercromby visits his mother at work. She’s the chief of a construction crew working on the Underground in London.

Proving that it’s never a good idea to dig TOO far underground, the construction works accidentally awaken an enormous, hibernating dragon which quickly kills everyone except for Quinn.

Over the course of twenty years, dragons (and nuke-happy humans) reduce the earth to a cinder. Quinn grows up to lead a group of survivors who dwell inside a stone castle in Northumberland.

A group of heavily armed Americans charges into town, led by Denton Van Zan. Although they don’t like or trust one another, Quinn and Van Zan agree to pursue the dragon that’s been threatening the castle and killing the crops…

… and cooperate to slay it.

Van Zan wants to recruit Northumberlanders into his army, to attack the only known male dragon. Kill it, and no new dragons can be born. Quinn disagrees. They wrestle. Van Zan wins and takes his army to fight the male dragon. The male dragon incinerates all but Van Zan and two of his soliders, then backtracks their trail and attacks the castle.

Quinn and Van Zan work together to save the people trapped in the castle and hunt down the male dragon.

When Van Zan’s plan is to kill the dragon with an explosive tied to a crossbow bolt fails, he takes a flying leap with an axe at the dragon. It doesn’t go well for Van Zan.

Quinn takes aim with his own explosive-tied-to-a-crossbow-bolt–and kills the dragon dead!

Months later, no new dragons have been reported and the existing dragons have eaten one another. Things are looking good!

THE END

Tomorrow, we see what “Reign Of Fire” can teach us about product management and agile development.

Yesterday we summarized “Time After Time” In 10 Screencaps Or Less™. Today, we extract a product management lesson from that 1970’s time travel mash-up.

In the opening scenes of Time After Time, H.G. Wells introduces his dinner guests to the new Time Machine that he’s invented. Unfortunately, one of his guests is secretly Jack The Ripper who promptly steals the Time Machine to continue his serial killings in modern-day San Francisco.

To the best of my knowledge, no product that I’ve ever worked on has been linked to time traveling serial killings. However, I have been involved in at least one strategic partnership that was disastrous.

Now, I wasn’t involved with vetting or approving the partner; it was thrust upon me and I did what I could to mitigate the oncoming storm. But in the end, there was no choice but to ride it out, which put a tremendous burden on everyone involved internally as well as on our customers.

What went wrong? Like H.G. Wells, we trusted someone we shouldn’t have–and had to live with the consequences.

When it comes time to make a buy/build/partner decision, there are a number of questions that must be asked–and, sometimes, the reality is that the Product Manager’s answers may fall upon deaf ears. However, you need to be prepared: It’s your job to lead the product and, in dire straits, do what you can to mitigate the bad stuff.

Never automatically assume you need to partner. Always go through the exercise of properly determining whether to Buy, Build, or Partner. See Build, Buy or Partner: So Many Choices, So Little Time for more information.

When you’re faced with the choice of selecting a strategic partner, I recommend asking the following three questions:

• Do you like them–AND trust them?
  Your potential partner must demonstrate that they are principled, honorable, and ethical–and that they can live up to their promises and deliver the agreed-upon deliverables. (To be fair, you should prove the same to them.)
• Are they in it for the long haul?
  Who invests in this company, or purchases products from them? Who are the owners? What’s their market share? Do they have the financial backing to weather the economic turmoil making headlines across the world?
• Are you strategic to one another?
  You’ve determined that you need them, but do they need you? How open are they to sharing information, executing changes, and working collaboratively?

Fortunately, in the situation I referenced above, we were able to weather the storm and disentangle ourselves from the strategic partner that was a very bad fit.

I then researched, vetted, and partnered with a different company with a proven track record and a shared sense of strategic values.

This second partnership has proven beneficial to both sides, with incentives for both parties to work continuously on improving the product experience and share in the resulting revenue. That’s an example of strategic partnership at its finest.

Partners can help you reduce time to market and reduce risk–but only if they’re the right fit for your product and your business.

Never make strategic decisions half-cocked or under pressure. Otherwise, you may find out that the partner you’re courting isn’t quite who you thought they were–and your product will be the worse for it.

Additional Resources

• Build, Buy or Partner? matrix
• Partnering Proposition Worksheet
• Build, Buy or Partner: So Many Choices, So Little Time
• Choosing Strategic Partners that Really Partner
• Strategic Outsourcing: The Importance of Choosing the Right Partner

What’s your experience been like in selecting strategic partners? Any horror stories to share? Or successes to trumpet?

“Time After Time” is a 1979 sci-fi feature film about H.G. Wells traveling across time and space in pursuit of Jack the Ripper. Let’s summarize “Time After Time”… In 10 Screencaps Or Less!™

< SPOILER WARNING >
Key plotpoints of this film are pictured below. You have been warned!
< / SPOILER WARNING >

Author H.G. Wells invites his friends over for a dinner party. After supper, one thing leads to another, and he unveils his brand new TIME MACHINE to them.

Unfortunately, one of the dinner guests is actually Jack The Ripper–and the police are hot on his trail.

Jack takes off in H.G.’s fancy new time machine.

Later that night, the time machine returns… without Jack. H.G. summons the courage to follow Jack–TO THE FUTURE! In this case, 1970s San Francisco. H.G. pawns his belongings while Jack gets back to the ripping.

H.G. and Jack confront each other. H.G. tries to appeal to Jack’s reason. But Jack, being a serial killer and all, won’t have it.

H.G. has trouble adapting to The Future because it’s not quite the utopia he expected. However, he does forge a love connection with bank employee Amy Robbins.

Wells takes Amy into the future, where they discover Amy will become Jack’s fifth victim. The horrified couple retreat to the present and try to change the future. Unfortunately, H.G. is quickly arrested as a suspect in the serial killings, leaving Amy passed out on her bed.

Jack kidnaps Amy, and attempts to escape once more in H.G.’s Time Machine.

Jack releases Amy and jumps into the Time Machine. H.G. removes the Vaporizing Equalizer (located somewhat precariously on the exterior of the Machine’s cabin) which causes Jack to disappear into Infinity.

H.G. and Amy return to the past, and live happily ever after.

THE END

Tomorrow, we see what “Time After Time” can teach us about product management and strategic partners.

Yesterday we summarized “The Blob” In 10 Screencaps Or Less™. Today, we extract a product management lesson from that classic 1950’s sci-fi flick.

According to its theme song, The Blob is a gelatinous creature that “creeps and leaps and glides and slides across the floor, right through the door and all around the wall”. It consumes everything in its path, growing ever larger and more dangerous.

Product manager and project managers routinely encounter features creeping up on them in a Blob-like fashion . . . attaching themselves to the work at hand, often with the best of intentions, and inadvertently endangering or even killing the product or project.

The good news is: these creeping features generally don’t want to dissolve anyone’s flesh and then devour you. The bad news is: if you’re not vigilant, these creeping features can sink your product, and blasting them with CO2 won’t do anything except make people cold and wet.

People sometimes use “product managers” and “project managers” interchangeably. While the two are related, they are not interchangeable and their approach to feature creep is very different. Before we get into the creeps, let’s define the roles of product managers and project managers.

Product Managers: Responsible for the ongoing success of a product.

Project Managers: Responsible for the successful delivery of a one-time effort; once that project is complete, the project manager generally moves to a new project which may be related to a different product in the organization.

There are other differences and responsibilities, but for the purpose of this conversation we’ll leave it at that. Check out Product Management Vs. Project Management by Jeff Lash for more detailed definitions.

How does a project manager defeat feature creep? What role does the product manager play?

The project manager is responsible for the successful delivery of a one-time effort–this means, getting it done, and done well, within various constraints (time, budget, etc.). Here are three tips on how to prevent feature creep from interfering with that goal:

• Allow the appropriate amount of time to research and nail down requirements. This sounds straight-forward but is often over-looked in the rush to Get Things Done And Show Results. Before anyone starts coding anything, make sure that you understand the purpose of the project and have a clear vision of what success will look like.
• Set the ground rules. Before a project has been defined and the spec has been locked down, set up rules governing feature changes. When a change is suggested or requested, hear the person out but be prepared to be the Bad Guy who has to say, “no”. If you are willing to greenlight the change–or are not in a position to reject the idea (for example, it’s the CEO’s direct request)–make sure everyone understands the repercussions of approving this out-of-scope feature (missing milestones, incurring additional costs, etc.).
• Be a hard-ass without being a jackass. Rejecting good ideas to stay on schedule can be tough. But it’s your job to make sure the project is completed on time, on budget, to the agreed-upon quality levels. Sometimes this means you’ll have to play devil’s advocate, and ask tough questions. This can strain relationships and alternatively bruise or swell egos. Remember to be respectful at all times, to hear people out, and to explain your decisions. Your meta goal is to be the most popular project manager in the room. That doesn’t mean saying “yes” to every request that comes your way; that means creating a stable, friendly working environment for your project and completing the project successfully.

For project managers, feature creep sneaks in after a project’s scope and requirements have been finalized. For product managers, feature creep takes a different, gelatinous form.

While the project manager strives to keep the scope of a given project manageable without taking on too many comely but dangerous hitchhikers, the product manager fights feature creep at the overall product level, determining the right feature set for the entire product not just an individual project.

The temptation for product managers working on a product feature set is to simply focus on what their competition is doing and just do that better and/or do more of it–which leads to a Blob-like feature set that may, or may not, meet the needs of your target market.

We saw a rash of this kind of thinking with free email services not so long ago: Company A would offer 125MB of storage; then Company B would offer 250MB of storage; then Company C would offer 1G of storage; and so on. As soon as one company implemented news feeds, everyone decided news feeds were required. As soon as someone else decided larger attachments were “It”, everyone else followed with larger attachments +1.

As a product manager, part of your job is to determine the right features to be released at the right time. Sometimes, this means setting aside your assumptions about the consumers of your product and re-educating yourself about their needs and desires.

Think of it this way: Suppose the target market for your email product didn’t give a toss about how many MBs or GBs anyone offers. How successful could you be if you could determine what they really did care about and then met that need before, and better, than anyone else?

If your feature list is just a compilation of features from your competitors, you’re doing something wrong. That is to say, you’re not doing your job as a product manager–you’re just feeding The Blob.

Your job as a product manager is to understand customer needs and create products that meet those needs. By asking the right questions and doing the research that your job demands, you’ll uncover the needs that need to be met and then determine the features that will meet them. And avoid being drop-shipped to Antarctica along with your failed product.

What do you think, gentle readers? Should feature creep be accepted as a fact of life or should it be warded off? How do you determine and prioritize product features?