When we make something new, people often ask "why don't you just add that to Basecamp?" There are a number of reasons, depending on what it is. But, broadly, making something brand new gives you latitude (and attitude) to explore new tech and design approaches. It's the opposite of grafting something on to a heavier, larger system that already exists. The gravity of existing decisions in current systems requires so much energy to reach escape velocity that you tend to conform rather than explore. Essentially you're bent back to where you started, rather than arcing out towards a new horizon. New can be wrong, but it's always interesting. And that in itself is worth it. Because in the end, even if the whole new thing doesn't work out, individual elements, explorations, and executions discovered along the way can make their way back into other things you're already doing. Or something else new down the road. These bits would have been undiscovered had you never set out for new territory in the first place. Ultimately, a big part of making something new is simply thinking something new. -Jason

Whenever I talk about working in real-time, making decisions as you go, figuring things out now rather than before, I get a question like this... "If you don't have a backlog, or deep sets of prioritized, ranked items, how do you decide what to do next?" My answer:  The same way you do when your made your list. You make decisions. We just make decisions about what to work on next as we go, looking forward, rather than making decisions as we went, looking backwards. Why work from what /seemed/ like a good idea before? Instead, work from appears to be a good idea now. You have more information now — why not use it? It's always baffled me how people who pluck work from long lists of past decisions think you can't make those same kinds of decisions now instead. It's all yay/nay decisions. Same process. Before wasn't magical. Before was just now, then. Why not look at now, now? Now is a far more accurate version of next. The backlog way is based on what you thought then. The non-backlog way is based on what you think now. I'll take now. One's stale, one's fresh. We'll take fresh. Then is further, now is closer. There's nothing special about having made decisions already. They aren't better, they aren't more accurate, they aren't more substantial just because they've been made. What they are, however, is older and often outdated. If you've got to believe in something, I'd suggest putting more faith in now. -Jason

One of the great lessons of nature: Randomness is the most beautiful thing. Every forest, every field, every place untouched by humans is full of randomness. Nothing lines up, a million different shapes, sprouting seeds burst where the winds — or birds — randomly drop them. Stones strewn by water, ice, gravity, and wind, all acting on their own in their own ways. Things that just stop and stay. Until they move somehow, another day. The way the light falls, the dapples that hit the dirt. The shades of shades of shades of green and gold that work no matter what's behind it. The way the wind carries whatever's light enough for liftoff. The negative space between the leaves. Colliding clouds. The random wave that catches light from the predictable sun. The water's surface like a shuffled blanket. Collect the undergrowth in your hand. Lift it up. Drop it on the ground. It's always beautiful. However it comes together, or however it stays apart, you never look at it and say that doesn't line up or those colors don't work or there's simply too much stuff or I don't know where to look. Nature's out of line. Just right. You too. -Jason

Not too long ago, we dedicated a 6-week cycle to improving Basecamp's onboarding flows. The aim was to increase conversion from trial to paid by smoothing out the initial experience of getting going, doing a better job of quick-teaching the basics, and making a few things a little bit easier each step of the way. At a high level, these were the projects in that 6-week period: Adding a sample Getting Started project with steps and basic education. Streamlined project creation (reducing it to one step from the previous multi-step process) and exposed all the tools upfront. We also removed the wizard option. Revamped and simplified the blank slates that introduce unused tools. Refreshed the sample project for creating a podcast (great cross-functional example people could relate to). Sped up creating a new account (people used to have to wait a few seconds while the sample projects were generated). Added an email reminder that the trial was ending soon. Dropped the other sample project so we didn't overwhelm with examples. Rewrote the Hey! menu onboarding messages/tips so they were easier to follow. The result? A huge 30% increase in conversion. 30%! As anyone who works in this field knows, conversion improvements (without tricking people) are usually a grind. You're typically thrilled to see any results, and often have to parlay small single digit improvements into more single digit improvements, hoping to eventually hit double digits. Yet somehow, this time, we managed to find our way to a 30% increase. And we have no idea how. And we don't care to find out. What was it exactly? Was it just one of the things that really mattered? All of the improvements together? A handful of small improvements that tipped into something bigger? Don't know, don't care. We spent six weeks on the work, we did our best, and something worked out really, really well. We're thrilled with the outcome, and that's enough for us. That was the point in the end, wasn't it? You could make the argument that we should have tried each thing separately, measured each impact, and then decided where to go next (or known when to stop). You could make the argument that changing so many things at once makes it impossible to know which variables actually mattered. You could have argued we should have been more rigorous in our evaluation so we could learn something fundamental we could apply to a future project. You could argue all those things. While you were debating those points, spending months teasing out answers, or testing each change in high-traffic succession for statistical significance, we were already basking in the results and moving our product teams to the next project. In six weeks all the work was done, we did our best, and it worked. The point wasn't to know, it was to do. And it was done.