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.

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