How We Work #1: "Expect to be Done"

Ryan Singer, Basecamp's head of Product Strategy, starts out a multi-part series by talking about how we decide what to work on every 6 weeks. From the strategy, to pitches, to project selection, to project budgeting, to integrated teams, to the expectation of completion by the end of the cycle, this video sets the foundation for what comes next.

[@AJSmart]

Absolutely love this!

[@michaelminton1684]

Thank you for this! Excellent overview and I'm very much looking forward to learning how Basecamp is able to ship so often.

[@alexitosworld]

Really nice! Can't wait for the next parts of the series.

[@piotr803]

This is some illuminating stuff, Ryan. Looking forward to the next installments.

[@gwynap]

This is great, thanks! Looking forward to the next one! I have changed my 'To Do' list to an 'Ideas' list and created a 'Slate' list with only the things I expect to get done on. It is currently clean....

[@BrayanBedritchuk]

Thanks so much for sharing!

[@SteveHazel]

that is good stuff! even (especially?) for a lone developer on his hobby project.

[@mixy2647]

Thanks for sharing your process publicly Ryan! It is always very insightful to learn more about how Basecamp works I can understand that: - small batch teams will take care of a bunch of small product enhancements - big batch teams will take care of new features or bigger things What about bugs? Are they taken care of by a "bug" team that works without cycles? Thanks!!!

[@pedrosaadialvesdeaquino7111]

Thanks for sharing! Great content here. One question: How often do teams miss the delivery in the 6 week cycle? Also, in this situation, how often is the cycle extended? i understand the benefits of narrowing scope rather than giving more time, but I feel a little unsettled with the notion that each project is a bet, and if we can deliver it on time we just give up. It's seems more reasonable that if we can burn two more weeks of work to finish the project we should do it, rather than throwing away all the 6 weeks worth of project.

[@feltpresence]

> 80% of all projects ship on time. Sometimes we have to go over a little bit, and on rare occasions we cancel the project because something went wrong with the concept. We don't just give ourselves six weeks and hope for the best. We apply specific strategies to manage the scope and track our knowns and unknowns throughout the cycle. I'll cover those in the upcoming videos.

[@ShankarBalachandran]

Hey Ryan, Thanks for this. It's quite helpful. I am curious to know what happens in the case that the 6-week cycle did not yield the expected results. You mentioned they may not get an extension, but is the batch discontinued or refactored or moved back to another cycle later?

[@feltpresence]

That depends on the project and why it didn't work out. We will look at this in closer detail in chapter 4. If the project ran over because of an illness, for example, and the remaining work doesn't contain any worrisome unknowns, then we may extend for a week or two. On the other hand, if a project reaches the end of the six weeks and there are still some core unresolved problems or unknowns, then we can't expect an extension to yield a solution. In that case we'd conclude something was wrong about the core concept, shelve it, and come back in the future when we have a different point of view about how to solve it. In general if something goes wrong with a project, we'll set it aside and set up a cycle that feels like a sure win to build up morale before tackling that same problem again. And it's also possible we won't come back to the project for a long time. Not every project we take on is a "must" and we may be able to survive just fine tabling it and waiting for a better idea to strike.

[@fahrradflucht7723]

Hey Ryan, you mentioned in this video that you have non-product teams that aren't working in 6 weeks cycles. I would be very interested in learning more how you come up with, plan and cycle work in these contexts. I think for example you have a Security, Infrastructure and Performance team? What translates there / how do you stay "calm" in these areas and prevent never ending projects?

[@johnumandap]

Great content! May I ask, is majority of the UX work done in the pitch stage, or is it done when it's already budgeted for and within the cycle?

[@feltpresence]

You'll see a little more of this in the upcoming videos. The concept is presented in the pitch as a rough sketch, more lo-fi than wireframe but clear enough to communicate the idea. That counts as UX work, but it's only the broad strokes. Most of the work is done within the cycle by the UI designer. We don't have an explicit handoff between design and dev. It's a very integrated piecemeal process, where design gets a few key affordances in, dev wires those up, design polishes and moves things around further, dev gets more things working on the backend, etc. They work together on the same code base.

[@selvermaric4378]

Ryan thank you very much for sharing this, we're currently in phase of tweaking process in development. You said you work separately on problem and solution, I am interested is your work on problems public on your Basecamp account or that happens outside of the Basecamp. Also, how do you show this "Defining the work" part inside of your company Basecamp account.

[@feltpresence]

When the work is defined enough that it can be written up as a Pitch, it goes onto Basecamp for other people in the company to see. Before that point, it's more private - on somebody's desk or maybe worked out in some private collaborative sessions.

[@MagnusAnand]

Nice video

[@methochris]

what software is this that you used to make the diagram?

[@feltpresence]

I made the diagram in OmniGraffle.

[@MachoMaster]

There is a problem of your head taking space and we are unable to see some parts of the chart. Therefore: 1. Could you please release this chart in .pdf or whatever other format with link in the description? 2. Don't remove your head-shot. It is much nicer to see somebody's face instead of only looking at the chart. The size of your face-video-window is also ok. But could you please next time be more cognizant of how much space your face window is taking and make sure that we are able to see every piece we need to see (for example when reviewing each subpart of the chart like Strategy/Budgeting/etc)? 3. Thank you for showing the whole chart in the beginning of the video. I hope it wasn't by accident and it will continue. May I suggest showing the whole chart at the end of the video as well? Thank you for the video. It is very interesting and I am waiting for the next parts!

[@davidbcg286]

You could find this visual on Twitter: twitter.com/rjs/status/982681205740113920. The direct link to the image is here: pbs.twimg.com/media/DaMvSYuWsAA0fEB.jpg:large

[@alexitosworld]

kudos for asking this in such a nice way 👌🏻

[@MachoMaster]

DavidBcg. Thank you!

[@feltpresence]

Yes, I've posted the map here: www.feltpresence.com/how-we-work The inset video will cover some part of the map at a given time, but I'm taking care not to cover the parts that I'm actually discussing at each point in the video.

[@MachoMaster]

Ryan Singer. Thank you. Perhaps you could put this link in the description of every video?