Jason FriedModify

Make it happen!

You hear it a lot. And it's generally good advice, of course. At least the 'happen' part.

You definitely want things to happen. But often times, it's the 'make' part that gets confused for progress.

You can push a ball uphill, but should you? Not only does it take a ton of effort, you can't really see what's over the edge until you get to the top of the hill. So you use all this effort to just find out if it was even worth the push to find out.

Contrast this with starting at the top and letting the ball roll downhill. Rather than make things happen, you let things happen. The hill, in this case, is the process, the team, the environment you've built to allow things to happen gracefully. To glide, not grind. To roll into a view you can see, with the gravity you get for free.

That's the way. Less force, more momentum.

What you must make happen is the way you work, the people you have, the trust you've built, and the way you work together. Once you've made that happen, you can let a of other things happen mostly on their own. Less huffing and puffing, less exhaustion from always pushing up hill, less of a feeling of starting from ground zero each time.

This doesn't mean you get to lean back, hands clasped behind your head, feet kicked up on the desk, with a cigar in your mouth. But it does mean you have more faith in the machine you've built to make all the other things you make. It surely makes things quite a bit easier, and there's no shame in that at all.

-Jason

Problems are often described by their size. "Hey, that's a big problem". Or "Eh, that's just a little issue, no big deal." And if you do hear someone say “serious” you immediately think huge. It’s still about size.

I sometimes still use those descriptors, but I'm trying to use them less. Instead, I’m reframing problems as High or Low.

High problems seep. They stain. They coat what's below, like melted frosting dripping down a cake. Gravity always wins, and high problems eventually become low problems too.

You see this in relationships. Little problems don't add up to big ones - it's the big ones that create the small ones. Something small really annoying you about someone? Good chance it's because something bigger is annoying you more. High problems leaking down, staining what’s underneath.

You see this in organizations. People bickering about flaws in someone's work or style? It's not because all is right above - it's because something's spilling from above. Bad hiring, lax oversight, proper examples not being set. High problems are like water hitting dry sponges — they don't just soak in, they make everything swell and distort, turning small issues into bigger ones than they should be.

While it's possible for small things to pile up and color what’s above, that direction is rare. So when you encounter low problems - especially ones that wouldn't seem noteworthy to an uninvolved observer — it's safer to assume they're symptoms of something bleeding from above, rather than growing from below.

-Jason

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 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.

Version 1 is all about being selfish. You’ll make a better product that way. For you, and, ultimately, for them too.

-Jason

I finally picked up a Teenage Engineering TP-7.

I've been experimenting with dictating random ideas lately. And while the phone is typically more convenient, I wanted to have a separate recorder on my desk.

The TP-7 is an absolutely charming piece of hardware. Reminds me of all the things I loved about some of those high precision portable Sony products from decades ago. But miles better.

It's such a tactile delight. The clicks and friction and spinning disk and toggles and tilts and materiality. The tiny dotted LED display, subtle drops of color. The tight tolerances. The quirky UI. The depth of "oh, I can do THAT with THIS?" discoveries. The feeling of something esoteric being fun to master. The few-too-many controls at first glance that eventually feel right at home.

Yes it's pricey, and yes there are plenty of alternatives for far less coin, but for me, the inspiration is priceless. And supporting people doing unusual, high-quality, high-design things is worth it. I just like playing with the damn thing. I like looking at the damn thing. It gives me all sorts of ideas for my own work.

I just adore functional objects like this. Incredible imagination, incredible work.

-Jason

People outgrow all sorts of things. Clothes, houses, jobs, relationships. And yes, software and services. It’s part of the natural order.

If they no longer fit, wish them well. If you can help them fit in a way that benefits your customer base as a whole, then local accommodation equals global improvement. That can work.

But there's a deeper issue here, and it's wrapped in the statement "one of your largest customer[s]".

While many think having a "largest customer" is an asset, it's actually a company's biggest weakness. If you can feel a single customer leave, you're in a delicate spot. If you have a customer you can't afford to lose, you're in an even worse position. Now you're no longer a sovereign company making your own product, you're a consulting firm making custom software for that biggest customer, or others like it. Now you're tethered. Not good.

So what do you do? Cap your prices. Don't let anyone pay significant more than anyone else. Have a customer base that looks like even static, each one's financial footprint essentially indistinguishable from another. So if any random customer left, you wouldn't feel it — or fear it.

I wrote more about this, using our company as an example, here:

-Jason

The problem with software estimates is that they're both entirely right and entirely wrong.

Yes there's a 3 week version of something. And a 6 week version. And a 4 month version. And a 12 month version. That's correct.

Yet, you'll almost always be wrong whichever you pick. Because estimates aren't walls — they're windows. Too easy to open and climb through to the next one.

The 3 week version will turn into the 6 week version will turn into the 12 week version. You can see right through.

Software that encourages you to estimate how long something will take makes it even worse. That software is part of the problem. You know which products I'm talking about.

So what to do instead?

Set an appetite.

A appetite is like a budget. Not "we think it'll take 4 weeks" but "we're only giving it 4 weeks." That's all we've got set aside for it. Then the team tasked with the work has to get creative and figure out the 4 week version of that feature. There is no 6, 8, 10, or 12 week version when the appetite is 4 weeks. Just like there's no $7,000 vacation when you only can afford a $2500 one. And you know how that ends up if you overspend.

Are there times when you need to give something another week? Maybe even two? Yes. There's some margin for that because it can only happen once per project, and it's commensurate with the time spent. You don't double the time, maybe you give it 10% more time if you need to. A little margin for error and reality is built in there. This isn't absolutist, this isn't fundamentalism.

And yes, there are times when things aren't completed within the time allotted, and there's no obvious, honest path to finishing it with a touch more time. In those cases the project dies, we internalize, and hope that doesn't happen again. It rarely does here at 37signals, but it has. It's part of the cost of doing things this way. The payoff is huge, the downside is limited — that's a tradeoff we can live with.

-Jason