#business-general

Durable tech

Diederik • @jdvhouten • • Part of Day 67

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.

The Ancient Roman Bridge, a Timeless Engineering Feat | by Richard Bruschi | History of Yesterday
This roman bridge is I don’t know how old, but it’s still here.

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.

Early user feedback

Diederik • @jdvhouten • • Part of Day 65

When you launch the first version of your product it’s likely to have serious flaws. If you want to discover what these flaws are you’ve got to figure out (a) what your users use your software for and (b) what changes you need to make to make them happier.

This sounds trivial, but it’s not. Especially when you’re busy building you can easily forget to pause and think in this critical phase and shred your chances for future product/market fit in the process.

First, you want to know what your users are trying to accomplish. This tells you if your users are who you anticipated using your software. If you have the -right- kind of users you want to figure out if your product website is targeted at them, and if your marketing efforts are successful at reaching them.

What do I mean by “right users”? Well, very early adopters tend to be different from the users you’ll get down the road. Early adopters are more technical, care more about power-user features, are less inclined to pay for software, and more likely to give extensive feedback. This initial set of early adopters is really valuable because they are so willing to help. But in most cases your core customer base will be different and also have different priorities. This mismatch is dangerous. Early adopters can lead you astray.

It’s not just early adopters that are unrepresentative. Any users that use your product in ways you hadn’t anticipated are dangerous to listen to. It’s too easy to get persuaded your app needs to grow towards a very specific niche, when really, by doing so you alienate 90% of your real user base. Always listen carefully to all feedback, but if the feedback comes from the wrong type of user it’s best to stay the course. If you really need to make a big change in direction your users will continue to remind you, so no need to do anything rash.

The world is a big place. If your first 100 users are lukewarm about your app it could mean that your app stinks. But maybe your app is just confusing to use for the first time. Or maybe your website gives the wrong impression. Lack of enthusiasm is not a great sign, but neither does it mean you have to pivot or redesign or start over. Minor tweaks will do. Look for a new set of users from a different pool, and see if you get a better reception.

Remember that users who give feedback unprompted are outliers. You’ve got to reach out to the quiet users, too! Track, in the most primitive way, whether users are active. If you have users who use your app every day for a month that’s a very clear sign you’re on to something. Email them, and ask them what the #1 feature is they’d like to see. It’s so easy to do, and you might discover that this quiet set of users are your core market and deserving of your full attention.

Solicit feedback in the app itself. Add a feedback button. Maybe add a poll so users can vote on something. Lower the barrier to give feedback — any feedback — as much as you can. This way you’ll get feedback from a wider group of users. And be really responsive and thoughtful in your emails to users. Most people expect poor customer support, so they won’t go out of their way to write down what they think. If you get the chance to surprise people with good customer support they become way more likely to suggest improvements to your product.

However, be weary of people who email you pages of ideas but who haven’t really tried your software yet. It’s a lot of fun to talk to people and to get excited about the different directions your product could go in. But it’s also a distraction if this conversation is with people who haven’t really explored your product. When people have a pressing need they really try to use a product to see if it solves their problem. They’re willing to put up with flaws and shortcomings in your product as long as you get the vital stuff right. And if they haven’t tried your product that tells you something. Which user sends the feedback is as much of a signal as the content of the feedback.

As for the features/changes you want to make, we’ve written about that before. In short: make the first impression really good and nail down the core user experience. Many good features you won’t have time to build for another year or two and that’s normal.

Products want to be platforms

Diederik • @jdvhouten • • Part of Day 63

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.

Enjoying the journey

Diederik • @jdvhouten • • Part of Day 61

I’m back from my holiday! We went on a simple road trip from Eindhoven to Marseille, at the Mediterranean sea, with plenty of stops along the way. We enjoyed some good food, hiked in nature, did some sightseeing, read some books. Now I’m well rested and excited to get back to work.

Whenever I sit down at my desk after being away for a while I get the opportunity to look at my work with fresh eyes. We tend to work on our projects for a long time. Years on end, usually. It’s easy to lose focus of the big picture when you’re always heads-down working. Stepping back for a while can give you valuable new perspectives.

