The Golden Rules

It's all about the users - does your product solve an unmet need? If not, no one will care. "But we have better UX" is not going to persuade anyone to move platforms. People only care about a B2B SaaS if it clearly makes their life easier or richer. Focus on one core feature, in a really narrow niche, find users willing to use the SaaS and give their honest insights, and keep working until the point they'll be upset if the SaaS was taken away.

So what? Understand your competitors and be able to give a valid reason why someone should use your app, rather than each of the competitor’s products. Examples of unconvincing reasons are “It’s just better to use”, “we have better navigation“ and “it’s faster”. If you are very lucky, you will be able to say “because no one else does anything remotely like this!”.

Get the early adopters and listen to them. Don’t worry about getting paid, you need people who will use your product every day to do their work, and give meaningful feedback. The blunter, the better. What you lose in subscription, you save in hiring a product owner.

Rapid prototype - use a low-code platform like Retool to mock up your app, rather going all in with building a custom React UI. Sure, it'll look a bit rubbish, but you can prototype a feature in a fraction of the time that people actually want to use and it solves their problems? If you can tell ecommerce stores what products or keywords are losing traffic, this information is so valuable to them, they simply care if it's formatted with Comic Sans.

Prioritise - are you always working on the next feature that will deliver value to the users? Or are you spending hours making the fonts and colours consistent, while your data is wrong or the core functionality is missing. Deckchairs + Titanic come to mind. Early stage SaaSes thrive when they solve a clear niche problem. When this is so obvious from the interface, they become so easy to sell. Aligning the overall product goals and vision with daily tasks that build towards that are essential. A healthy startup needs a single decision maker, who carefully decides the overall roadmap and can align this with the prioritised daily engineering tasks. Bad looks like an emphasis on graphic design, frequent changes in priority, co founders contradicting priorities, founders expecting to see complete features when the task was for the DB work, lots of incomplete work being shelved and tension. Good looks regularly long term planning sessions, regular short term prioritisation planning sessions, sprints that rarely change scope, low WIP churn. I can't emphasis enough how important this is.

Basic meetings - turn up on time, deal with the essential matter in hand, finish on time (or early). Respect the time of your team, and don't waste it waffling shit. If a 30 minute meeting is regularly taking 2 hours, you're in serious trouble.

Backlog = what to work on next. When an engineer completes a piece of work, they should be able to go to the backlog and pick the next piece from the top. If this concept is hard to implement, you likely have the wrong person making the decisions on priorities. Sorry.

Descope aggressively - a big mistake of first time founders is promising to solve all the problems for everyone in your space. The more that is taken out will make the remaining work stronger.

We just need to focus on building this feature... - this is that feeling that you're not really focused on the most important work. Without a clear product vision that will create a compelling product demo that people makes people throw cash at you.

Everyone has an opinion, and most of them are uninformed - we seem to have reached a point were people have become oblivious of their shortcomings, and it's created an environment where even the most unqualified people will push their opinion without a single second of actual experience to back it up. Just look at LinkedIn. If you listen to advice, make sure that advice is from someone who's actually done the thing they're talking about. If it's an engineer saying that a degree is not necessary for engineering, I'm going to assume that they don't have a degree in engineering and aren't aware of their incompetence. This is something that doesn't get talked about much publically, but it's one of the most important skills to gain.