To do this effectively, we need two things. One, we need a way to represent the feature list, so that it can be iterated on. Two, we need a way to interrogate this feature list effectively.

Let’s talk about how to do this.

Mapping out the features

We want to stop thinking of this in business terms and start thinking of this like a user. That is the level at which we will have to deal with the complexity of the software.

First, make a list of user objectives. What does the user want to achieve using your app?

Next, you need to map out the user flow. Walk through every step that a user takes to achieve each of your objectives. Record those steps.

What we are building is a map of how users flow through the app.

There are many ways to do this. You could just make a simple outline of each step taken. You could draw up mockups of each screen the user goes through. You could draw a flowchart, either on paper or using software.

An example of the kind of simple mockup you can make - Credit

Whichever you pick, make sure to prioritize speed. Unless you’re an expert at Photoshop, put it away and pick up pen and paper.

Make sure every screen is represented in your outline. For example, if a particular step goes through multiple screens in the app, split it up. We want to tease out more details, not less.

This process alone should start surfacing some of the complexity of your app. Now, we drill deeper.

Question everything

Asking questions like we did above can be quite open-ended, like we did above. It can be hard to know where to begin.

To start you off, I’ve put together a list of common questions that apply to most software. These questions are arranged into four broad categories that you can use as a framework when attacking your outline.

Look at each step of your outline, and ask yourself every question on this list. If the answers reveal new steps, add them to your outline.

Here’s the list:

User inputs

These questions are about information that goes from the user to the product.

What information does the user input?

Is this input open ended or interactive?

Open ended examples: free-form text input, choosing an image to upload, recording a video.

Interactive examples: text input into a search form that displays results to pick from, choosing an address on a map, picking from a predefined collection of options.

Is there any input that would be considered invalid, and how does the app deal with it?

Are there any passive inputs? Most common example: user location via GPS.

What information does the product need from a new user? Is there a way for the user to change this later?

Information presented to the user

If the previous section was inputs, you can think of this one as outputs.

What information is shown to the user on this screen?

How is this information shown? Examples: text, images, maps, lists, graphs.

Does the information need to be sorted in some way? Examples: recency, distance from user, relevance.

Does the product send any active outward communications? Examples: emails, push notifications, SMS messages.

Interactions between the pieces

These questions are about how different pieces of the experience (users, the product, other services) interact with one another.

Do users interact with each other? Examples: messaging, adding as friend, “liking” or tagging of other users’ content.

Do the users interact with external services? Examples: payment services, shipping tracking, social login.

Does the product interact with external services? Examples: location lookup services, weather APIs, social networks (“Your friend X just joined! Check out their profile!”).

Business owner functionality

Questions about what you, the business owner, need from the product.

Do you need to be sent alerts or summaries, via email or some other medium?

Do you need a specialized system for yourself or employees? Examples: driver app for your delivery staff, real-time order management interface for your kitchen staff.

Do you need an interface for manually approving users/content?

Do you need a content moderation system? A way for your admins to easily remove user content, disable user accounts.

That’s… a lot of questions.

Yep! And it’s really just the common ones that people often forget early in the process. There are many more that will be specific to your product, and that you’ll uncover over time.

Bringing it all together

This process of building an outline and interrogating it will tell you what’s missing. Repeat this process a few times, and you should have a pretty solid feature list that you are much more confident about.

You know, I was really hoping you had this one weird trick to fix my project. This sounds like a lot of work.

It really is. But this is work you would have done at some point in the process anyway.

Remember why we are doing this. Software features have hidden complexity that you will need to uncover no matter what. You just get to choose when you peel the onion.

Essentially, you have two choices:

You can discover user objectives, build a mockup or flowchart, question your own assumptions, and peel back the layers like we did above. Or, You can get a developer to start building your app and uncover these issues with each version, one week at a time. After several months, you will discover the exact same things you could have figured out in a week with pencil and paper.

This is why software projects blow up and try to eat you alive.

So, go and discover your features. Build your outline and question your assumptions. Uncover the bulk of your problems quickly and cheaply.

Save yourself the stress and pain, release your product out into the world, and let it bloom.

Do onions even bloom? Your metaphors are stupid.