Sometimes, when I return from a break I feel energized and ready to continue working right where I left off. This is the best case scenario. Other times, I ask myself why I’m working on this specific thing, when I could be working on any number of other things instead. In a conventional job it’s the responsibility of other people to figure out what what’s important and what you should be working on. When you make your own products you have to figure it all out yourself. Breaks are a great time to think about these big picture questions.

Taking a break costs time. There is no denying that. If you don’t plan ahead for breaks your schedule will slip. That’s a little bad, but not a disaster by itself. What really matters is choosing the right things to work on and actually launching. Launching a week or a month or a quarter late doesn’t matter in the big picture. It’s still better to move fast, of course. But direction matters most. We’ve picked a direction with Thymer and we’ll launch with only essential features. This reduces the risk of we waste a lot of time time building the wrong thing and it’s easier to make big changes to small products.

Although our goal with 80daystartup is to get a product from 0 to market in a short time, we’re still in it for the long haul. Making a simple product that is good enough to charge money for is really just the first step in a much longer journey. Ultimately, we need to make a pretty great product to get the kind of traction necessary to make Thymer work as a business. That’s going to require rewriting big pieces of our app and ripping out those parts that don’t work. Ideally, we get everything right in the first beta version. But if the future turns out anything like the past then we’ll make some big product mistakes. It will take some iterations to fix those and to get to really great product market fit.

And even then, that’s still only the beginning. Turning a good concept into a rock-solid commercial product is a ton of work. If Thymer really takes off we’re likely to work on it for years before it’s really “done”. And that’s fine! We enjoy writing software, and we enjoy seeing people use the software we’ve written. We don’t know if Thymer will work out. We’ll discover in due time, but no matter what we’ll enjoy the journey.

Work-life balance

Wim • @wcools • • Part of Day 60

We’re going to take a quick break and will be back with our daily updates on April 11th. In the meanwhile, you can find a preview of what we’re building at Thymer.com, or check out the list of all our posts or the recaps of the work so far.

From the start on Day -1, when we built this site, we added a note in our FAQ on how we would work on the 80-Day Startup. Rather than working for 80 days straight, we decided we would take breaks too. Some of the cliches about running a startup being a rollercoaster are really true, and there’s a lot of different tasks to juggle at the same time.

For our 80-Day Startup project, on any given day we can work on a combination of code, graphics/UI design, marketing, growing an audience, writing blog posts (more work than we expected to be honest!), replying emails and DMs, configuring a server or anything else that needs doing.

Next to that we’re running our existing SaaS business, with similar work as well as all the work that comes with an established product like customer support, sales, finances, content marketing and so on. Some days we wake up to new MRR because new customers signed up completely organically/passively, while we’re getting to work on cool new features. Another day there’s a tricky bug to fix, some boring task to work on, while a customer churns at the same time.

That’s all just part of the thrilling ride, and for us there are way more highs than dips, so we both really like working on all of this.

90-Hours/Week and Loving it!!

But it’s exactly because we like working on it so much that the breaks are important. When it often feels like a hobby, it’s too easy to fill up time with work, and there’s lots of other things to explore and experience too. Being in perpetual crunch mode is unhealthy, and also totally unnecessary. When we worked on our very first product, back when we were students, we also had work-weeks of 60h or 80h, next to a side job and studies, but there’s no reason to keep doing that.

As we’ve seen over the years we’ve been doing this, growing our existing business at a healthy pace is totally possible. We focus on the things that matter, stay productive, and automate a lot. That’s why we’re building a new product in exactly the same way. It’s the only way to keep running rollercoaster marathons.

Whether it’s life stuff, traveling the world or something completely different, we want to keep plenty of space for that too. And if you would worry about productivity, we can say we always return more refreshed and more productive, easily making up for the time we take breaks.

So we’re going to take a quick break now. Diederik will be on a trip. I will be away later and do a bit of work for our existing business for now.

