#musings

I pay hardly any attention to anything that can be considered the “tech du jour”. When it comes to tech I’m a late adopter (if not a laggard), and unapologetically so. Sometimes I miss out on really cool tech that works amazingly well, but most of the time new tech is a dead end. Either it doesn’t catch on, or it does but it doesn’t work well, and even then it’s likely to get displaced by the new hotness in just a few years.

Take smart devices. Are smart home devices here to stay? I don’t doubt it. Do I want to have my house filled with the kind of smart devices that are for sale today? Absolutely not[1]. Smart devices are still hobbyist devices. For people who enjoy tinkering and the never-ending process of making different brands and protocols work together. Do I want a wifi-enabled garage door opener that breaks when some cloud service goes down? I don’t. Nor do I have the patience to upgrade the firmware on smart lightbulbs.

That these smart home devices don’t work properly isn’t the worst thing. The worst thing is that they demand constant time and attention and that the process of getting things to work is never educational. You can’t get “good” at home automation. You just google and mess with config settings until it starts working and then you hope it will continue to work for as long as you don’t touch it. (If only!)

I like to fix things such that they stay fixed. And I like to learn skills in the process that will serve me well for the decades to come. Because it’s this combination that allows you to move forward and go fast. The more fragile tech you use the more energy you waste on ducktape fixes. The more fashionable your tech is the more energy you waste memorizing minutiae. And then you have to migrate your stuff from the old way to the new, starting the process all over. Chasing new tech can feel like work, but you’re really just tiring yourself out without getting anywhere.

Once you’re on the lookout for durable tech you find nondurable tech everywhere. Web frameworks have notoriously little durability. When you memorize the concepts of a web framework you gain short term productivity, but you don’t acquire any fundamental knowledge. If you’re not careful you’ll spend your entire career chasing the new hot thing in web tech.

If you learned Javascript 10 years ago, haven’t used it since, and decide to make something today, it’s very easy to get back up to speed. Browsers have gotten amazingly fast, but this benefit you get for free. You now have “let” instead of “var”. You have real dictionaries instead of Object. In total there are maybe 100 new additions, and you can learn about all of them in an afternoon or two. JavaScript has gotten way better, but fundamentally it’s still the same language.

By contrast, if all you know is jQuery (15 years old) or AngularJS (10 years old) you now have a way steeper learning curve ahead of you. Frontend libraries like these don’t age well, and everything you memorized about the “angular” way to develop applications is not worth anything anymore. If you decide to learn another framework, React maybe, then you risk investing in what could turn out to be a technological dead end. Will reactive design be the way we develop apps in the next 20 years? Probably not. And apps built with “legacy” web stacks? They become unmaintainable, so you’re pretty much forced to rewrite them. Good luck finding people who want to work on an Angular 1.0 app in 2022.

Software written in C 20 years ago still works flawlessly today. Old DOS games can run in Dosbox or a browser emulator. Webapps that are a hairball of ducktaped libraries and microservices fall over unless you do constant maintenance. Some tech endures while other tech falls apart. The difference is night and day.

You want to invest time and effort in technologies that clearly won’t go away. Becoming good at vim or MS Excel might not be an optimal time investment, but the time isn’t wasted because even 20 years from now vim will be vim and and excel will be excel. Being able to ssh into any machine in the world and being able to effectively edit files is extremely useful today just like it was 10 years ago. When you’re good at Excel you can quickly crunch some numbers and plot some charts. Why spend days or weeks on dashboards that track metrics when you can do the same in Excel in a fraction of the time?

Durable tech skills are knowing fundamentals of C/C++, Python, JavaScript or any other mainstream programming language. You can learn vim, bash, strace, and rsync. These utilities aren’t going anywhere. You can learn algorithms and you can learn how to relational databases work, instead of some company’s proprietary API or ORM. Write things yourself, from scratch, with as few dependencies as possible. This way, once something works it will continue to work, maybe forever.

I can’t predict the future, but one trend is clear. Simple, monolithic systems that are rock solid tend to continue to work. Fragile systems composed of many libraries, services, and glue code start out unreliable and never seem to get better. Look for durable tech and try to make things that last.

[1] the only smart device I own is a Spotify connect receiver that stops working every 2 weeks and the only “fix” I found is to hard reboot by pulling the power cord. It also has HDMI CEC which works 70% of the time.

Imagine two startups. One startup makes a business chat app similar to Slack. The other startup has a business wiki product. In principle, these are very different apps that solve different problems. In practice, both apps face constant pressure from their customers to become more like the other.

