Six steps to help you start your SaaS business.
After co-founding, selling, and subsequently departing from my first startup, I realized that, for my next move, I wanted to do it all over again– with the benefit of hindsight. So began the journey towards assembling a great team to build another innovative SaaS product.
The second time around, I wanted to follow a more systematic process to decide what product to build. Below is a high-level overview of that process, in the hope that it might help other budding entrepreneurs.
TL;DR: find a common business process that, re-imagined with modern tech, benefits a decision maker with a budget.
You'll have to either mine your own experience or seek input from others to identify a list of candidate business processes. If you're having trouble finding interesting business processes: leverage your network, and if that fails: try cold-outreach.
In the subsequent steps, dispense with the less promising concepts. You can't explore every idea in full depth, so you'll need to use your best judgment to identify where the opportunities lie.
Document all you can about how each candidate process works. You need to establish the process requirements, and how they tend to vary between companies. It's also critical to understand the stakeholders, and the value they get from the process.
There is little point investing time in a business process if nobody with a budget cares about it. Benefiting the company as a whole is not enough. You need to have a rough idea of which "role" in the company would buy your product, and why.
If an individual with a budget doesn't care then effectively the company doesn't care either.
For instance, if you're simplifying financial forecasting / reporting in SMBs, then you probably want to target the CFO. If you're optimizing recruitment at large enterprises, then you want to target the head of recruitment (or whoever above them has a budget, perhaps the VP of HR).
Sometimes it's tricky to figure out who "cares" about a problem, what their typical "title" is, and whether they have a budget or can influence someone with a budget. Answering these questions can take time, but it's a critical exercise.
Another issue is that sometimes a problem is too diffuse. You might be tempted to say "this problem hurts everyone a little, so the CEO is the target". But the CEO has a short list of things they care about, and you need to ask yourself whether this problem is in their top 10 (or, ideally top 3) list of problems. If it's not, then you're going to have a tough time selling to the CEO.
My preferred way of doing this:
These specs should mostly consist of mock-ups, showing the main workflows in your software:
The goal at this stage is to document functionality, not to finalize the UX.
Collect as much critical feedback from relevant stakeholders as possible, updating the spec as required.
Figma is an awesome tool for prototyping software. Implement your spec as a sequence of workflows in a Figma prototype.
You're now ready to UX test, pre-sell, and potentially fundraise based upon your prototype!
There is no "silver bullet" that guarantees startup success. Agility and good judgment are more important than unthinking adherence to this, or any other, process. So don't forget to assess the degree to which your circumstances differ from my own, and consequently whether to heed or ignore the particulars of my advice.
And most importantly of all: good luck in all your efforts!
You may have noticed some tell-tale signs of low morale. Here are 35 ways of improving employee morale in the workplace that will give your teams a boost.
All Hands meetings are vital to maintaining company culture and collaboration. If your company doesn’t do this, they are missing out.