If you’re new to the blog, you can find all the posts we’ve written so far at Topics & Days. We post a (roughly) weekly recap, so to get a quick summary of what we’ve been working on so far, you can find those at recaps.

If you’re a binge reader of the blog (thanks for following us!), this might give you some time to catch up (we noticed it’s quite a lot of posts by now ;).

See you back in a week!

Making sense of contradictions

Diederik • @jdvhouten • • Part of Day 56

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.

Trust signals

Wim • @wcools • • Part of Day 55

When comparing products or services, one important factor in choosing which solution to go for is trust. We know we are looking for certain trust signals before buying services as consumers ourselves, so we need to make sure that as makers we address those same questions and concerns too!

This is especially true for the kind of product we’re building. It’s not hard to come up with concerns potential customers might have. With any SaaS product you want to know it will remain online, your data is secure, people care about your privacy, and so on. Especially when trying out a new product from a new startup, you want to make sure it sticks around.

The “close tab” button is your biggest enemy, and just the tiniest concern you don’t address can cause people to not even give it a try. As I wrote before, people are going to look for answers to these concerns anyway. So you can either address them yourself, or people will leave your site, look for answers on sites you don’t control (and maybe come back, who knows). You might think people will take the effort to email you if they need an answer, but it’s much easier to “close tab” and look for something else.

Luckily, addressing most of these signals really don’t cost a lot of time:

About page

This seems too obvious to even list here, but just really, just mention something about you or your team somewhere. When launching your MVP, you really don’t need to publish a complete biography. Even something like a link to your Twitter profile will be enough. Software is so anonymous, and is literally written by folks on laptops on different sides of the planet these days. People like to not just buy something, but from someone (especially for B2B, buying something when it says just [email protected] in the footer is going to be a harder sale).

Social media/online presence

This is actually a mistake we’ve made for our first product. We noticed that when we didn’t have an easy way for people to find recent activity about us online, they seemed worried about the product being abandoned. I don’t have sufficient data for this to claim any statistical significance, but whenever we didn’t tweet for a while on our company twitter (which we link to in the footer of the product’s website), it seemed like we somehow converted less people.

We even had people contact us asking if the product was abandoned, because they couldn’t find updates (on our Twitter or other social media, probably). And this was just after we had completely redesigned the product a few months before and we were very happy with how polished the product was now. Ouch. But it makes sense in a way, people have probably been burned before by some startup with poor support, so it’s just another trust signal.

Fast support

We always aim to answer any support emails really quickly. This is related to software being very anonymous, and it just shows there are actual humans involved and that we really care (and good support is a USP too!)

Security/privacy policy & GDPR

Especially with SaaS products, you want to make sure customers can see you care about their data. More than anything, these just show you’ve put thought in it at all. And next to it being the right thing to do, some things are simply required, for example GDPR compliance.

This is probably a topic for another post, but especially when launching your very first version to validate an idea, it doesn’t need to be anything super complicated. It already helps a lot to have a nice FAQ-style page to address the biggest concerns. How will you handle cancelations, data erasure, data export, how do you store your data and so on.

Better than trust

Speaking of security, ideally you wouldn’t need to trust a company much at all. In the case of Thymer for example, we would really like to look into end-to-end encryption (E2EE) at some point. We will launch with encryption in transit and encryption at rest from the start, but I don’t think we’ll have time for E2EE in our very first version. We can’t build everything at once, but it’s good to think about which features can address the largest concerns for not signing up first.

Testimonials

This isn’t possible on day 0 with zero users, but as soon as you have some users, ask them how they like the product and whether you can add their reply to your website. Related to this, one of the things people will usually look for is reviews for your product. Make sure you reply in those places when people have questions. You can even create your own “X reviews” page and rank for that, so you can guide people to different reviews and include your own support structures when they have questions.

Bugs

Every product is going to have some bugs and glitches, that’s hard to avoid. Some bugs are so embarrassing however, it just signals you don’t care at all. Of course you won’t have infinite resources to make everything perfect, but prioritize fixing critical flaws. Some bugs there’s just no coming back from. Fix it or people will stop trusting your product.

