...
Make planning easier
I want to have a clear process I can follow when planning out a SaaS app so that I’m never losing time feeling unsure about what I should be doing next while planning.
Identify risks sooner
I want to be able to flesh out my SaaS ideas as much as possible before I start coding so that I can uncover especially-difficult aspects of the idea as soon as possible.
Examples:
legal issues - “It isn’t legal to do that.”
limits of current technology - “AI can’t do that yet.” / “There’s no library to do that.”
Communicate my vision better
I want to be able to share a detailed description of an app idea with other people to better communicate my vision.
Avoid feature creep
Example: “I just got a great feature idea, but it’s a feature that wasn’t planned for the MVP. I should finish the MVP first and then work on this new feature idea.”
Gauge the total cost better
I want to estimate how long different features will take and then compare my actual rate of progress against those estimates to quickly get a sense of what the total cost (in terms of my time) of the project is going to be.
Why: this will make it easier to abandon projects that are going to be more ‘expensive’ than they’re worth.
Example: “From my rate of progress so far, it seems this app is going to take 1,000 hours to complete, but I estimated that it’s only likely to ever generate around $10,000.”
Work more efficiently
I think if I have a clear goal of “try to get this feature done in 12 hours” it will help me to work more efficiently than if I only have a fuzzier goal of “try to get this app done in 360 hours”.
Summary / Guiding
...
ideas
start by writing out a simple description of the idea, and then create a separate fleshed-out version of that description.
start by writing out a simple description of a single user and use-case, and then add additional user types and use cases.
start by writing out text descriptions, then use those to create wireframes.
maintain separate descriptions of the vision for the full-featured version of the app and the (possibly-multiple) minimal version(s) that could be used as a starting point (MVP) towards that ultimate vision.
...
Start with just considering just a single case of a user-type (or multiple users user-types if the app is connecting different types of people) and a problem they hadhave (aka a use-case).
Yes, the full-featured version of your app may handle many different kinds types of users and many different kinds types of use-cases, but when getting started it’s better to keep things simple.
If you got this idea from a problem in your own life, you can use yourself as the initial user.
Write out a simple description of the problem that user had-type has.
“I want X but can’t because Y.”
Question: There are two elements here: first, what the person wants, and second, the thing keeping them from getting what they want. I feel like it’s important to keep both of these clearly in-mind but it’s not clear to me yet why.
Answer: I think it’s important because your solution has to both allow the user to bypass the problem (“Y”) and also do so in a way that allows the user to get what they want (“X”). If you lose sight of what the user wants, you can end up in situations where the “solution” isn’t really a solution.
Examples:
Rhymecraft:
Writers: “I want to write rap songs to the same level of quality as Biggie / Tupac / Eminem, but can’t because I don’t know how to write rap songs.”
Uber:
Riders: “I need a ride, but I can’t find one because there’re no taxis driving past me and no easy way for me to communicate with the taxi drivers.”
Drivers: “I have a car and want to use it to make money by helping people get around, but I don’t see any customers around me and I don’t have a way to communicate with customers who aren’t around me.”
Facebook:
Students: “I want to know about the other university students in my class and find out whether I have any shared friends with this person I like, but can’t because that information isn’t stored anywhere.”
Upwork:
Clients: “I want to find someone to work on this short project but it’s a huge amount of work sorting through resumes I get from Craigslist and then interviewing people to try to figure out who is going to do a good job.”
Freelancers: “I want to find work but it’s really hard to build a good reputation when I am hopping from gig to gig, and the application/interviewing process is so much work it’s not really worth the trouble.”
Optional: Write out a simple description of any existing solutions and why they’re not ideal.
Explanation:
This provides useful context for people who aren’t already familiar with this space.
Examples:
Rhymecraft:
I could pay a rapper/writer to help me, but 1) it would be more expensive in terms of my time and money than using an app, and 2) they probably wouldn’t do a great job.
Facebook:
(Nathan’s understanding of the state of things at the time:) Some of the houses have online facebooks, some have physical facebooks, but there’s no centralized online system. And some/all of the existing online facebooks are limited to students in those houses.
Write out a simple description of the user’s journey with your app that would allow them to solve their problem.
Examples:
Facebook:
Student: “I create an account at thefacebook.com and share information about myself: my photo, who my friends are, what classes I’m in. I can then find information about my classmates that they’ve shared.”
Start to build out a fleshed-out text version of that simple user story.
The idea here is to try to specify exactly how it would work, what information would need to be gathered, etc. while maintaining the simple description as a north star.
Use that fleshed-out text description to create a list of necessary views/pages.
Create a new Balsamiq project and within it create a mock-up that contains simple box-only representations of the different views in your app that would be necessary to implement that user journey.
Now that you have one user journey complete, think about whether the users might ever want to do anything other than what you’ve just mocked up. Follow the same steps as above for those other user-actions / use-cases.
Maintain a separate bare-bones Balsamiq project that includes the views from all the different user journeys but this time have the links able to be clicked on to bring up different views.
Once you’ve done this for your minimal version of the app:
follow the same process to consider additional user-types and use-cases as a way of fleshing out the full-featured version of your app and/or planning out a subsequent-release.
start from scratch on a new, different app-plan if you want to plan out a different starting point/MVP: a limited-feature app that would have the same full-featured version as its ultimate aim.
Examples:
Facebook: I can imagine Facebook having started not with its ‘Friends’ use-case but instead with its ‘Facebook Groups’ or ‘Facebook Marketplace’ use-cases, and then expanding later into letting users add friends.
Uber: I can imagine Uber having started with its ‘Uber Eats’ use-case instead of its ride-sharing use-case.
...
Example plans
MVP
Step 1 - The initial user-type(s) and their problem(s)
Mark Zuckerberg is a college student at Harvard. He wants:
College students at Harvard want to learn about the other university students in his classat their school, but he they can’t because that kind of information isn’t available in a central location.
A simple description of existing solutions and why they’re not ideal:
Some of the houses at Harvard have online facebooks, some have physical facebooks, but there’s no centralized online system. And some/all of the existing online facebooks are limited to students in those houses. The university is working on their own centralized online facebook but it won’t be done for months or maybe years.
A simple description of the initial user journey / use-case:
I register with the web app and share info about myself. I can then browse other students and see the info they’ve shared.
A fleshed-out version of the initial user journey / use-case:
I register with the web app and share information about myself: basic info (age/sex/location), my photo, my contact information (phone/email), my interests, relationship status, what classes I’m in. I can then browse other students at my school to see the info they’ve shared. People can choose to share their more-personal information only with ‘friends’, in which case you need to click ‘Add friend’ and have them accept it before you can see more information about them. And if you do that you can also see if you have any friends in common with someone.
A list of necessary views/pages to implement this initial use-case:
Login / register page
“Edit your info” page
“Browse other students” page
Profile page
Privacy settings page
Pending friend requests page
Simple box-only wireframe:
Full-featured app
Puzzle pieces I still need to fit somewhere
...