Users of the chat app start demanding threaded discussions, archived discussions, pinned discussions, rich text options, and the ability to draft responses. Any individual feature might make customers happier and increase retention and conversion rates, but mindlessly adding all these features will turn a good product into an unfocussed mess. You end up with an ugly hybrid app that is half chat half wiki. It doesn’t have a clear audience anymore.

You can see how a wiki app can end up in the same place by adding more and more messaging features. Different chimera, but equally bad.

It’s a problem that all b2b SaaS apps struggle with. If you say yes to every feature request your product eventually turns into a platform product like Office 365. Customers always ask for Forms, workflows, calendars, project management, chat, writing, and email features. And they’re not wrong to want a single integrated solution as opposed to a hodgepodge of overlapping products. If they like a product they want it to solve more of the problems they have. So what is the app developer supposed to do?

As a SaaS vendor you have a couple of options. One option is to embrace the platform vision. Max out on engineers and build it all. This is the Google Suite, ZoHo and MS Office 365 strategy.

A second option is to stay strictly on course. You build out your narrow product and make it the best it can be without adding any platform features. Instead of making your product wider you go deeper. You keep your focus and you refine and perfect your product, and users will have to use an API for everything else. You get really good at saying “no” to customers. The big disadvantage of this approach is that you spend a lot of time making small improvements only a handful of powerusers care about while ignoring the features your customers really want but that don’t fit neatly in your product vision.

A third option is the “tiny platform” approach. Instead of building a whole platform you only build the easiest 5%. You implement a couple of key features of each platform product and go no further. This is the Basecamp approach. The big disadvantage here is that you end up with a product that is okay at many things but doesn’t excel at anything.

A fourth option is to make your product an add-on to an established platform like Office or Google Suite. You focus on your product features and you can provide integrations with the other application suite products for everything else. This strategy makes a lot of sense, except, you tie your future to a 3rd party that really doesn’t care about you. It’s a precarious position to be in. The platform owner can pull the plug at any time. One day you’ll wake up to an automated email that an API function has been deprecated. Your app stops working. Your customers are angry, you are helpless, and years of work go down the drain.

There is no correct approach to this platform dilemma. Software is never finished and you can always keep building and building in any direction. Build in the right direction and you’ll get many happy users. Build in the wrong direction and you’ll attract the wrong kind of customers that will push your product even further away from product-market fit. That’s why it helps to have a clear platform strategy. It can tell you when to say no.

This is what we have to figure out for Thymer. Thymer will have task management and planning features, but this has some overlap with the features provided by conventional calendar software. And everybody already has a calendar app that Thymer can’t realistically replace. Neither can Thymer replicate all major functionality people have come to expect from calendar software. So what do we do? Do we go all-in on API integrations with 3rd party calendar software? Do we tolerate scope creep and reimplement all calendar features we think are important? Do we add a minimalistic calendar to Thymer and accept that users will still have to use a different calendar product on the side? Or should we kick the can down the road in the hope the correct answer will become clear in the future? I don’t know.

There is a ton of startup advice out there, and much of it is contradictory. Let me explain what I mean with some examples:

• Entering a crowded market: It’s smart because in a crowded market you can always find people looking for a new product. Or: It’s risky because it’s difficult to make your product stand out from the crowd.

• Product pricing: You should charge as much as possible, that way only you need to find a handful of customers to become “ramen profitable”. Or: make your product inexpensive so you can undercut competitors and enjoy free word of mouth marketing.

• Rapid prototyping: Smart because it allows you to quickly validate if your business model works. Or: It’s unwise because if you rush to market your product won’t be great.

• Originality in product: It’s good because people don’t get excited about things they’ve seen before. Or, maybe, it’s bad because it means you’re solving a problem that doesn’t exist or nobody cares about.

It’s not hard to come up with arguments for or against anything when it comes to software startups. This is in part because the world of software is big. Strategies that make sense for a lavishly funded startup in the valley won’t work for a bootstrapped company in Japan. A biotech startup has different constraints than a simple web startup.

Contradictory startup advice is also common because there are many different ways to get a company off the ground. What worked for others in their particular situation probably won’t work for you. Different time, different product, different market, different people. Every startup is unique and the world is changing rapidly.

When you get or read advice ask yourself if the opposite could be equally true. It easily could be. It’s up to you to figure out if you should follow well-meant advice or do the opposite. It’s rarely obvious. So take the time to really think everything through. As a rule of thumb, you can learn the most from founders that are slightly ahead of you and that have a product in a similar but different market. Then you can look at what they do and see if it works. What does their marketing and sales strategy look like? Is their product good? Do people talk about their product on social media? What do they say? How and where they they get their first users? If you keep your eyes peeled for evidence like this you’ll learn a bunch.

Especially as technical founders, when designing a product, it’s fun to think about everything it could be.