Taxes: an automation story

Wim • @wcools • • Part of Day 53

I got reminded of wanting to write this post because it’s that time of the year again here, where we have to prepare and file our business tax reports. This is something which always used to cost a lot of time and money, and I just happend to notice others in my Twitter timeline joking they wouldn’t be able to get any real work done the next two weeks because they had to work on this.

We try to automate all our processes as much as possible. For many tasks, instead of being a team of a two, we try to be more like a team of two plus a dozen of little scripts/bots. By automating things like invoicing, server monitoring, and yes, even things like accounting, we’ve managed to cut overhead significantly. That way we can just focus on product and customers, which made it easier to scale without the need to hire as fast as other similar companies.

In this case, dealing with accounting/filing taxes is a perfect example of how we automate things. Even with having thousands of transactions to keep track of for our existing product, the entire process took half a day. And the only reason it takes half a day is because our government doesn’t offer an API to avoid having to manually enter the data into their forms. [1]

Obviously this isn’t an option for everyone. It helps we can create these scripts ourselves and that we can vertically integrate all our systems this way (although a lot more nocode options are available these days, too). Perhaps we take automation a bit too far at times, but I also don’t agree with the other extreme of “outsourcing everything”.

The popular advice goes along the lines of “you should always outsource X, because it’s not core to your business”. The problem with that is that the process to run an effective business is a core feature too. It’s an internal product, which can really give you an edge if you can operate faster and more efficiently. It’s the product that builds the product.

Accounting and filing taxes has absolutely nothing to do with our core business. And yet, by automating this ourselves, and making it part of our “business stack”, we’ve saved a lot of time and money which we could spend on our products instead.

We almost always start out with a process being completely manual. For example, when we launched our first product, we couldn’t even bill customers yet! And because Stripe wasn’t a thing yet, we had to manually charge customers every single month. For that stage of the product, it was the right amount of automation though: we had no idea if it would take off, and the manual process was still manageable for those initial customers. Our priority was validating if we could get customers in the first place.

As the product grew, we automated billing and charging for subscriptions. Invoices would be generated automatically, sent out to customers and saved to our database. We even automated keeping track of different currencies, VAT rates and so on. Then the business grew even more, and we got larger business customers who wanted to pay by wire transfers, outside our automated credit card system. And of course by this time we also had other software/hosting vendors from all over the world where we got invoices from.

All in all, when it came to our accounting, we had this large .zip file with all invoices, but there was no automated balance sheet, list of ledger accounts or journal combining all these transactions. Every year we had to spend a week or more unifying everything from bank and credit card statements, Stripe invoices, vendor invoices, salaries and much more into a neat double-entry bookkeeping Excel file.

When your work gets replaced by a Python script

Obviously, we didn’t have time for this, so we tried outsourcing first. It was a total disaster. Long story short: accountants over here do everything manually (which is absurd when even small indie companies can have have thousands of recurring subscription transactions), don’t understand SaaS, don’t understand selling internationally, or much of what we need at all. We even tried a very expensive large accountant firm. Same story. Everything they did was manual, full of mistakes, and they even managed to not file a bunch of critical reports at all. In the end we spent even more time, having to verify and fix their work on top (if you’re an accountant reading this with an interest in startups: our market could use an “accountant for SaaS” product). All this to say, that this is the part where I think it’s too easy to think outsourcing will fix all your issues: much of what gets outsourced just won’t get checked/verified. It will most likely be full of mistakes, and that has costs too.

In our case, the cost of mistakes and pain of not making this process part of our business stack was larger than the one-time cost of automating it. So we automated the whole thing with a bunch of Python code, and named the program after the accounting firm we thankfully no longer needed. John.py – not their real name 🙂 – is now part of the product that is our business, is integrated with all our systems, and takes care of all the accounting. From handling bank statements, to invoices to generating balance sheets and fiscal reports. And because we assert everything, it is correct down to the cent. It costs $0 per year.

