Kawasaki wrote this as a practical guide to starting an organisation, drawing on his experience at Apple and as a venture investor. It is organised around the sequence of tasks a founder faces rather than around a theory.
The substantive content includes: causation, meaning start with the meaning the organisation creates rather than with a mission statement, and his instruction to write a mantra of three or four words that employees can actually remember; positioning, where he argues a company must be able to say what it does in one sentence that a customer would use; pitching, where his ten-twenty-thirty rule specifies ten slides, twenty minutes and thirty-point type, and where he sets out the ten slides a fundraising pitch should contain; bootstrapping, where he argues cash flow beats profitability and that a founder should ship rather than perfect; recruiting, where he argues to hire people better than yourself and to ignore irrelevant experience; and evangelism and partnering, where his particular expertise lies.
The most quoted content is the pitching material, which has been adopted widely enough that the ten-slide structure is now the default expectation in early-stage fundraising.
The book has no evidence base and consists of practical assertions from experience. It is from 2004 and the fundraising environment, the cost of starting a software company and the go-to-market options have all changed substantially. The pitching, positioning and mantra material remains directly usable.
First-time founders who want practical sequenced advice on positioning, pitching and early execution.
Chief evangelist at Canva; earlier Apple's Macintosh evangelist and a co-founder of Garage Technology Ventures.
The Art of the Start breaks early-company work into concrete tasks - pitching, positioning, recruiting, bootstrapping, partnering - for founders with no prior company behind them. The Macintosh Way and Selling the Dream document how Apple built developer and customer evangelism into a product launch, which is where the modern practice of developer relations comes from.
Chosen by shared topics, the entries that hold them, and the people who recommended both.