How to build a product

1. Developers, product management, and customers brainstorm ideas.
   

   What problem are we trying to solve?
   What market opportunity are we trying to meet?

2. Developers & product management write the core user stories.
3. Developers build an end-to-end web site skeleton with mocks to any external systems.
4. Developers spec out the core web site API.
5. Developers and product management iterate over the web site skeleton adding the core user stories.
6. Partnering with the customer; developers and product management push the product to market as quickly as possible.
7. From customer feedback developers and product management enhance, rewrite, or create new user stories and apply those stories back into the web site.
8. Repeat 1-7

Meetings

It seems that in all my years of software development every company I work at seems to feel the need to pull people off of real work to have a meeting. Where they want to discuss some useless topic that just makes managers feel like the team is being productive by communicating status or issues. So what are good guidelines for meetings? Should we be having meetings? Here are my 3 golden rules:

1. Meetings should never be scheduled; you should strive to create an environment where meetings just happen. How do you do this? Create open development environments where there are no offices or cubicles just groups of desks with lots of couches and whiteboards. In this environments meetings become organic and happen only when people need to talk.
2. You should never have meetings to communicate status; that is why you use wiki’s and bug tracking tools. People who want status should just pull the status from those tools. It does not matter if you are standing up while you are giving status in a meeting or you call it agile. Status or issues should be an asynchronous activity where the people who need to know should be pulling those from the team, not slowing them down with a synchronous meeting.
3. You should only have meetings for productive things like brainstorming new ideas, doing use cases, group design, discussing code, or getting the team together for drinking beer.

Why working in a large org sucks

Great quote by Paul Graham which explains why working in a large software development organization sucks.

..we can get a portrait of the “normal” world. It’s populated by people who talk a lot with one another as they work slowly but harmoniously on conservative, expensive projects whose destinations are decided in advance, and who carefully adjust their manner to reflect their position in the hierarchy.

http://www.paulgraham.com/kate.html