I'm so glad you asked!
Processes enable companies to consistently produce quality products without an over-dependence on individual teammember's abilities. A process designed to create something that has never before existed has to be flexible enough to allow the chaos of innovation but robust enough to make real progress.
There is a sequence problem between planning to learn and planning to accomplish. Planning to learn must always come before planning to accomplish. This is the “fail fast” mindset. How is it done? By creating low risk, highly instructive tests that position yourself and your team to gather information cheaply, and thereby lower risk and uncertainty.
How do we position ourselves to (1) make the saltatory discovery so that we can (2) benefit the world and ourselves through saltatory innovation? My mildly uncontroversial answer is based on the following four truths.
Begin the design process at the lowest possible level then move up (hint: it's not the logo). The pieces just to fall into place if you can start with what's most important.
I like to say "The more the detailed the plan the more will go wrong." But then I also like to say "No plan means no direction which means no product." Where's the balance? Welcome to the wonderful world of Agile product development.
Plan iteritively. What thing of value can we delivery in a single sprint? Sometimes it's just a button. Sometimes it's much, much more.
Businessmen and women are motivated by results (money, prestige, etc.). Engineers are motivated by what's cool to build. Developers are highly educated craftsmen and women who want to make a difference in their teams, communities and even the world. Often business people treat them like machinery--I know, I used to be one. The product manager's role should be to direct the ingenuity of the developers toward the right problems. Then watch them build something great.
Finishing a product is the most difficult stage of development. All the nitpicky, leave-it-till-later to do's come back to haunt you. Here's my short checklist before I release anything.
If the answer is no to any of these questions then we have to decide if customers would rather have it sooner with bugs or later with fewer bugs.
To see how this process has worked out so far, check out my portfolio