Blog #2 Lifelong Product Development Experience |
|
 |
|
|
I have a lifelong product development experience, which I thought exciting to describe and share with you. In my last blog, I explained what happened when I started to write this book – whatever I tried to explain, I found no solid references and definitions to build on. Most used words in this business had a different meaning because they were not clearly described, or if described, they were ambiguously defined among the various authors. As a result, they were useless to build on—like trudging around in a swamp. So there was nothing else to do than back off a bit and drain the swamp until finding load-bearing ground. Let me take an example, what does “requirements” mean. It can be anything from imagination in somebody’s head, over to an endless novel-like stream of words. If I want to explain how to capture requirements, I must find precis definitions, like what types of requirements are there, should they be text-based or graphical, when in the development should capturing take place, who are supposed to handle them, etc., etc. If we don’t define and share this, anything can be regarded as a requirement, and it is impossible to understand when they are ready before proceeding with the product development. |
In my book about Cpdm, I define precisely what is needed to know about requirements. Yes, it will take some time to grasp this 100-page requirement chapter in the book, but there is no way to navigate the swamp other than build on solid ground. And not all of the development team need to understand these 100 pages in detail. One of the members can navigate the swamp using Cpdm, and the other members can capture the requirements according to the navigator. The Cpdm book certainly covers foundations, but it also describes the entire house, with many additional examples. But to my point, it is a waste to try to save time and effort by skipping the foundation and begin settling the first floor right on the mud. Likewise, it is a waste to try to save time and effort by skipping to understand and capture requirements before further developing a product. |