We partner with organizations of all sizes to design, develop, and grow their products for iOS, Android, and the web. This is our Playbook.
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 to design, develop, and grow their products. We have also created our own products and dozens of open source libraries.
This is our playbook. It details the best ways we've found so far for how we make successful web and mobile products, as well as how we run our company. It's filled with things we've learned based on our own experiences.
It is a living document that everyone at thoughtbot can edit in a private GitHub repo. This means that as we have grown and learned, this Playbook has changed. It also means that it is incomplete and can only represent where we are today. We are constantly working on improving, and we seek to share what we've learned as we go.
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 we've tried to make this Playbook as comprehensive as possible, some of
our work is very technical, such as our Git protocol for feature branches.
Look in our public thoughtbot/guides GitHub
repo for that kind of information.
We hope the practices we've shared here will be helpful to you. While our "plays" have worked for us, we encourage you to build upon them using your own experiences, deciding for yourself which tools and techniques might work for you.
Thank you for reading.
Our Company
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.
Customer Discovery
In our many years of experience designing and building products, we’ve learned how important it is to regularly ask, “Is this the right thing for us to be building right now?” A key ingredient in building that right thing is knowing who you're building it for and why they need it right now. We love building software, but we love solving real people’s real problems even more!
This collection of customer discovery exercises will help your team find (or regain) customer, product, and strategic focus.
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.
Designing
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.
Choose Platforms
Early in a project, we have to decide which platforms we'll use.
Which platform depends on our ideas for solving these users' problems. For example, if they're construction workers on a job site, a mobile or tablet interface might be the best choice.
After considering what's best for users, what's best for us?
- The tools are open source with a strong community
- The tools make us happy
- The tools help us create and iterate quickly
Our Core Choices
Web Apps
Mobile Apps
Laptop Setup
Your laptop is your sword. Don't go into battle without it. To get started quickly with a standard configuration, we've created a setup script called Laptop and dotfiles.
Planning
One of our primary process goals is to make frequent, small releases of our working software.
This section describes how we achieve one week's worth of iteration on a product. It lays out the process we follow and some communication tactics.
Developing
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.
Production
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.
This saves time and money. We can get started using those services in minutes, and pay a service tens or hundreds of dollars per month instead of paying developers thousands or tens of thousands.
We often create a Google spreadsheet for our clients, listing the monthly cost, description, and credentials of each of the products' external services. It includes line items like GitHub, Heroku, SendGrid, New Relic, and Airbrake.
Measuring
"If you can not measure it, you can not improve it." -- Lord Kelvin
The difficult part of measuring is deciding what to track.
Best Practices
Outlining our proven methods for building an inclusive work environment is just as important as documenting best practices for developing in Rails or using Git. We've developed public guides to serve as helpful references for our team when working with each other and when communicating with clients. For programming and other technical style guides, check out our guides repo.