We’ve been able to postpone a hire and spend time on interesting features for our customers by automating this completely. Perhaps automating accounting makes absolutely no sense in your case, but there will likely be other parts which, when considering your business as a product which can have moats of its own, are better to integrate and automate than outsource.

[1] I think there is some way to partner with the local tax office if you’re an accredited accounting software vendor to get access somehow. We’re so allergic to manual processes that I must admit it’s very tempting to apply to become one just for the single purpose so we can file our own taxes quicker, although that’s probably a real waste of time 😉

Magical thinking

Diederik • @jdvhouten • • Part of Day 52

Most startups fail. Some startups don’t launch at all. Maybe the founders get into a big fight, or they lose interest, or the product is too hard to build, or something else throws a spanner in the works. Other startups launch but don’t get any traction. Either they get no signups or the users don’t like the product. The founders then get discouraged and quit. Then there are startups that pass the first two hurdles but stumble at the third hurdle: they launch and get a bunch of happy users but they fail to monetize. Failure at different stages but failure all the same.

With our app we really want to pass all three hurdles: launching, marketing, and sales. There is some luck involved and we can’t discount the possibility we’ll fail as well. Things beyond our control can take us out. That’s part of the game and we accept that. What we don’t want is to fail because of unforced errors. We don’t want to do dumb stuff that predictably results in failure. We want to learn from other startups what works and what doesn’t.

I’m going to describe three different startup failure scenarios that I see time and time again. I’ve anonymized the stories because my goal here isn’t to make fun of people who failed but to analyze what happened so we can learn from it.

Our fictionalized founder makes three apps over the years:

  1. a desktop app that helps you organize your music collection on Linux
  2. an iPhone app that tracks and charts your grocery expenses
  3. a job listing webapp

The projects fail for different reasons but with a shared root cause. I’ll get to that later. First let’s go over these startup attempts.

Attempt 1: Linux music library app

Two common pieces of startup advice are to (1) build with the skills you have and (2) solve a problem you understand well. Our protagonist takes this advice very literally and decides to make a desktop Linux app. He has written software for Linux before and he knows he can make a better app for organizing your music.

Our heroic founder spends nights and weekends to get his music library app done. He starts coding in c++ for performance reasons, but eight months in he decides that programming that way just takes too long. The product architecture got a bit messy, so he decides it’s time for a rewrite in Rust. He doesn’t know Rust, but it’s a cool new language with smart memory management that he wanted to learn anyway. Fast forward a year later and the app kind of works. At this point the founder no longer has much passion for the idea. He’s not convinced people will buy his app. Working for two years straight in isolation is a long time and he decides he it’s time to launch. He spends two days on a website, but our protagonist has no web design skills and it looks pretty bland. He submits his site to Hacker News, reddit, and sends the link to some friends.

Crickets. His website gets a few dozen visitors. A download or two. Traffic drops to zero after a few days. Frustrated, the programmer abandons his project. He tells himself that failure is inevitable on the road to success. That failure isn’t real failure if you learn from it. He reflects on why his startup didn’t take off and concludes that the fundamental problem is that his app didn’t have a big enough audience because Linux is too niche. He figures he should have made something for “regular people”, instead. He also decides he should make something simpler.

With full determination he decides to try again.

Attempt 2: iPhone app for grocery expenses

Our founder has no particular passion for grocery phone apps but he figures that everybody shops for groceries so it should be a good and large market. If he charges $10 then for every 0.01% out of a billion iPhone users that buy his app he’ll make a million dollars (less 30% Apple fees and taxes). Previously the founder struggled with distribution and now he has Apple to take care of this for him. He also doesn’t need to worry about invoicing, credit card payments, or any of the other annoying business-y stuff anymore.

Our protagonist starts building. A year and two rewrites later he’s happy with the product and submits his app for review. His app is approved and soon after he gets the first sale! Making your first dollar of internet money very exciting. Then again, a trickle of downloads and one $10 sale per week won’t cut it if you need to make a living. But what to do? Lower the price? Ads? Rename the app? Change the logo? Translate the app to multiple languages?