However interesting that might be for us, it’s important to not get carried away too much when it comes to actually building the product. It’s great to have a vision of where things could go and explore those a bit, but we need to keep the first version small. It’s not easy saying no, especially to your own ideas. Working on whatever you want is a big reason to run a business in the first place, but to increase the chances of success, the order in which you work on something matters.

The type of ideas we like to work on is where the long term vision of a product is sufficiently large, but where the very core, the smallest possible version, is very small (although very small is relative depending on the stage of your company of course). Working on something which could potentially be used by many many users all over the world makes the problem that more interesting to work on for us. But if we want to start up and grow, especially as a bootstrapped business, we need to be able to build the first version quickly.

Thymer is a good fit for us with these requirements. If we manage to get traction and get to the point of lift off, it’s easy to see how we could keep developing the product into a larger vision. Because it’s a very horizontal product, a feature like plugins alone could grow it into a platform, to become a control center of sorts for managing everything you need to work on or organize in your life.

At the same time, the core vision is really easy to describe: an IDE, but for planning/tasks. This alone is plenty of work, so we’re building just the (polished) parts which convey the core of that vision. That this core vision is oddly specific (many people will have no idea what an IDE is) is a good thing. It might be tempting to think building “project management software” is a better idea because it’s a huge market, but it’s very vague, has endless scope, doesn’t offer ways to reach any audience in particular, and there’s nothing unique about it. You can’t launch with a generic “platform” on day 1.

In the beginning you need the focus: reduce the scope on the product side so you can launch faster, and find a niche on the market side to find initial fans.

Building a huge product for everyone from day 1 makes it incredibly hard to succeed. In terms of marketing, paradoxically, if the product is for more people (everyone!), the less people will care. It’s just not exciting for anyone in particular, so it’s harder to reach initial passionate users that way. Plus, building up any kind of momentum takes time. If you spend years building, it needs to be an overnight success on the day you launch because you’re out of time. That’s a huge gamble. Instead, always be launching. When launching something small first and then building more on top while it’s already out there, you can do the momentum building and product building in parallel. There will be many more “launches” this way to generate some renewed interest with every add-on or new development.

On the building side, if you only keep building, you will eventually run out of runway. Even with a large runway, the longer it’s going to take, there’s a chance you’ll simply run out of motivation. And as long as you’re building in the proverbial basement, you don’t train your launching muscle. It’s easy to get bogged down in details which don’t matter that way and drift further and further from the shores of actual user/customerland. You also don’t get any feedback, so by the time you get new insights from initial users, it might be too late to course-correct.

Another risk is that by the time your “perfect” product is finally finished, it’s obsolete, and you need even more time to make it “perfect” again. That’s not to say you need to go on some death march either, or stress out about being the fastest and worry about competition all the time. There’s usually plenty of time, but markets and trends do move on eventually, so taking too long does have risk. All in all, the chance you will really launch something successful in the end will go down.

And yes, we all know some counter-examples of products being built over the course of years to become an instant hit. But that’s a lottery, and you don’t know all the many examples where it didn’t work, where launching that way failed, and the movie/book about its story was simply never written.

Next to the approach for building a single product, this also applies to what ideas to work on. In other words, it’s easier to build Zip2 first before you start SpaceX. Start small, keep it simple, grow from there.

We’re making a todo/planning IDE. Think Visual Studio Code for tasks and projects. For our startup to work we have to get three pillars more or less right: product, business model, and marketing. Marketing because you don’t get anywhere when nobody knows your product exists. The business model is the part where we figure out how to make money. Most importantly we have to make a product people love.

Product

We want to make Thymer text based. The design trend over the last decade has been towards shiny interfaces with lots of whitespace and poor usability. Software has gotten easier to use but also dumbed down a great deal. We want to go in a different direction. We want higher information density, a text based interface, extensibility, and we don’t want simplicity at the expense of powerusers. On these things we are high conviction.

We have a clear vision of what we want to build. If we deviate from this vision based on early feedback we’ll end up with a product that lacks cohesion and that nobody will get excited about. We can pivot somewhat, but we can’t change what our app is fundamentally about. If it turns out that people just don’t want this kind of software (or don’t want to pay for it) we’ll throw in the towel and build something else.

Marketing

These are some of the marketing channels we can use to get the word out:

• Social media (reddit, hacker news, linkedin, discord, other communities)
• Google ads, Twitter Ads
• Youtube channel
• SEO marketing pages to boost organic search engine traffic
• Twitter
• Magazines
• Blogging
• Guest spots at podcasts
• Guest blog posts
• Bulk deals (e.g. Appsumo)
• Integration with 3rd party products or protocols
• Viral features/word of mouth

