TL;DR
Kawasaki’s “Rules For Revolutionaries” feels like a manifesto written by someone who’s been in the trenches of high-stakes product launches, which aligns with my experience scaling teams through rapid growth phases. While I appreciate his bias for action and customer obsession, I’m more cautious about his “break all the rules” mentality—in my world of regulated products and enterprise customers, some constraints exist for good reasons.
About the Book
Guy Kawasaki presents a three-part framework for revolutionary innovation: Create Like a God (challenging conventional wisdom), Command Like a King (making decisive strategic decisions), and Work Like a Slave (relentless execution and knowledge absorption). His central thesis is that true revolutionaries must be willing to overturn established thinking, make bold decisions despite incomplete information, and outwork everyone else through obsessive customer and market focus. The book draws heavily from his Apple evangelism days and garage.com experience, emphasizing that breakthrough products require breaking through barriers—both mental and organizational.
Where This Resonates With My Experience
Proceed with Urgency
“The best time to plant a tree was twenty years ago. The second best time is now.”
This mirrors decisions I’ve had to make launching AI-powered features ahead of competitors. I’ve learned that waiting for perfect data or consensus often means missing market windows entirely. When we rolled out our first ML recommendation engine, I pushed for a limited beta despite engineering concerns about edge cases—we learned more in two weeks of real user feedback than six months of internal testing would have provided. This reinforced my rule: if we can mitigate catastrophic risk, speed of learning beats speed of perfection.
Ruthlessly Prioritize
“A revolutionary’s job is to say no to good ideas so you can say yes to great ideas.”
I’ve seen this firsthand when managing roadmaps across multiple product lines. Kawasaki’s point about “death magnets”—features that seem important but drain resources without moving the needle—gave language to something I’d observed but hadn’t articulated well. Last year, I killed three “strategically important” integrations that were consuming 40% of our engineering capacity but served less than 5% of our user base. The book reinforced a hard-learned lesson: my job isn’t to make everyone happy; it’s to maximize customer impact per unit of effort.
Face Up to the Truth & Adapt Plans
“Don’t let the pursuit of perfection prevent the implementation of goodness.”
This changed my thinking on technical debt and MVP decisions. I used to view compromises as failures of planning, but Kawasaki’s framework helped me see them as necessary speed enablers. When our payment processing integration was taking three months longer than planned, instead of delaying launch, we implemented a manual workflow that handled 80% of cases automatically. It wasn’t elegant, but it got us to market and gave us real transaction data to optimize against.
Delight the Customer
“If you have to put customers on hold, play great music.”
While this seems like a small detail, it reinforces my philosophy that customer experience includes every touchpoint. I’ve applied this thinking to error messages, loading states, and even our API documentation. The book reinforced that revolutionary products aren’t just about core functionality—they’re about removing friction at every interaction point.
Where I Push Back
Break All Rules Mentality
“Rules are for people who don’t have the guts to make their own.”
I’m more skeptical here because I’ve seen teams interpret “revolutionary thinking” as license to ignore compliance, security protocols, or architectural standards. In regulated industries, some rules exist because the cost of failure isn’t just market loss—it’s regulatory action, customer data exposure, or safety incidents. My experience has taught me that the most impactful innovations often come from working within constraints, not ignoring them entirely.
Command Like a King Framework
“A revolutionary makes decisions with 30% of the information he wishes he had.”
While I agree with bias for action, Kawasaki’s framing feels overly individualistic for complex technical decisions. I’ve learned that decisive leadership means knowing when to make unilateral calls versus when to leverage team expertise. When we were evaluating cloud migration strategies, the “kingly decision” would have been to pick based on my experience, but the revolutionary outcome came from empowering our infrastructure team to prototype three approaches and present data-driven recommendations.
How This Influenced My Leadership
- I will push teams to articulate what conventional wisdom they’re challenging in every major feature proposal—not just incremental improvements
- I will apply stricter guardrails around “strategic” projects that don’t directly serve our core user workflows—Kawasaki’s death magnets concept gives me better language for these conversations
- I will communicate to leadership that revolutionary products require revolutionary resource allocation—not spreading bets across twenty “maybe important” initiatives
- I will not compromise on customer feedback loops in early product stages—even if it means manual processes or imperfect automation
- This reinforced my heuristic: if a decision can be reversed with two weeks of engineering effort, make it quickly; if it requires six months to unwind, take time to get it right
Who Should Read This
Product leaders managing early-stage or high-growth teams who need to move from incremental improvements to breakthrough thinking. Particularly valuable for executives who’ve gotten comfortable with consensus-driven decision making and need to rediscover bias for action. Less useful for leaders in heavily regulated industries unless they can translate the principles through appropriate risk filters.
Rating
Moderate Alignment—Strong tactical alignment on urgency and customer obsession, but I apply more systematic risk evaluation than Kawasaki’s “rules are made to be broken” philosophy suggests.