“If in doubt, ask a customer” – How We Build Product at Tanda
Since 2012 Tanda has grown from me and a few mates in a share-house to a business employing 30 people. Most of that growth was in the last 18 months, as both our product and customer success teams have tripled in size. There’s been growing pains, but I’m happy with the point we are at now and with how we keep improving as a team.
I’ll try to keep this post updated over time as things change. Most of the processes in this post have evolved over time and through trial and error. I’m sure there’s room for improvement. If you have comments or feedback, I’d love to hear them!
This post started as a quick question on the CODE Network Facebook group. Writing takes a while (for me anyway), so I wanted to check who was keen on the topic before writing too much. This is quite like our actual product process – we try to avoid writing any code until we have a good reason to do so.
Choosing what to build
We have LOTS of ideas for what would make Tanda better. So do our customers. People sometimes ask how you balance customer feedback with “business product vision”. They quote Henry Ford saying that if he asked what people wanted, they’d say a faster horse (did he?).
I’m not convinced there’s a need to balance the two when building a SAAS product. Our customers pay us every month to improve our product. We commit 20% of our monthly revenue to research and development. And our customers will keep paying us if our product keeps meeting their needs. So if we build something our customers think is crap, they can vote with their wallets and we’ll be out of business.
The chasm between what customers want and what we think is not as wide as Henry Ford suggested. And I like it that way, which is why we have a relentless focus on feedback throughout the development cycle.
Where projects come from
Ideas for projects come from all over the place, there is no single “entry point” for new product work. We encourage everyone at Tanda to talk to customers lots and keep a Trello board of their ideas – no matter how crazy they sound. This makes it easy for us to capture the “mood” of the market and pick good projects. The theme in every project is to either fix the most broken part of our product, or build something new that customers want. In this way we get a “rising tide” of quality as long as we keep a balance in both kinds of projects. For example, here’s some recent big projects we’ve shipped:
- Locations & Teams: a restructuring of some of our core configuration options, fixed the (very annoying for us) problem that there was no “best practice” way to set up a business in Tanda.
- Leave fixed one the most common requests we got from customers – a tool for employees to request time off work online and see the status of their request.
These projects came from different places, but the processes of building & shipping them were similar. In both cases, the first step was to figure out the project’s “team”.
The project team
Each project’s team consists of a designer, a developer, and a product owner.
The product owner is not a member of the development team. Depending on the project, they do things like:
- contact customers to ask their thoughts on how a current feature works
- gather feedback from other Tanda people about how a feature should work
- make judgement calls on non-technical questions that come up during development
- coordinate testing of new features with customers
- update help documentation
- give advice on customer communications & marketing messaging
In short it’s their job to speak for the customer. Generally they will be someone who’s already talking to customers daily. This makes it easy to sneak in a mention of a new feature or to get feedback on an existing one.
We use the terms “designer” and “developer” a bit more liberally than others might. The two work together to scope what new features should do, then get an OK from the product owner. Once all 3 are in agreement, the designer and developer split ways in terms of what code they write. We only changed this recently. 6 months ago the designer “designed”, and the developer only got involved once the new feature was defined, the HTML was written, and it “just needed to be wired up”. This turned out to be a bit of a disaster as it resulted in a lot of back and forth once real world constraints hit.
We use GitHub Flow, which is a git workflow that GitHub designed to make it easier to deploy all the time. It’s based on Git Flow, which works well for periodic releases like desktop software or native-first apps. But for a web based SAAS product, deploying a feature when it’s ready makes more sense than waiting for a weekly release date.
We have added a few things on top of GitHub Flow to better suit our workflow and style of business:
- Whenever you create a pull request, a new publicly available test site is created. Your feature branch then deploys to this site on each push.
- We use a Pull Request Template with a handy checklist of things to do before deploying. The code reviewer and product owner sign off a pull request before it’s merged.
- Everyone at Tanda uses a Chrome extension to see open pull requests and their corresponding test sites. This makes new features accessible to everyone as we build them.
- Master deploys automatically just like every other branch. So closing a pull request triggers a production deploy.
- We also have a general purpose test site, which has a copy of the master codebase and production database. It’s updated once per day. Everyone uses it to test things before making changes to customer accounts on production.
Why these changes? GitHub is a product built by developers for developers. As a result GitHub Flow assumes that the people writing code are the best judges of if a feature should exist. We’re a bit different in that we developers aren’t Tanda’s target customers; businesses with 15-250 blue collar staff are. Our workflow is designed to make it easy for everyone at Tanda to give feedback on new features as we build them.
Building and deploying
We use Codeship for building and deploying. Our deployment scripts use Capistrano. There’s nothing particularly exciting here. As well as plenty of unit tests we also have a few other tests that run in a separate Codeship pipeline: bundle-audit and Brakeman for security issues, a broken link checker which ensures all our external links work, and a static analyser that looks for accidentally committed calls to debugger, awesome-print, and a variety of other dev tools. Our tests report code coverage, which we used to post to Coveralls but found we were never checking. We still measure it because it’s a good thing to be able to look at locally, especially when adding features. We don’t use any linters (yet?).
Telling people about new features
This is an area we have only found a good balance for very recently. Back when we used git flow, we used to have a weekly release day. On that day we’d share a release document outlining all the new stuff going live. This was good for making sure everyone at Tanda knew about new features after they went live. But it didn’t work well for preparing staff and customers in advance.
Since moving to GitHub Flow, we’ve become much more proactive about communication. As a feature gets closer to completion, the product owner will share the link to the test site around with as many people as possible. They’ll also share the pull request around internally and ask other Tanda people for feedback. And they’ll update our help site with new screenshots and information.
Once a feature goes live, we’ll announce it in the appropriate HipChat rooms. I also send a note around once a week to the whole company with a summary of pull requests merged in the last week. For larger or more interesting new features we send messages out to customers using Intercom. (You might have noticed these in the pull request template above.)
How all this is different to university
When I was at QUT I learned a few things about product development which haven’t carried across into the real world well.
The first was that of building software from a well defined spec or “client brief”. I suspect this works better when you have a single client for each project as I’ve had at past jobs. But building things with only a single user in mind is disastrous in a SAAS context. Whenever we merge a pull request, our change can affect 20,000 users. I don’t want to scare people away from pushing to master, but having that perspective in mind is important. This is a different mindset to building for one client.
The other thing we learned was to have weekly scrum meetings to check in a project’s status. I’ve since learned that project teams should meet daily, or not at all. On more complicated projects we do in depth daily standups. These can go for up to half an hour but keep everyone on the same page, even as we move fast. On simpler projects, we try to keep deliverables as simple as possible, and not have meetings. There’s no sense doing daily standups on a 3 day project. Either way, all our other processes create easily accessible feedback loops, so everyone who needs to know about a project, does.
Wrapping it up
If we had a motto for all this it would be “If in doubt, ask a customer. If you’re still in doubt, ship it and find out.”
Most of the processes in this post have evolved over time and through trial and error. I’m sure there’s room for improvement. If you have comments or feedback, I’d love to hear them!