Notes on “How to do great things with small teams”
So you appear to need people passionate and happy, well rounded, quick learner, trustworthy and a good writer, so he’ll take someone who is average and happy instead of brilliant and disgruntled.
Small has big advantages: customner is closer, so less formal, less mass, less fear, more flexibility, more change and more freedom. So what does this do – allows people (if they are passionate and happy) can do more things, cna speak up, can all contribute to all things and are not constrained by the ‘roles’ a big company puts on then. But a big company has money, hardware, software etc (is he sure??? In a big company we still have issues getting things), so a small company has to be creative in getting things done.
“when spending a dollar no longer hurts, then you have too much money”
An interesting take of ‘customer suggestions”. they respond, they listen, but only act id the suggestion comes up again and again.
Remember – “decisions are temporary” – so you can change things.
“Build less software, build half a product, not a half-assed product”
Less software means less features, lower cost of change, less work to maintain things – all of which can make people happy. Support is tiresome, timeconsuming and a pain. So ensure you build stuff that won’t need much work…and drives people to get their own solutions. Give aids to someone coming up with their own solutuons, don’t try and fix everything.
So I can see the above working with small products that can go onto be big. This is about emergent stuff, stuff that can evolve.
Now he’s putting down fucntional specs – I agree, they constrain evolving design “there’s nothing functional about functional specs” But in the area I work in, they’re compulsary as the designers and the builders are different parties. It’s the agreement – and it does definitely lead to argument.
Design, prototype, experience and change. Repeat until something works and you can live with it. Yes please, I’d love to do this. Iterative design is good.
“things aren’t problems till it’s a problem,” When Basecamp was launched the company did not have any billing software – because it was launched with 30 days free….so they did not have to build it til 30 days were up. Just in Time – only do things when you need to.
He’s talking about something like the SCRUM method, breaking things down into smaller projects, each of which has a cycle.
SO when you have a small product (or half a product) how do you get the word out? Have features that can be shared and gossiped about – find something people want to talk about; promote through education – blogging, conferences; upgrade often, so people see you’re still working on it, still passionate. And finally, be transparent, be honest, keep people informed, don’t hide things. (and that is definitely one of the days’s recurring topics)
