37signals

Want to visually track how work progresses through stages? Basecamp's Card Table might be just what you need! Join our support team for a live class tomorrow at 1:00 p.m. Central to learn about our take on kanban. Save your spot here: https://lnkd.in/gX33AvDT

HEY Calendar is now more accessible and easier to use with a screen reader. Check out the latest improvements in this short video.

Initial feedback shouldn't derail your confidence. Hear more about product launches and initial versions in this week's REWORK episode with David Heinemeier Hansson and Jason Fried — V1 is For Us.

Are you terrified to open your email because this happens? Lose the trauma today and start using HEY. #email #gmail #unsubscribe

While it's great for development teams, Basecamp works for finance teams as well. Yesterday, I had the opportunity to answer a question from one of our community members about how to set up finance and accounting processes in Basecamp, so I figured I'd share it here too. Here's a screenshot of our main accounting project. To-dos are essential for the day to day in accounting. The most important one is the month end close to-do list, which is set to recur every month. We've upped our game in terms of process documentation, so the to-dos are enhanced with detailed instructions or links to longer process documents. There are two sets of Documents in this project.  Financial Docs retains all of the necessary monthly documentation related to the close - account reconciliations, bank statements, vendor expense schedules, etc.  Process Documentation houses all of the long form process instructions that we've written over the last couple of years. Not all of the finance work can be done in Basecamp, so we set up Doors to link to our Bank, Payroll, GL and Expense Management systems. Finally, we utilize the Client functionality to allow for async communication and file sharing with our external tax accountants. Financial information is sensitive, so the project is set to be invite-only. All of the history is there. Every discussion or comment when new issues emerge. It's a great way to keep the team organized and in the know, and a dream scenario for any new finance or accounting hire that needs to onboard.

Curious how our team uses Basecamp to QA Basecamp? Join us for a live Office Hours session – Wednesday, Nov. 6th at 10AM Central/11AM Eastern. Our Quality Assurance team will walk through their Basecamp projects, share best practices, and answer your questions. Save your spot! https://lnkd.in/gVSHK9Z3

The latest news from 37signals

Quality Assurance (QA) is a team of two at 37signals: Michael & Gabriel. Check out their post on how they use Basecamp and the Shape Up framework to test our software products! https://lnkd.in/gDiY45fm

Do you have similar workflows across numerous projects? With Basecamp, you can create project templates from scratch, or create one from a project you're already using. #basecamp #projectmanagement #workflow

VERSION 1 IS FOR YOU A few weeks ago I was at our company meetup in Montreal, on stage in a big room in front of everyone, sharing progress on two brand new products in development. We went one at a time. First Product 1 for a half hour, then Product 2. The lead designers for each product were driving, and I was talking. The products projected on a big screen behind us, in front of everyone else. As I walked through the products, I kept citing use cases. I cited ours — after all, we were building these products for us, as we always do — but then I shared a bunch of hypotheticals. “Imagine...” “Someone could...” As I was saying this, I was recoiling inside. But I went through with it as the show must go on. Perhaps it was a touch of insecurity given how early along we were with each product. I felt like I had to bolster them somehow. And there’s no better way to prop something up in the moment than blathering on about all the imaginary things it can do for all the imaginary people! The demos went well, but a few days post meetup I wrote up an internal long-form announcement in our “HQ” project in Basecamp. The HQ is essentially our intranet, and it’s where we post announcements that go out to everyone in the company. We use it in lieu of email, which is a terrible way to make private announcements. Essentially I admitted I regretted sharing all these alternate use cases. They were a distraction, blurred vision. The misdirection was a mistake. Then I said: “And with that, I want to remind myself, and everyone else, that we should be focused on building products for ourselves first. v1 is for us. Others will find alternative uses for products we build, just as they have with Basecamp. And we may suggest alternative uses to expand people's imaginations, and the market for the products. But every feature in v1 of Basecamp existed because we needed it. Nothing was imagined for anyone else. Over the years we've of course made changes to products to adapt to the needs of customers, while not straying too far from home. That's good. But v1 is sacred to us.” And that’s the key, really. v1 is for us. No one else. Others will use it, many will resonate with it, but ultimately, v1 is ours. It’s sacred ground. There’s an eternity to change, tweak, modify, grow, expand, and adjust for everyone else, but there’s only a fixed amount of time to make that perfect version 1 for us. To tie the knot on the reason we made the thing on the first place: Because *we* needed it, because *we* wanted it. We don’t do MVPs here. I don’t believe in MVPs. I think they’re the lowest of the lowest bar, an insult to product development in general. What’s less inspiring than something that’s Minimally Viable? We do what I call MPV1s. Maximally Proud Version 1s. Version 1 won’t be everything to everyone, but it’ll be everything to us. Just what we need, and nothing more. And we’ll be proud of every part of it — and also what it isn’t, yet.