Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can’t verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements – but it is ignored every day.
Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical. When you set unattainable goals, the best result you can hope for is a frustrated engineering team. Write requirements that are attainable, and your team will surprise you with what they can achieve.
Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done. Great requirements exist to do three things:
- Identify the problems that need to be solved.
- Explain why those problems are worth solving.
- Define when those problems are solved.
Writing valuable requirements is important. It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features. The right products and capabilities are the ones that have relevant value.
- Valuable requirements solve problems in your market.
- Valuable requirements support your business strategy.
- Valuable requirements solve problems for your users.
- Valuable requirements meet your buyers’ criteria.
- Valuable requirements don’t over-solve the problems.
Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc). And your site/application crashes due to the “unexpected” demand. All you can do now is look for a bucket of water to put out the fire. What could you have done to prevent this disaster? Jump back to today and start doing it!
Agile development methodologies succeed because they help development teams be as effective as possible. Development teams do not, however, work in complete isolation. The company they work for has a strategy. The company manages a portfolio of products, and targets a particular product at specific market problems. Within that context, an agile team can thrive. What’s the best way to provide that context?
Continue reading Agile Product Management: Providing Context
A lot of people stand up a variation of “If you build it, he will come” (from Field of Dreams) as a copy-writing hook for whatever they are about to tell you about creating products/services/whatever. We’re no better. We’re going to tell you that there is a big difference between the people who buy your product and the people who use your product.
If you build what he thinks he wants, he will come.
Actually, we need two catchy quotes.
If you build what he actually needs, he will come back.
For good measure, let’s plug my recent article in The Pragmatic Marketer, Maximize Your Word of Mouth Marketing: Turning Users Into Fans with a gratuitous quote.
If you build it right, he’ll bring his friends.
These quotes (the first two) highlight the differences between buyer personas and user personas.
Continue reading Buyer Personas And User Personas
Jun 14th was the first productcamp in Austin (and the second one anywhere). It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.
Continue reading Defining Problems at ProductCamp Austin 1
The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!
Continue reading Defining Problems With Cause And Effect Diagrams