Ask someone what they want, and they’ll tell you they want a faster horse. Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the […]
Cadence Versus Risk
I’ve been thinking about the software development process. Big, upfront, design and requirements. User research and analysis. Market insights, gained on exploration or over time. Release cadence – how quickly you get, and incorporate, feedback from your customers about your product. How quickly you react to your competitors’ reactions to […]
Use Cases for Iterative Development
Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage […]
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 […]
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 […]
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 […]
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 […]
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 […]