Six months and many experiments later our protagonist is ready to give up. He can get more downloads if he charges 99¢ but he’s still only making beer money. Switching to in-app purchases results in more downloads, but getting people to upgrade is no mean feat. A few mean app store reviews later he’s completely done.

Okay, lesson learned, he thinks to himself. Next time, he’s going to make something SIMPLE with BUSINESSES as customers.

Attempt 3: job board

With renewed spirit our founder gets to work. Where previously he spent the better part of a year to get a prototype going now it’s just a matter of weeks. Job boards are pretty easy. What do you need? A place for people to look for jobs in their region. Search and filter by keywords and requirements. Done. What else? A backend for employers to submit new job openings. He decides a job listing costs $100 for 30 days. Slap a credit card form on the page and done.

This time our founder has a plan to get users. He’s going to contact hundreds of companies and recruitment agencies over email and LinkedIn with his pitch. He figures that by charging less than the established players he can win their business.

No dice. Companies just don’t want to advertise on an empty website. And job-seekers have no reason to visit an empty job board either. Catch-22. Our protagonist decides to reach out to a more experienced founder and asks for advice. The secret, he’s told, is to cheat. Create fake listings, fake users. Fake it all. Once you’ve got real companies and real job-seekers you can phase out the fake traffic.

The founder can’t believe what he just heard. That’s an ethical line he doesn’t want to cross. Disgusted, he concludes that startup life just isn’t for him.

Retrospective

Three attempts over many years amounted to nothing. Every time the founder believed he learned from his mistakes and would surely succeed next time, but he was wrong. The founder didn’t get anywhere because he learned only specific lessons: don’t make a Linux app; reaching the top of the App Store charts is hard; you can’t bootstrap a marketplace from nothing without cheating. The founder didn’t discover the root cause of his startup troubles and consequently didn’t learn anything of value. He could try five more times and he would continue to fail if he did.

The fundamental mistake this founder made is that he tried to arrive a good startup concept by reason. You can come up with reasonable sounding arguments in support for the most hopeless ideas. “Good arguments” therefore carry no weight at all.

Instead, the founder should have looked for evidence. Have other people found success with commercial desktop Linux apps for consumers? If yes, how did they succeed? Did they bootstrap, self-fund, or take VC funding? How did they find an audience? Can you find the wreckage of other people who tried what you’re about to do but failed? Why did they fail? If you can’t find success stories that’s big red flag.

It’s easy to explain failure with hindsight. There is no commercial competition for Linux desktop apps because Linux users don’t pay for software. The Apple App Store by contrast is highly competitive. You have to figure out why apps succeed and fail in app stores before you spend a year on an app of your own. You need a captive audience of businesses and professionals in search of jobs before you start on your job board or you’ll fail. But these specific explanations are not important. What matters is the process of looking for evidence that supports or invalidates your startup idea before you commit. The alternative is magical thinking and it looks like this:

The diagram doesn’t look like this in the founder’s head. The founder has all sorts of strategies and plans that sound great, but plans that aren’t backed up by evidence are just wishful thinking. If you remove everything based on wishful thinking what you’re left with looks like the flow chart above. Build. Launch. Pray. Give up. (Repeat.)

The founder also made many other mistakes. But so what? Everybody makes mistakes. Mistakes can be fixed if your startup gets the important things right. Your best best is making an original product for an established market and by applying sales/marketing strategies that are known to work.

Written like this it seems trivial. But it’s not. I see an endless amount of magical thinking by founders who earnestly believe that just making something and hoping for the best will work out for them. I’m not judging, though! We’ve also spent years on hopelessly flawed products. When we failed we totally deserved it.

I mentioned in the introduction that we intend to pass the three startup hurdles of launching, marketing, and sales. For each of these hurdles we’ve collected clear indicators that our general approach should work. We’re intentionally a “single miracle startup“. We’re taking an educated gamble with our product, but our marketing and sales will be conventional and straightforward. Our plan may fail, but we have a real plan.

Start small

Wim • @wcools • • Part of Day 51

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.

Even companies with larger goals have a “secret master plan”, i.e. get to a smaller goal first

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.