Writing passionate requirements is not about writing with passion. It is about writing the requirements that cause people to be passionate about your product. Find the most important problem, for your most important customers. Understand the essence of what is important to solve that problem, for only those people. Then […]
Kano Analysis / Product Management
Posted on:
Customer-Centric Market Model
A market can be thought of as the collection of contexts in which you might sell your product. You can split your market into a set of market segments. Each of those segments represents a group of customers, each of whom shares a set of problems for which they would […]
Agile / Business Analysis / Ishikawa Diagram / Prioritization / Product Management / Requirements / Requirements Models / Software development / Software requirements specification / User Stories
Posted on:
Atomic Requirements
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements […]
Agile / Business Analysis / Product Management / Requirements / Requirements Models / Software development / User Stories
Posted on:
Sprint Backlog – Don’t Solve Half of the Problem
Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users. The right approach is to first […]
Business Analysis / Ishikawa Diagram / Kano Analysis / Product Management / Requirements / Requirements Models
Posted on:
Verifiable Requirements
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 […]
Business Analysis / Product Management / Requirements
Posted on:
Writing Unambiguous Requirements
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 […]
Product Management
Posted on:
Innovation and Transparency
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!
Business Analysis / Product Management
Posted on:
Rupert Murdoch – Zero; John Nash – One
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 […]
Business Analysis / Product Management / Requirements / Requirements gathering
Posted on:
The High Costs of Building the Wrong Product
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 […]