MoreRSS

site iconJason Fried

Founder & CEO at 37signals (makers of Basecamp, HEY, and ONCE). Non-serial entrepreneur, serial author. Wrote Getting Real, Remote, and REWORK.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Jason Fried

Making it happen vs. Letting it happen

2024-11-15 01:52:38

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

High and Low

2024-11-01 06:33:53

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

Version 1 is for you

2024-10-24 05:19:39

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 with that, I want to remind myself, and everyone else, that we should be focused on building products for ourselves first. v1 is for us. Others will find alternative uses for products we build, just as they have with Basecamp. And we may suggest alternative uses to expand people's imaginations, and the market for the products. But every feature in v1 of Basecamp existed because we needed it. Nothing was imagined for anyone else. Over the years we've of course made changes to products to adapt to the needs of customers, while not straying too far from home. That's good. But v1 is sacred to us.”

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

The Teenage Engineering TP-7

2024-10-12 04:34:12

Teenage_Engineering_TP7a.jpg


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

Don't have a biggest customer

2024-10-09 23:33:31

On X, Dinesh Kherajani asked:

"How should you handle a customer who has outgrown your B2B SaaS product? The customer has been using it for years, but has scaled up and no longer fits your ICP. This is one of your largest customer."
(https://x.com/DineshKherajani/status/1843539478864114113)

My answer:

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