How to release software and how to release software

After my tryst with Product Management over the past 28 months and my 9-6 work involving the PM concepts, I think I am now capable of penning my thoughts on the 2 ways software should be built and released. These are more of my personal views (and of some friends and colleagues too ;-)) and should not be considered as the final say. You are free to think/opine/contradict it and I would love to know more than 2 ways of doing the above task.

To begin with, I think writing a software is bullshit. Software is never written, it evolves from someone's idea. What goes in is not just the if, else or the {}. It is the end user's requirement, his pain points, and his suggestions. This is the only way we can look at software. From an end user's point of view. Hence the first and most important thing to do before building any product, is to get the customer's suggestion. After all, if you have a product and no customer you might as well throw it out of the window (needless to say, you might consider using the documents and the presentations created as emergency tissue papers). The following should be the motto of the day for any person working in the software industry:
"In Our Business The Customer Is The King". You should make each developer, product manager, solution manager, development manager, head clerk (???), admin, HR, every link in the chain, to say this 100 times before starting to code. This is one of the ways to get to know who is the boss. (I still wonder how some of the projects/products which came up without any customer focus made it to the market and survived for a week).

OK. So now back to what I started with. The 2 ways to release a software. The first methodology is outlined here.

"I give You Take":
(Should be read as I give you my idea, you take my idea). This is another way of saying "I give a damn to your ideas"

1. The LOB head comes up with an idea.
2. The idea is shared with design, architecture, and solution managers.
3. Solution Management tries to find internal stakeholders (read as internal customers) (we still do not have customers anywhere here)
4. Architecture comes up with the design document.
5. Technology is deliberated on.
6. Plans are communicated to development and timelines are created.
7. Development is still unaware of why it is doing what it is doing. (Point 2 never flows till here. It is not hidden in those design documents and MRDs which were created in point 3 and point 4. If you want you could understand from there)
8. Repeat steps 5-8
9. By now it is close to 8 months and 50% of development is still not aware of what they are doing. The rest know something because, they are in the process of updating their resume and need to show what they have done in this timespan since the project started.
10. When all the testing and validation and product standards and bug fixing and internal releases are completed, the product is ready to be released for a few select customers who showed interest in a similar idea.
11. When this is finally taken to the market, you find a host of products which are cheaper and easier to deploy with better service network.

Then we go back to step 1 and the process repeats. The reason why this would be a 95% failure is that there is no customer interaction at any point. Even if a customer is unfortunate enough to buy this product (which would be costly as hell because of the huge effort spent so far), the UI, interaction, and flow would not be to his taste. So now the development is loaded with the task of customized development for this customer. (The remaining 5% would be for the internal customers who do not have an option but use it as a pressure from the upper management)

The major pit-fall here is that every single person in the food chain is unsure of the market demands. There is just no customer in the whole thread, from whom you could get their views.

The other route (and my most fav one) is:

"You give I take"

Should be read as "You give me the requirements, I take your requirements"

For this I would say the first point of contact is the field. Get the field sales people to check with their buddy-buddy customers about what they have, what they would like to have in what they have, and what they would not like to have in what they have. This is more of a bottom-up approach and would flow as below:

1. Field approaches customer with what they want.
2. Customer gives his requirements.
3. Field talks to Solution Management
4. Solution Management prepares MRD and shares with Field
5. Field ensures if things are understood (and if required, check and cross check with customer)
6. If things are fine, Field requests for commitment from SM.
7. SM checks with management and provides a breakdown result structure (more of SCRUM except that at the end of each Sprint, the actual audience would be the Field and Customer and not peer developers)
8. Signoff from Field and customer
9. Communication of MRD/PRD from SM to Architecture.
10. Architecture prepares blue print. Discuss with Field (and if required the customer). Make sure if this is what the BOSS wants.
11. Communication to Development and Project Management.
12. PM plans for short sprints and development executes.
13. End of each sprint, check with customer if the requirements are being implemented right.
14. Close the project ahead of schedule.

The good thing in this approach is, even if you slip a month or so past the deadline, it is not a big deal since you have got the customer and field's confidence in your work. They would be ready to wait for your result.

The only con here is, it requires 3 steps more to release (the first needed just 11) and requires to disturb the customer time and again (with your questions and suggestions and ideas). But what the hell, I think customers like to talk to development about the proposal. At the end of the day, who would like to spend money on a piece of code which they never wanted.

This is a longer route, but one which is guaranteed to get you that 5 * from the customer. Afterall 5* is always better than a dissatisfied customer. Think about it.