Nathan Wailes - Blog - GitHub - LinkedIn - Patreon - Reddit - Stack Overflow - Twitter - YouTube

How to plan out an app

Owned by Nathan Wailes
Last updated: May 29, 2023
7 min read

The goal

  • 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

    1. 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 1) the full-featured version of the app, 2) the (possibly-multiple) minimal version(s) that could be used as a starting point (MVP) towards that ultimate vision, and 3) intermediate versions between the MVPs and the full-featured version.

The process

  1. Start with just considering just a single user-type (or multiple user-types if the app is connecting different types of people) and a problem they have (aka a use-case).

    1. Yes, the full-featured version of your app may handle many different types of users and many different types of use-cases, but when getting started it’s better to keep things simple.

    2. If you got this idea from a problem in your own life, you can use yourself as the initial user.

  2. Write out a simple description of the problem that user-type has.

    1. “I want X but can’t because Y.”

      1. 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.

        1. 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.

      2. Examples:

        1. Rhymecraft:

          1. 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.”

        2. Uber:

          1. 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.”

          2. 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.”

        3. Facebook:

          1. 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.”

        4. Upwork:

          1. 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.”

          2. 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.”

  3. Optional: Write out a simple description of any existing solutions and why they’re not ideal.

    1. Explanation:

      1. This provides useful context for people who aren’t already familiar with this space.

    2. Examples:

      1. Rhymecraft:

        1. 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.

  4. Write out a simple description of the user’s journey with your app that would allow them to solve their problem.

  5. Start to build out a fleshed-out text version of that simple user story.

    1. 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.

  6. Use that fleshed-out text description to create a list of necessary views/pages.

  7. 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.

  8. 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.

  9. 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.

  10. Once you’ve done this for your minimal version of the app:

    1. 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.

    2. 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.

      1. Examples:

        1. 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.

        2. Uber: I can imagine Uber having started with its ‘Uber Eats’ use-case instead of its ride-sharing use-case.

Example plans

Facebook

MVP

  1. The initial user-type(s) and their problem(s):

    1. College students at Harvard want to learn about the other university students at their school, but they can’t because that kind of information isn’t available in a central location.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  6. Simple box-only wireframe:

Full-featured app

  •  

Puzzle pieces I still need to fit somewhere

  • Part of the plan should be an accounting of the biggest risks so that they can be measured and mitigated early if possible.

Related information

Books

  • Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

    • The process described in this book isn’t quite the same thing as developing a detailed app plan. It’s more a way to quickly decide between alternative plans or test a risky plan with real users.

    • “This book is a DIY guide for running your own sprint to answer your pressing business questions. On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a realistic prototype. And on Friday, you’ll test it with real live humans.”

  • The User's Journey: Storymapping Products That People Love

    • “While many people often use the shorthand storymapping when referring to Agile user story mapping, they are quite different. Storymapping is as simple as it sounds: literally mapping out an intended experience of use just as you would a story--plot point by plot point. Agile user story mapping is a method that Agile developers use to organize and chart the course for large bodies of work comprised of smaller ‘user stories’. Although the two approaches look similar (Post-its on a wall or cards on a table), they are quite different. Storymapping is a way to engineer increased engagement in your products. Agile user story mapping is a way for engineers to work.”

  • User Story Mapping: Discover the Whole Story, Build the Right Product

Links

 

 

 

 

Follow me on Twitter