We are thoughtbot. We have worked with hundreds of product teams all over the world, from individual founders who are self-funded, to large multi-national organizations. We have also created our own products and dozens of open source libraries.
This is our playbook. It details how we make successful web and mobile products, and also how we run our company. It’s filled with things we’ve learned based on our own experience and study of others’ experiences.
It is a living document that everyone at thoughtbot can edit in a private GitHub repo.
We’ve made the playbook free and licensed it as Creative Commons Attribution-NonCommercial so you may learn from, or use, our tactics in your own company. While our “plays” have worked for us, we trust your judgment over ours to decide which tools and techniques might work for you, too.
Our playbook includes:
- Our Company
- Rapid Product Validation
- Choose Platforms
- Laptop Setup
- Sharing Knowledge
We believe that it is possible to continuously learn and improve the way people work while building higher-quality products that make positive contributions to the world.
One of our primary process goals is to make frequent, small releases of our working software. We do this through frequent communication and weekly iterations on a product.
- Processes need to adapt to the needs of the product and team
- Daily standups build trust and maintain momentum
- Manage priorities and visualize progress with a lightweight process
- Meet weekly to discuss successes, failures, and future plans
- Product Owners Guide
- A functioning remote team doesn't happen by accident
Rapid Product Validation
We're risk averse; we use concentrated tests while building products to make sure that we're providing value to our users. The fastest way to ensure that we're building the right software is to prototype and test solutions with people before we build out fully fledged features.
- Design Thinking Exercises
- Creating a Jobs Profile
- Applying Jobs-to-be-Done Theory to build successful products
- Product Design Sprint
- Test Assumptions, Get Validation, and Eliminate Business Risk
- Research Frames the Problem or Opportunity We’re Solving For
- Running remote workshops and design sprints
- Conducting Switch Interviews
Our human-centered design process is grounded in the principles of Design Thinking. It's the driving force behind our projects and teams. Designers keep this process alive by helping our teams understand user problems and needs. Together, we collaboratively and continuously ideate, build, and learn.
Early in a project, we have to decide which platforms we'll use. Which platform depends on our ideas for solving these users' problems. After considering what's best for users, the best tools for us have a strong community, make us happy, and help us create and iterate quickly.
Your laptop is your sword. Don't go into battle without it.
The majority of our development practices were first detailed in Kent Beck's classic Extreme Programming Explained: Embrace Change and in Gerald Weinberg's The Psychology of Computer Programming. We've tried its practices and found that using most of the practices most of the time improves the quality of our work and happiness of our team.
We live in a magical modern era where many problems have already been solved for us. We focus on the core product as much as possible and outsource operations as much as possible to external services.
The difficult part of measuring is deciding what to track. Dave McClure's AARRR framework provides a high-level overview of important metrics. We then use tactics such as event tracking to instrument those metrics.