Communication / Consulting / Interaction design / Product Management / Requirements / Requirements gathering / UX

Requirements Gathering – Interviewing the Right People

Posted on:

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

Marketing / Product Management

One-Page Marketing Plan Template

Posted on:

Kelly Odell posted a single-sheet marketing plan template, after being frustrated with the massive templates that others have promoted in the past. John Sviokla recently wrote about how the 4-P’s of marketing are changing to the 5-P’s of marketing. Marcus Ting-A-Kee found John’s essay and wrote about it yesterday. Guy Kawasaki suggested that Kelly adapt his template to John’s new approach. Kelly chose to mix the best of both worlds. We add our own spin at the end.

Communication / Product Management / Requirements / Software requirements specification / Writing

Requirements Documents – One Man’s Trash

Posted on:

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents – MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

Agile / Product Management / Requirements / Requirements gathering / Software development

The Agile Dragon

Posted on:

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.

Agile / Product Management / Project Management / Software development

Agile’s Biggest Strength is Agile’s Biggest Weakness

Posted on:

Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.