10 things I learned from Jason Fried about Building Products
Jason is a savage.
Myself and my co-host Jake Knapp had our first guest on the 10th episode of the Product Breakfast Club Podcast, and it feels like we should just cancel the show because there’s nowhere to go from here. CEO and “product beast” extraordinaire Jason Fried shared his worst kept product design secrets with us, and I suddenly realised that I have no ideas of my own. Almost everything I do was inspired by his work.
As the head of 37 Signals, later Basecamp, he wrote two books (ReWork and Getting Real) that provided some principles for both Jake’s Design Sprint and my company, AJ&Smart. He was such a massive influence on both of us — in the YouTube version of the podcast you’ll see that we were both a bit starstruck to interview him.
But how did he end up on the podcast? It all started with a Tweet that caused a bit of a shit-storm amongst us delicate designer types:
It’s a controversial statement, to say the least, and the Twitter conversation started to veer off towards the necessity of testing, so we reached out and ask Jason if he’d like to discuss it on our Podcast. He said yes (be careful what you wish for!) and we we’re chatting a few weeks later!
1. You can only iterate on a shipped product
A product changes in thousands of large and small ways during its lifecycle. But at what point do you call these changes “iterations”? Jason thinks that until the product is shipped and actual people are using it in real-life situations, everything is theoretical. All the revisions prior to launch are done to an unfixed, WIP version of your product, and the thinking that motivates those changes is guesswork. The first time you get actual feedback is when your product is live: that’s your threshold for iteration.
That all made sense, but Jason’s reasoning implied that feedback prior to launch is not necessarily that useful. What with the Design Sprint being centred around testing, we were curious to find out what he meant.
2. Testing is not failsafe
Jason illustrated his point with a Basecamp anecdote. They recently released something that the entire team had been using and testing for a long time. When they were satisfied with how it worked internally, they shipped it, and unexpectedly, the sh!t hit the fan. Basecamp users were not happy, and the team couldn’t have been more surprised. It had worked for them before, so what went wrong?
Any sort of testing only provides simulated answers. Looking at something and judging it is not the same as using it and judging it. There’s no skin in the game, and you can’t imitate the pressures that users will endure in everyday situations. (Which is also why you can’t ask people how much they would pay for your product.)
Context colours everything. Products can’t be evaluated in isolation, and there’s often a danger of “designing by anecdote” based on memorable interviews that highlighted one person’s imagined experience.
But context is also important to the extent product teams are familiar with their subject matter. Basecamp is working on its own dog food, but if they were designing medical testing software, they’d be less daring about shipping so fast. In some instances, testing is indispensable. In others, you shouldn’t even think about it. It all comes down to weighing up cost vs. value.
3. Consider cost and value
In everything they do, Basecamp is driven by identifying meaningful work and discarding what would only slow them down. They always try to “squeeze out” any opportunities for distraction: what doesn’t matter is probably more important to define than what does.
Will testing improve the product? Undoubtedly. Enough to make the cost worthwhile? For Basecamp, the answer is often no. If testing uncovers something worthwhile in 5% of cases, then 95% of those interviews were in vain. Are they willing to take that risk and iterate on the live product instead? Absolutely!
Nothing will ever be perfectly buttoned up, and with hundreds of thousands of people using Basecamp they’ll have immediate quantitative feedback to work with.
4. Changing software is easy
There’s no excuse for not iterating on software. Unlike a (non-smart) watch or a high-finish car, software is malleable, never finished and can be improved ad infinitum.
Back when Jason started out, making changes to software was slow and cumbersome. He had to use Filemaker Pro to upload an executable standalone database to AOL, and after a successful server update users had to download the new version and do an individual data migration. Yes, it goes above our heads too, but when there were so many hurdles in the way, you thought twice about updating anything.
That simply isn’t the case today. Deploying is fast, you can iterate in minutes, and updating is mostly automatic so there are very few technical constraints holding you back.
5. The more you second-guess, the more you lose traction
Technology is not an excuse, but “polishing” your product shouldn’t be, either. When you have a strong, opinionated original vision (be it a product feature or a Medium article), second-guessing it will only water it down. And if you think about it long enough, it will never happen.
Once you question the initial concept, you’ll start implementing new ideas, which lead to inconsistency, and an endless cycle of trying to match up with the rest. You’re setting yourself further and further back, without knowing if your efforts matter at all to your audience. As Jason said, “I’d much rather second-guess 6 months after release.”
You see a lot of lengthy posts detailing the 8-month process of redesigning a brand, involving 42 people across 7 different disciplines. The last Basecamp redesign took a single designer 7 weeks. It’s all a question of approach.
6. Work in the way that works for you
Too many companies set themselves unattainable standards and compare their own approach with the success of Apple and Google. It’s crucial to be self-critical enough to match your size and status with the right mentors and examples. Google, Apple, Netflix and Spotify are EXTREME outliers with vast resources and a massive scale matched by only a handful of companies in the world.
Many companies will also just adopt a trendy tool or methodology without considering whether it suits their unique culture and habits, and when the next new thing comes about, they rinse and repeat. 2 years into the “innovation lab”, often there’s no innovation to show.
Jason is very intentional about the way he runs Basecamp and they have devised unique habits that work for them. They are lean, ship and iterate often, and they work in 6-week development cycles. That means that whatever they do has to fit into that cycle from idea to delivery: a constraint that defines what they build and how.
7. Protect the time and attention of your team
The №1 thing you have to nail down before designing any other workflow is making sure that your employees can do the best work they’re capable of. That means eliminating any stressors and distractions. Jason Fried protects the time and attention of his team by making sure that:
- They don’t work overtime. A working day is eight hours long. If you’ve ever been on a transatlantic flight with nothing to do, you know just how long that is… Jason firmly believes in an hour as a good unit of work, as opposed to four 15-minute blocks or other disruptive divisions. Their work week is 40 hours in winter, but from May to September they only do 32 hours a week. 32 hours! Keeps you on your toes.
- They have the day to themselves. People need large stretches of time to do focused work, and the cost and stress of interruptions is higher than any potential wins. For that reason they almost never have meetings at Basecamp. Preposterous, I know, but they seem to be doing just fine.
- They have time to recharge at the end of the day, to pursue other interests, sleep well, enjoy the summer sun without guilt, and come back to the office refreshed.
- There are no shared calendars. You are the master of your own time, and people respect that. No one’s day is spent being dragged into sorting other people’s obligations.
Jason himself is a big advocate of staying focused and doing one thing at a time, and his 12” screen doesn’t allow him to multitask. These are some of the ways in which he enforces constraints that are good for the people and the product alike. When you’ve only got so much time at your disposal, decisions become swift and there’s no time to second-guess.
8. Make a call and move on
In their 2016 Letter to Shareholders, Jeff Bezos revealed that decisions are sped up at Amazon by applying the “Disagree and Commit” principle. Stakeholders can express their disagreement and explain their reasoning behind it, which ensures that their viewpoints are fairly considered. But once a decision has been made, all of them have to commit to it.
This thinking was familiar to Basecamp. They unsentimentally recognise that whichever feature they build, or layout they choose, will do an okay job and won’t matter that much in the end. So when debates start getting repetitive, a designated “Points Person” makes a call and they all move on — a practice not unlike the Decider’s role in the Design Sprint.
9. Build a star team — don’t hire one
Jason admits that learning the quirks of working at Basecamp is not easy, but it pays dividends. They hire about 2–3 people a year: from about a dozen people in 2006 they’ve now grown to a size of 56 employees. They currently have a hiring freeze — not because they couldn’t find work for more people, but because they want to be selective about how much they take on.
They’re very intentional about the way they hire: it’s not about poaching star developers from AirBnb, but finding often overlooked talent that has the potential to truly bloom. Relying on the guidance of a few committed, core longtimers, they’ve built an all-star team (though they didn’t hire one). Their average tenure of 5 years is significantly higher than the industry average of 18 months, proving that their crazy ideas about work-life balance actually work.
10. How to run a product company
Finally, here’s a summary of the practices and beliefs that built up Basecamp’s success:
- Trust the work you do and stop second-guessing. Do your best, ship it soon, and have faith in your team’s abilities.
- Keep your team small for as long as you can. You’ll move much faster.
- Don’t expect superhuman effort. Look after people, ensure they have the environment to thrive and grow, and don’t work them overtime.
- A company is all about making decisions and carrying them out. Be intentional about both and know how to move on.
- Plan well. Establish realistic deadlines, get very good at scoping. Don’t put undue pressures on your team.
- Define meaningful work and squeeze out everything else. Minimise distractions.
- Don’t adopt tools and practices blindly. Identify what works best for you.
