Day 4

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
We're building a startup in 80 days in public. Day 4 was on Jan 13 '22. You can find today's entry at Day 67.

Today's posts:

The initial stages of a SaaS product

These are the phases you’ll typically go through when you start a SaaS product:

  • Idea phase. Here you try to figure out if there is a hypothetical market for your idea. What kind price you can charge and how you will reach your audience. If possible, explore multiple ideas and let them marinate. Don’t rush this stage. At this point anything is still in play. But the decisions you make here will affect what kind of customers you’ll have, what kind of technical challenges you’ll work on, whether you’ll make money, and everything else. Any business has fun and not-so-fun parts, so choose wisely! Owning a business that operates smoothly and profitably is a lot of fun, and you’re unlikely to get bored. By contrast, working on a product you’re passionate about that has no functional business model is painful and you’ll start to doubt yourself sooner or later.

    If you’re a techy (like me) you want to choose a startup idea that has a relatively straightforward customer base and business model. That way you can succeed if you have an excellent product but mediocre marketing.
  • Prototype phase. Good taste and good design sense matters. If your product looks good users will assume it’s is a good product, and you’ll get the benefit of the doubt when something doesn’t work right. If your product looks sloppy you’re going to lose people who would otherwise be interested. Prototypes are by their very nature flawed, but you don’t want to make an app only a founder could love.

    You might think you can save time by using cookie-cutter CSS templates/frameworks, but these frameworks make your product look bland. Your product should be visually distinctive. People are far more willing to try products that look different, and this also makes you more memorable. The world is a diverse place and people have different tastes. By being different you’re going to alienate some people and attract others. That doesn’t sound great, but the alternative is being bland, and then you won’t have any enthusiastic users. Big businesses can afford to be bland, startups cannot.

    The press also likes to cover things that look new. It’s tech fashion, basically. Design styles go in cycles. Do products use a lot of whitespace, or very little? Skeuomorphic design or Swedish minimalism? Muted pastels or saturated colors? When a startup becomes super popular you’ll see many other startups copy their visual style. It’s pretty funny when you notice it happening. Of course, there are no right and wrong answers in fashion. And what looks fresh in one year can look tired two years later. A sloppy and amateurish look will do you no favors.

    Your product should have very clearly defined core functionality. Businesses with money to burn can afford to have their product be a confusing mess. You can’t. Your users will simply move on if they don’t “get it”. And you can’t blame them. In this prototype phase it’s your job to figure out if your innovations actually make sense. And because you’re going to rewrite these prototypes anyway you can cut corners if you have to. In addition, you can experiment with the software architecture of your program. Changing your mind in this stage is cheap, but refactoring a live service with millions of users is painful. The prep you do here will pay off handsomely.

    In this stage you figure out the identity of your product. How you interact with it. What it feels like. What it does.
  • MVP phase. Here you build the real thing. It has to be good enough so people can actually use and derive value from your product. The goal isn’t perfection in this stage, but you don’t want launch anything half-assed. As Wim wrote earlier today, you want the core functionality, and nothing else.

    Everything that can reasonably be postponed to after the launch you postpone, even those features that you know people will be asking for from day one. The goal of the MVP is to get good user feedback. The most important thing is whether you believe the product is any good, but if you’re the only person on the planet who believes it is then you’re in trouble.

    What you really look for in this stage are people who think your MVP is great. It doesn’t matter how many people hate it, or don’t get it, or are indifferent. None of those people will become customers anyway. You only need a handful of passionate users at this stage. Talk to them and judge if you can actually turn your MVP into a business. If you can’t find any passionate users, then maybe your idea wasn’t so great after all. Or maybe your execution sucked. This is really the critical junction. At this point you can still walk away without having invested too much. Delete everything and go build something else. If you go ahead with the commercial launch before you have clear evidence that people need what you’ve made you risk running a zombie startup: one that’s neither dead or alive. This sucks because you might thread water for years. Barely surviving, but not going anywhere. Don’t let this happen to you. But if you proceed and turn this into a real business, then you also have to accept all the responsibilities that come with it. Onwards!
  • Commercial launch. Whoo-hoo! Your first paying customers. Hopefully, you didn’t have any trouble converting your beta users to customers. Now you have to fix in a hurry all the shortcuts you took while building the MVP. And you have to figure out billing, invoicing, refunds, customer support, backups, failover, GDPR compliance and everything else. This stage is schleppy but the excitement of growing your tiny business will help you power through it.
  • Scale. Don’t get distracted. Focus on your product and the customer. Setting the right priorities is everything. Learn to say “no” a lot.

