Respectfully, I think that an expert has a tendancy to adjust a problem to his/her know-how instead of adjusting to the matter in hand. That being said, it is not always the case.
In this context, I don’t consider my self an expert in anything and I try to keep it that way. I believe that by doing so, I put less constraints on my approach, and allows me to keep an open-mind and my objectiveness for a problem analysis.
In the specific case of a product development process, I’ve learned that there’s no perfect way to do things. It always depends: on your market, resources, budget, history, etc. In fact, I dare to say that there’s probably as many ways as persons in a company.
Less is more in this context means that by focusing on a simplified yet complete workflow, we spend less time thinking about the what and how and focus on doing the actual thing.
There’s so many product management tools and methodologies out there, and I’m not arguing about it or analysis their pros and cons here .. In the end, they all share the same concepts.
I’ve found that what always works is to study your environment and evolve with it. Your products are alive and evolving, your documents are alive and evolving, I hope that I don’t need to remind you that your team members are alive and evolving.
Most of all, I’ve noticed that people ofter underestimate the importance of writing down their thoughts about a product and go directly to the development. For a one-shot thingy, a proof-of-concept, this might work, but then again this is not what we’re talking about here.
Whatever your product is, whatever your management method is, as long as it’s an industrial one, it goes through the same phases (which is eventually a circle):
Market analysis, Conception, Development and Validation
Let’s see how these parts interact.
To be continued in this next part