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.

Precision. Certainty. Specificity. Everyone wants to know exactly what and exactly when, and they want a statistic attached to corroborate it. But numbers are rarely answers — just as projects are rarely math problems. Where are we in this process exactly? How far along in this project are we exactly? Where does everything stand absolutely? There are no equal signs after those statements. There are all sorts of things in life that you want but can’t have. Exactly is one of them. Creative work thrives on subjective interpretation. You can establish an end date that’s fixed, but where you are is really up to you. Yes, in some specific businesses with ultra-specific standardized widget-making processes, it’s possible to expect and require perfectly precise forecasts. But that’s almost certainly not yours. The quest for knowing exactly has preoccupied entire industries with impossible answers, and pushed entire categories of tools towards the wrong trends. You can find out where things stand. But the answer is a human one, not a digital one. It’s fuzzy, it’s a bit abstract, and it’s more a feeling than a figure. It’s taking stock of all the things that can’t be measured, and speaking or writing the actual answer, not pointing to an abstract number. “63” means nothing. “We think next Tuesday” means something. As long as humans are making things, it’s best to ride along with human nature. To follow that seam, rather than to cross it. This is what we’ve been doing as of late in Basecamp. We’ve been adding imprecise, humanizing features to project management. If you want false precision, you have plenty of other choices. If you want a system that represents what’s really going on, here we are. For example, take Basecamp’s Hill Charts and Move The Needle features. They are visual representations of where individual scopes of work, or entire projects stand, based on the flexibility and subjectivity of someone’s mind and hand, not a computer’s representation of rigidity. Both tools use graphical markers — either a dot or a needle — that people physically move around and place on a subjective scale based on an understanding of where something stands. It’s not precise, it’s approximate. “About here.” “Feels like we’re this far along”. That imprecise wiggle room is also known as the truth. You can see how both features work here... Hill Charts: https://www.youtube.com/watch?v=sZKJD-l3W6E Move The Needle: https://www.youtube.com/watch?v=D0urtIQrFyQ Subjectivity is a good thing — a human thing. It’s with the grain. Subjectivity and productivity are partners, not adversaries. Over time we’ll be adding more imprecision like this to Basecamp. The more we can reflect reality, not a false premise, the better off teams will be. We know that, we believe that, and we’ll continue to promote that. -Jason