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
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.
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.
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.
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.
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. 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
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.
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.
"If you can not measure it, you can not improve it." -- Lord Kelvin
The difficult part of measuring is deciding what to track.