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.

Read the rest of the article…

People who already use Scrum will only find one new thing in this article – a way to communicate what happens inside a sprint that has proven effective for me.  People who are new to Scrum who wonder “how do things work inside a sprint?” will see how things work in a way that avoids hyperbole and is easy to map to what they already understand from traditional software development processes.

Read the rest of the article…

Writing unambiguous requirements is about understanding what is written, and what is read.  Without a clear understanding of your market, you can’t write unambiguously.  Even when you understand your market, you risk writing something that is ambiguous to your readers.  Documenting requirements is about communication.  Don’t break this rule, or you’ve wasted all the energy you spent understanding your requirements.

Read the rest of the article…

Accept has invited me to participate in their webinar series on Transparency and Innovation – this Wednesday, July 28, 2010 (10AM Pacific, 1PM Eastern).

Join us and join in!

Read the rest of the article…

vs.

What happens when billionaire media magnate, Rupert Murdoch, pits his idea against a Nobel-prize winning idea from the beautiful mind of economist and mathematician John Nash?

When you act on what you hope your market will do, instead of what you predict your market will do – you’re in trouble.

This is a story about understanding your market, and an example of using game theory – specifically, the Nash Equilibrium in “non-cooperative game theory” to predict market responses to your products.

Read the rest of the article…

Everyone who thinks about what it takes to create great products needs to read The Design of Design: Essays from a Computer Scientist.  Frederick P. Brooks, Jr., author of The Mythical Man-Month, has released this inspiring collection of essays about the nature of design.  By Brooks’ definition, design includes the notion of intent and definition of goals, requirements, and implementation choices.  Everyone responsible for creating products, but with fewer than Brooks’ five decades of experience really needs to read The Design of Design.

Read the rest of the article…

As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

Most companies ignore their markets – and they will struggle to survive.  Some companies listen to their markets – and they have an opportunity to succeed.  You have the opportunity to understand your market, and transform it into your market – but you can’t get there just by listening.

Don’t listen to your market, understand your market.

Read the rest of the article…

“For what one idea do you want your product to stand in the mind of your customer?”  I heard Roger Cauvin ask that question at the most recent ProductCamp Austin [correction - he said it here - thanks Roger], and the quote has been jumping to the front of my mind almost daily ever since.  Maybe by writing about it I can exorcise the demon and get back to using the idea instead of being haunted by it.

Consistency in writing requirements is important on two levels – strategic and tactical.  Tactically, you need to write your requirements with grammatical consistency, so that potentially ambiguous statements will be interpreted similarly.  You also need to write requirements that are logically consistent, so that you avoid “impossible” requirements and gaps of unspecified meaning.   Strategically, your requirements need to reflect a focus on markets and problems that are consistent with your business objectives and the vision your company is manifesting

Read the rest of the article…