How to define your Saas Project? Smart tools and approaches.

The previous episode revealed that the budget forecast numbers add up, and the market for software cost estimation tools is promising. What are the next steps, when you're bootstrapping software-as-a-service? The next step would be to define your product.

When I'm helping other people to create a product for them, they usually come to me with a very brief description of their core value proposition of their product. They are focusing more on additional features like user registration or email messaging.

The reason for this, in my opinion, is that it's straightforward to describe something that you know, because user registrations forms are all over the place, and everybody is familiar with that. But when you're defining a new set of features, it isn't easy to imagine how that would work. It requires creativity, and it’s more challenging as it might be at first glance.

Three simple frameworks to describe the project

The first step to define your product would be to create a description of the product you want to create. There are a couple of ways you can take to describe your product. For example, you can create mockups, wireframes, make a visual representation of your product, how it will work.

The second would be to create user stories, which usually describe the outcome of user actions.

The third thing would be to describe the list of features, what users see or what the user can do on a particular screen of the user interface.

Regardless of the path, you'll take, you have to do this in detail. I mean like literally very detailed description of the user interface or description of user stories or set of features. The more information you will add, the better for your developers to understand what you want to create. Focus mainly on Key Value Proposition. Don't focus on additional features or don't go beyond your Key Value Proposition.

What to focus on?

The other thing is that you have to remember that what adds complexity to a product is a Business Logic. The Business Logic, from my experience, requires 1/3 of the MVP budget. It's very complicated, but at this level when you are creating proof-of-concept of your product you don't have to think, and you don't have to worry about Business Logic. You can add the slide later on, but be aware that it will take one of a third of the time to create a proper Business Logic because it's not that easy. It is something more than collecting the subscription payment. The Business Logic describes everything from onboarding the user paying the subscription, but also it covers the cases like if the user cancels the subscription or the user applies the coupon or a discount.

Why Project Documentation is so important?

You may ask what is the purpose to spend that much effort on describing something that will eventually change. Bootstrapping the change is written in that mode. The reason is simply this: your Key Value Proposition won't change that much over time You can make a pivot, but the Key Value Proposition probably won't change that much so your description, your documentation won't apply anymore.

The second reason is that your developers must precisely know what they are creating so they can make a solid foundation. Then they can build on the top of it.

The other reason: the better describe your product, the more accurate quote from your development team you will receive. It will help them to determine how much time and how much money you'll need to spend on creating something like that.

And the final reason would be that it's easier to make changes on paper. If you create a project description, and you consult this with various people like project managers, developers, your potential customers. They will say that "okay, that's not something that will work, or this has to be made differently". It's effortless to copy-paste, delete or add some extra features on the paper rather than asking developers to add functionality and completely change the planned structure.

My approach

So defining the product on paper is very important even though you know that it will change in the future. How I'm going to approach this in my software cost estimation tool? I'm usually starting with Functional Requirements Documentation because it's a smart way to describe a product.

How would I do it? First, I'll define the features like creating a new estimation approving estimation and stuff like that. Plus I will add a description of Non-Functional Requirement. Non-Functional Requirements are everything that happens in the background, like sending a reminder about unapproved estimation, or things like that.

Also, I will describe a transition when it comes to estimation because the estimation here is the core of the product. There will be a lot of things that can "happen" to quote estimation. Probably I'll create a diagram that describes what happens with the project estimation when the user or the client approves it or when a client rejects an estimation.

With this Functional Requirements Documentation, I'll be in a position to quickly create wireframes, an initial version of the UX mockup which then I'll pass to UX designer so he can improve this user experience.

Abstract from technology stack (if possible)

The thing which I am not going to do is to focus on technology stack or anything related to technologies that will be used to create that product. It is in favour of the development team that will implement this product. When you create product documentation, don't think about what technology will be used, unless you do a technology-specific product. In my case, and I believe in most software-as-a-services, technology is an abstract layer of your product definition.

Defining a product specification is not easy as it involves a lot of thinking, analysing, specific industry knowledge or even sometimes technological knowledge. Still, you have to remember that in the long run, it will help you to keep your development on track.

I've created a template that will help you create Functional Requirements Documentation. If you need help with defining your product, you can always ping me, and I'll try to help you with defining your product.