Over the past few months, our newly minted Android team (Jamie, Jay, and myself) has been hard at work on some shiny new Android stuff. And while we can’t share it yet (soon, I promise!), we’ve learned a lot about how to rapidly prototype, explore, and most importantly ship these new ideas within Basecamp.

Like any new team, it took us a bit to find our groove. But in the past eight weeks, we’ve really hit our stride. Now we’re moving quickly and making great progress, without causing ourselves a lot of anxiety or creating undue risk.

So I wanted to share a bit about the strategies that have been working for us. I hope these can help other Android (and even non-Android) product teams out there.

Here’s what we do…

We ship internal builds to the Basecamp team every two weeks.

We scope most of our work into two week cycles of design, programming, and testing (excluding QA). Some of the work might be carryover from a previous cycle (like a design exploration), but the programming is from scratch.

Having two week cycles puts us into a shipping mindset that encourages focus and discipline. Issues can’t linger — we have to make quick (smart) decisions. And we have to be ruthless about cutting scope down to what’s shippable.

Of course some ideas will take longer than two weeks to finish. If we decide to tackle those, there is one criteria: they can’t be exploratory, they need to be well-formed, solid ideas. If something is going to spread out over a few builds, then it has to be worth the investment.

We pick a theme for our build cycles.

Very early on we wrote up 5-6 big themes that we wanted to focus builds around. While these themes changed over time, the idea has stuck and has been an invaluable part of our process.

Every internal build now goes out with a theme that gives everyone a 1-2 sentence idea of what they’re going to get. For example, we might theme a build as “Get to things faster on every screen”. These themes achieve two important things:

  1. It broadly sets the Android team’s development goal — the goal we should measure our work against every few days.
  2. It gives everyone else at Basecamp a nice tl;dr of what to expect. When someone picks up our build, they should be nodding their head in agreement with the theme. If not, then we’ve missed the mark and need re-evaluate what we’ve done.

We kickoff right after our last build ships.

Two weeks isn’t much time to plan, design, program, test, and ship. So right after a build goes out, we spend an hour or so going over our open themes, bugs, and considering where we are in the big picture. Then we pick a theme, assign ourselves work, and get cracking.

The discussion itself is very fluid, and is driven by a variety of factors – technical considerations, overall progress, design ideas, and even logistics like vacation schedules. For example, Jamie is going on his month long sabbatical in July. That was a signal to Jay and I that we should spend as much time as we can now on design executions, and leave architecture and plumbing for July.

We balance low-level programming work (not as much fun) and UI work (more fun) as best we can.

We suffered from this imbalance a bit early on. We spent our first couple builds firming up our foundation and working on our testing tools and suite.

This was all good and necessary, but we started to feel a little stuck. Even though it wasn’t true, it felt like we weren’t making great progress because it was harder to see the fruits of our labor. Perception can be reality, sometimes.

So we started balancing our themes better. We started taking more shots at UI work that felt more rewarding, while never ignoring our foundation.

Over the last few builds, we’ve done a better job of balancing these, and it’s really showing in the quality of our work and the happiness of our team.

We involve our QA team early and often.

The QA team comes in right after we ship. The sooner we have quality eyes on major areas, the better off we are, period. Our QA team does a great job identifying not only bugs, but also big picture UI and product considerations that could impact one of our next cycles. These are often things we don’t notice because we’re too close to the work day to day.

We’re rigorous about shipping.

Even though our self-imposed two week deadlines are arbitrary, we respect them. We close our to-dos, write release notes, and bring in QA. If we’re going to ship, we’re going to ship like we mean it.

We keep our progress visible.

This sounds obvious, but we keep our to-do lists updated and we share heartbeats regularly with everyone at the company. This not only helps manage the day to day, but it helps to communicate a clear picture of what we’ve been up to. Everyone feels free to jump in and give us direction, offer new ideas and advice, and even simply say a few words of encouragement!

We recognize there will be cold streaks.

Sometimes we’ll absolutely fly through stuff, and other times it feels like we can barely type. It happens to everyone. We respect our shipping deadlines, but know that everyone hits a cold streak now and again. We encourage each other to keep at it and to ship as best we can.

We plan for the future a little bit at a time instead of all at once.

We don’t excessively plan, but we do spend 30 minutes here there considering our next few cycles. The idea is to not get distracted from shipping our current build, yet recognize the value of organic conversations and ideas to the bigger picture. It’s important not to lose sight of the end goal, and doing this a little bit at a time helps with that.




There is one important footnote to all of these strategies: the biggest factor for success is the makeup of our entire team. Jamie and Jay are great at what they do. And our designers, programmers, support team, writer, and video producer are all great teachers and listeners — we’re lucky to have them backing us all the time.

Put that all together, and we know we can create something great for our customers. Stay tuned!