If you’re investing in a company like this, you NEED to understand what is happening and how it is happening.
When investing in a SaaS system, you don’t need to look at things from a code level, but you need to have the ability to tell if the people working on the project have a good plan, are managing things correctly, and are actually working. Familiarity with these tools will enable you to have that insight.
1. Project Management
When you’re building a SaaS system, you absolutely must have solidified project management processes and systems or deadlines fall away and bugs will slip by. I recommend learning about waterfall and agile methodologies and knowing how your developers are working. For all of our SaaS systems, during our heavy development times, we do a daily scrum meeting with all developers, project managers, and sometimes stakeholders. This keeps everyone on track with where we are on the project.
Understanding the process of iteration is very important as well. No software system out there is amazing on day one. Developers iterate through the system; meaning they build, then rebuild, then rebuild. Each time, they gather user feedback, make a list of new features, decide on which bugs to work on, and then create a new short term development roadmap.
Below is a screenshot of our PM Kanban Board for BrainLeaf:
2. Development roadmap
You need to know what your estimated deadlines for upcoming features and deployments are going to be. This can be as simple as a shared document that has a list of dates and deployments. The important thing here is that the developers know what is coming up next as they develop features.
For example, if you are building a tool that allows you to charge payments and your developers are building some of the linking properties of the system, they’ll need to keep in mind the security for processing payments in that development. If they didn’t plan on the payments system, they may have to go back and redo work. That being said, this will inevitably happen over the course of the product lifetime, no matter how much time you spend planning. Making sure everyone understands what’ coming up next will help keep your team on track.
3. Systems documentation
Software is complicated, and sometimes complex. It is really, really, really important to document as much as possible throughout the process. Part of this is keeping a management board like the one above, but there are constantly requirements that need to be reviewed and planned as well. Having a centralized system for managing documents is critical. This can be as simple as a shared Google Docs folder or more complex like a wiki based system. We use a wiki style system from the same company that does our PM management systems.
4. Code Repositories
A code repo is the key to decentralized coding practices. If you ask your guys how they are managing their code and they don’t talk about a code repo, there is something seriously wrong. Your team needs to have a centralized code repository for things like merging and branching their code. This should ideally be done via a 3rd party system such as Github or Bitbucket (I like bitbucket as it is a lot cheaper and works with our other tools very well).
If you don’t have a repo, you can’t easily bring on new developers, and you are at a high risk for people overwriting code, mismanaging code, and just generally screwing things up. Additionally, you can see what your people are doing using a code repo. If you’re wondering if people are working, you can check their commits there.
5. Gathering bugs and getting user feedback
There are two different ways of getting user feedback, passive and active. An example of passive is having a button on the side of the website that says “what did you think?” where users can give feedback. Depending on the product, this can be more or less effective. Whereas an example of active would be getting a list of people that used the system to make a purchase then calling them to ask what they thought about it.
Both of these are REALLY important. Personally, I like to make automated systems that do this for me. Whenever someone uses the system, I get their email and send them a series of follow-up emails that ask them to give feedback. My first email sends them to Calendly and asks them to make an appointment with me to talk about their experience. Then, there is a drip campaign that pushes them to reuse the system and give feedback on it. AT time, we may also have a modal box show up asking for a review on the product. I can go through all of my systems in a later conversation, but this is a good start.
There is also a system that I like to use called Lucky Orange. This system enables me to see their exact movements on the page. There are more expensive and better systems out there that do this, but this is only $10 per month and works well enough for me.
6. Have a beta deployment plan that works
As I’m sure you know, the issue in growth is usually sales. If there are major bugs, the project can be killed before it even gets off the ground.
I ran into an issue like this with one of my companies where the idea was great and we had a ton of interest, but the system just wasn’t ready. We were in beta, the system was completely free and a lot of people tested it out. But, because it didn’t work well enough, many of my potential early adopters and left them with a bad taste in their mouth for the system. It then took a lot of work to get them to give us another shot once the system was in a better shape. The lesson here is that in some cases you need to do a private beta, not an open beta, depending on the project type.