We won’t know which marketing channels will work for us. Presumably one or two marketing channels will end up producing the bulk of the traffic. We’ve just got to try everything and we’ll discover what works in the process.

When it comes to marketing and distribution we’re low conviction. We’ll have to figure it out as we go. As long as we get traffic and trial signups I’m happy.

Business model

On principle we’re only willing to try a couple of business models:

• Freemium (mostly free users; small percentage upgrades to paid)
• Freemium + B2B SaaS (also have subscriptions for businesses)
• One time fee for lifetime access
• Pay for usage or flat fee?

We don’t want ads in our product, but any combination of free+paid we can try. We can make some educated guesses on what works, but ultimately consumers aren’t rational agents. How much users are willing to pay, if anything at all, depends on emotional factors that are hard to forecast. Can we charge based on the value we provide? Will customers price anchor based on competitors? Will customers feel strongly that software should never cost more than $X? We don’t know. Needless to say, with regard to pricing, we’re low conviction.

If we can’t drive enough traffic to our website to get trial signups in volume, then maybe we’ll pivot and introduce features that appeal to businesses. As we wrote about earlier, a business subscription is easily worth 30x a single user subscription. A B2B SaaS product can thrive on a trickle of traffic.

Marketing is the real bottleneck and biggest unknown. Given enough traffic and enough trial users I’m confident we’ll be able to fix all major issues in our product and the business side will take care of itself.

One of the hardest parts of running a startup, next to doing the actual work, is knowing what to work on. There’s a seemingly endless list of things screaming “highest priority level”. One category in particular can be very distracting and time-consuming: deals and partnerships.

Especially when starting a business for the first time, all these deals can easily be mistaken for validation and important work, where in fact most of it is playing shop. The extra difficulty comes from the fact that you need just the right amount: you need to stay the course, but sometimes it helps to tack to beat against the wind.

The danger in saying yes to everything is that you just end up wantrepreneuring away your time. Most time should be spent on building your product, and talking to actual users. It’s very easy to spend all day jumping on calls with other startup folks, join in competitions, going to conferences, hang out with business networking groups, and not end up with a better product or a single customer. Trickier still are offers which actually look like they’re helpful. Especially when you just launch, you might see your inbox fill up with those very quickly, from amazing ad campaign offers to requests for collaborations.

One of those typical offers is a potential customer (or even an actual existing customer!) reaching out with an idea to get extra business. Wow, you just launched, and not only do you have a very passionate customer, but they’re willing to think along, have ideas of their own and spread the word for you!

What makes this difficult is that the common advice is to listen to your customers and use feedback to improve your product. But in my experience, anything more than getting feedback to learn more about the problem space, so you can then improve your product based on your own ideas, is a huge distraction. Proposals for deals or partnerships are cheap, and it will most likely be a lot of talk with very little result. Quite often you will end up becoming more of a freelancer building a solution which is only great for one customer. Stay the course and stick to your original mission.

We made this mistake too at the beginning. A customer reached out and thought our horizontal product would do especially well in their vertical. Perhaps we could white label it? They had a huge network in their market and were convinced they would be able to sell this easily to many of their customers and businesses in their network. Especially being technical founders, and only just having our first customers or two, only having to write a bit of whitelabel code and having someone do the sales to bring in even more, that’s amazing right? They just needed a few features which would be really critical for this market.

You can see where this is going. Only they ended up using the whitelabeling and extra features, for their own business. They never managed to refer anyone else or reach any other businesses. And of course why would they? Running your business is your job, not theirs. They aren’t as invested, it’s just a random idea for them. We all have random ideas, the execution is the hard part. Only as an owner of the business are you willing to do the actual hard work of building and selling, no customer is going to actually want to work as hard on that as you are.

Related offers to do affiliate marketing or marketing outreach for you will usually have the same result. Most of the time this just ends up being a way for a customer to ask for a discount or free plan in return for maybe telling others about your product. A better deal is to just not waste time on this and see if they want to pay so you have an actual customer.

Another very good example are emails from private equity firms or invitations to “chat” about investments or even potential acquisitions. If there’s a mother lode of distractions so large they can cost you your business, then this is it. But there’s so much to say about this (plenty of anecdotes there ;), that’s probably better for another post sometime.

The point is to remember with all these deals is that most of them will fail. They seem like a shortcut but they’re just be a distraction. What really moves the needle in the end is just improving your product and going to where your customers are to talk about it. The only caveat here is that sometimes saying yes increases your luck surface. Many good things in life can happen because of random connections, and business is no exception. As a rule of thumb that’s why I usually only say yes when the distraction is not too big and it’s either fun or to help someone and pay things forward. But time is limited so choose very wisely and say no most of the time to stay the course.