Notes on The Lean Startup and The Mythical Man-Month
A few short notes that I took away from The Lean Startup and The Mythical Man-Month
Lean Startup
Get ahead of the opinion
If you have an idea but you don't have the product, it is easier for people who are evaluating you to criticize the idea because the white space has not yet been filled in yet. At this point a project is more likely to face opposition, criticism, and non-constructive feedback because everyone has their own idea about what to do next. The discussion can sometimes get mired in technicalities. So what should you do?
Get ahead. Build a shitty prototype.
Even if it is terrible, once you have the prototype, you shift the conversation away from the idea and towards what you have built. I have seen teams get mired in endless discussions about the specs when they were in their ideation stage, but once they built their first prototype, the conversations suddenly got more substantial and more supportive.
Building a shitty prototype doesn't mean that you slap something together overnight. It doesn't necessarily have all the bells and whistles, but it has at least one critical functionality working.
Document.
This comes in hand with the 'shitty prototype' rule. If you don't document, then you don't know what worked and what didn't, and what is worse? Not being able to recreate a success, or repeating a failure? Both sound like terrible options to me.
So write it down, and structure it. Make sure that what you write is something you want to refer to later on. There is no point writing down something that you can't read or can't search for later.
The Mythical Man-Month
For reference in the future.
- Some sort of public Q&A storage system is very useful.
- The second iteration is the most dangerous, because there is a desire to embellish the product.
- Proposals are written before meetings to force decisions.
- Organizations must be designed around the people available.
- Plan to throw one system away.
- Specifications are continuously emphasized in the book.
- Use debugged components - it saves time. And add one component at a time.
- Scheduled and estimated dates are distinct. Keep your hands off estimated dates, otherwise they will not be accurate.
- Adding manpower to a late software project only makes it later.
Interesting Observations
- What he calls The Project Workbook is the changelog that we see today.