Features: from core to bullshit

When looking at what features to build, we divide them into roughly 5 categories: core features, long tail features, BS features, checkbox features and anti-features.

Core features

These features form the heart and soul of the product. They make it clear what our vision is. All users of the product will use these all the time. Even if they’re not used by everyone, then all true fans will use them all the time (in the case of power features). If the product doesn’t have these features, it won’t shine, it won’t convey its value proposition clearly. If people aren’t convinced by the product with these features, then the vision behind our offering isn’t compelling enough and we should rethink the idea before building on.

Long tail features

Nobody will buy your product because it has these, but people might eventually leave because it doesn’t.

It does nothing to help you stand out, but people who need (or often, think they do) these features might leave or switch as competitors catch up with your main vision.

There is a very long tail list of these features, and it’s something you can add over time to improve both retention and conversions. They won’t completely make or break the product, and won’t be useful for validating your idea, so there is no need to rush these.

For example, think of how the original iPhone was revolutionary yet didn’t have copy&paste; that simply wasn’t part of what made it so special.

BS Features

As it says on the tin, these features are complete bullshit, laughable even. The product could technically do without these, but adding them helps the business in a different way, by giving it a twist or viral component which helps getting the word out.

Just like anything you write, it’s important to think of who the audience is. And the real audience of a BS feature isn’t the user; it’s an editor at CNN or a friend of the user who will tweet about it.

Spending a day on a BS feature which uses {machine learning, blockchain, chatbots, hype du jour} for no other reason so the press/investors will cover your product has a clear benefit. The product with or without the feature would otherwise be exactly as functional, but instead of being unnoticed, this version of your app does get covered or is fun enough to tell your friends about it.

The number of sales generated for Tesla because of its whoopee cushion “feature” making fart noises is >> 0.

Even better when there’s a viral component to it. We once added a “feature” to a CRUD app where you could add items by tweeting them to us, which other people then noticed. Delightfully silly and completely useless. So obviously people used it and the press wrote about it ;).

Checkbox Features

This one sits somehwere in-between “Long tail” and “BS”. The audience isn’t exactly the end-user, but you do need it to close more sales and expand your audience. It’s a category of features that is relevant for products which have decision makers who aren’t necessarily the user.

This happens often in B2B, and especially B2E (Enterprise) settings. Here, different people typically need to sign off on the approval of a product, all of them with their own ideas of what is important. The more layers are involved, the longer the Excel with “requirements” will become.

Especially if the layers involved won’t actually use the product, the feature requirements might feel strange because you know they won’t actually be used that way. They can be a hard requirement however because of the purchasing process, so your product will simply not be considered unless you can check all the boxes.

If it’s relevant for the market you are pursuing, you can decide to build these in, but in an incredibly minimalistic fashion. That way you can check the box, but nobody is going to care about it anyway. You can even make it a completely manual process. If an “Audit Log Report” is required every quarter to win a $$$ sale, you can manually query it from the DB and send it in a PDF. Boom, feature checked.

Anti-Features

Other than the four categories above, these we need to avoid at all cost! In other words, we need to keep a not-to-do list and avoid falling in the trap of building anti-features.

An anti-feature is something we add to our product which would take it in the wrong direction. Not only does this take precious time away from building stuff that matters, but it can trade good customers and leads for an audience which is not relevant to the product.

It harms both the product and the marketing. It dilutes the vision of the product and makes it look like something it’s not. It also makes the product harder to use for your real audience.

Most often, the anti-features end up being built because a really persistent customer really “needs” it. Most likely they’re not even a customer yet, and just as likely they only think they need it.

Especially when starting out, with very little to no revenue, it can be hard to say no and tempting to build it in. Resist this, because it might turn you on a path of becoming a de-facto freelancer for individual clients and endanger your entire product.

Of course you won’t always know when something is an anti-feature. It’s tricky because some of them are easy to mistake for ‘Long tail’ features (but hardly ever for core features!). A good rule of thumb is that if you have doubts, they’re probably justified. If you keep hearing the same feature requests or complaints about the product over and over again, then you’ll learn automatically that it’s valuable enough to move to the nice-to-have Long tail list.



← Previous day (day 3)Next day (day 5) →


You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Dogfooding
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Desktop-first
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive