Making a Side Project, Part 3: Minimum Usable Product
People often ask me how I’m able to make and launch so many side projects, and this step in the process is usually why. Having the ability to define what we need to build and stick to it, is key.
You don’t have a lot of time to work on your side project, if you did it wouldn’t be a side project. Getting the features down to something that can be built in a short time frame, is key. Key to making progress, key to launching, key to getting feedback from user.
Since I’m making this project during the Product Hunt Global Hackathon, my time is externally constrained. I have to launch by the end of November. I typically limit myself to 2 weeks, so this is actually longer than I normally get, but I am doing this documenting of the process as I go, and I have to say this is taking more time than I thought it would!
What is a Minimum Usable Product
A Minimum Usable Product (MUP) is the minimum features that we need to build so that a user can use the product for the purpose it was intended. No nice to have features, just the minimum required. Minimum Viable Product (MVP) is another popular term for this, but I don’t think that accurately describes what we’re trying to do.
For each release of the product, the user is able to use it to achieve the goals of the project.
I’ve often left out things like the “Forgot Password” feature until after launch. The chance that a user will forget their password the day they create the account, well it happens, but not very likely. Typically that is the only feature in the MUP that needs to be able to send emails, so not only do you save time by not having to build the feature, but you also save time by not having to signup for and setup an email delivery service.
Features like this usually get added pretty quickly after launch, don’t let that stop you launching though.
On one project, I waited until someone emailed that they forgot their password, then I sat down, built and deployed the feature and emailed the user back with a link an hour later.
It takes a lot of discipline to define the MUP and then stick to it, you’ll get sucked into the “oh I really need this one more feature” before I launch. You don’t, trust your gut when you started the process.
Minimum Usable Product for Track Startup Expenses?
I’m not building a fully fledged accounting system. Let me say that again, I’m not building a fully fledged accounting system. We don’t have time for that, and I believe people getting going with a project don’t want to use something like that.
User stories come in really handy here.
“A user story is an informal, natural language description of one or more features of a software system.”
User stories became popular with the rise of Agile Development. You don’t have to get very technical or fill in the details right now, just simply and quickly document what the visitors and users will do when they use the website.
- As a visitor I want to see a marketing page so that I know what the website does
- As a user or visitor I want to see the Terms and Conditions of the website
- As a visitor I want to signup so that I can track my expenses
- As a visitor I want to login so that I can access my account
- As a user I want to create a project so that I can track its expenses
- As a user I want see my expenses for a project so that I know how much I’m spending on it
- As a user I want to add a new one time expense in a project
- As a user I want to add a new recurring expense in a project
- As a user I want to add a variable amount to a recurring expense in a project
- As a user I want to end a recurring expense in a project
- As a user I want to delete an expense in a project
At it’s core, that is the MUP.
We are missing some things that might come pretty quickly after.
- As a user I want see my expenses for all projects so that I know how much I’m spending in total
- As a user I want to reset my password
- As a user I want to change my password
- As a visitor I want to read more About the website
I do like to think about other features now, as it might affect how I build things. Writing code a certain way now might make future features more difficult or easy, considering them now is worth a few extra minutes.
We don’t always work alone on projects, so a natural enhancement to think about, is is allow multiple people to track the expenses for a project. People may have different permissions, perhaps some people just see the expenses while others an add them too.
- As a user that created a project I want to invite other users to collaborate on a project
- As a user that was invited to collaborate on a project I want to accept or reject the invite
- As a user that collaborates on a project I want to be able to leave the project
- As a user that collaborates on a project I wanted to be notified when an expense is added.
These features might be part of a premium tier, so we might need to think about integrating with a payment provider like Stripe, but since I don’t know that yet, I’m not including that in the stories.
How about publicly sharing project’s expenses? We live in a public open world, were people like to be transparent. Many companies expose their income on services like Baremetrics, others openly publish how much they pay their employees, why not their expenses too.
- As a user who created a project I want to be able to make it visible to the world
- As a visitor I want to see a list of public projects
- As a visitor I want to see the expenses of a public project
Further down the road we may want to think about automatically pulling expenses from the credit/debit card account. I’d like to get there, but it’s so down the list of things to do, I’m not even going write stories for it.
I think that about covers the MUP and we even created a little roadmap for future updates.