If now you have some good ideas and hired oneThe engineer materializes the idea,
Over time, you find that some items need to be adjusted and the scope of functions is slowly expanding.
In the end, this project was out of control, devouring your life step by step.
Why is this happening?
Not necessarily because the engineer is not professional enough, or because you don't know anything about project management, or because the idea is bad;
In fact, it was because of some small misunderstandings that the project was doomed to its ultimate destruction from the very beginning:
We would think that the product is composed of some functions,
Some of these features have been rejected, or other features have been added,
All functions are clearly on the white paper;
In fact, this idea is wrong.
Your project is not just a blank sheet of paper that can be seen at a glance, it has depth.
Online libraries end physical libraries
Let’s look at some concrete examples,
This is a new project idea:
Many people often need books that are not in the library. When someone may own the book,
The requester sends a request through the app, and the other party will respond,And we take some profit from each transaction.
The feature list is very simple:
After passing the product specifications to the engineer, help the app think of some killer names.
kaBooki? lib.rari.ly? hubsoda?
Someone already uses the name hubsoda.
Then we can think about some problems that need to be solved...
How do users pay?
Will it be delivered directly? Or pay through the app?
A: They should pay by credit card in the app so that we can collect fees from it.
How do users find books?
What actions do they need to do to find books on the app?
Fill in the form for the title and author?
A: They should find books by searching.
...So we need a book database.
What is the demand for books? Can the bookseller see the list of all books?
Or, do we send notifications to sellers like Uber or Thumbtack?
A: We send a request to those who have this book
So, does the seller need to put all the books on the app?
A: Yes, yes.
How to ship this book? The user sends it by himself, or we handle it?
A: Let's deal with it.
So you need a system that tells you which books and destinations you need to pick up?
A: Stop it, let the user send the book to the other party.
Do we send the recipient's address to the sender? How to deal with shipping costs?
A: These users must live very close. After getting the book, make a new friend by the way?
Therefore, we need to match nearby users.
How do they find each other? Is there an instant map on the app to arrange a meeting?
We set the price of the book? Or do they discuss the price themselves?
A: They decide the price themselves.
How do they decide? Do I need a chat room on the app?
A: They can call.
Do we need to verify the number by SMS?
These problems will extend indefinitely...
Let's see what the feature list looks like now:
Each function in the list can be extended further.
Let's clarify the cause of the feature explosion...
This is not what we generally call feature creep (feature creep)
Each item in the final feature list is to support the initial idea,
Instead of constantly adding new features to the product.
It has nothing to do with technical considerations.
This has nothing to do with which payment platforms can be easily integrated into the app.
The engineer can suggest which technology you should use, but he cannot decide what function you need.
It has nothing to do with market considerations.
Are you still thinking that someone will use this product?
In fact, these questions are only used to verify your ideas,
Determine whether the product is suitable for the market, and understand the pricing strategy,
There is no way to tell you why the feature list is so large that it explodes.
We all misunderstand how complexity works.
We thought that each function was as complicated as the “online library paradigm” described at the beginning,
But this view is wrong.
Functions in the app are like maps
The closer you look, the more details you find.
When we build or use an app, the scale is still small;
A complete app needs to be tested step by step,
At each stage you will find some problems,
Then you must redesign, add new steps, or add new features.
Just like you are planning a route, it looks like a straight line on the map,
If you consider the small part, you will find that there are several turning blocks and traffic lights on this straight line;
Different commuting methods have different routes.
The same is true when building a software,
After zooming in, you will know the solution.
Will my product be left unfinished?
Our goal is to describe the function, which is usually very complicated.
For this goal, we have carefully looked at each step,
The closer you look, the more problems you will find.
Complexity is not the main problem, the problem is how do we find these functional problems,
We handed over the product specifications to the engineers, and we got the first version of the results a week later.
When we first used it, we walked through the whole program step by step and found huge loopholes,
Record the places that need to be modified, and then construct the second version for the engineer.
After several such processes, we have a good solution;
The trouble is that the round-trip cycle is too long, each cycle lasts for several weeks or months.
This kind of complicated process is necessary,
But it is time-consuming and expensive to keep dealing with engineers.
We should do this:
Before we write a long list of programs, we have to discover as many complicated places as possible in the app.
I hope to use the fastest and low-cost way to build a more powerful feature list step by step,
We would rather revise the specifications repeatedly than spend too much time on revising the entire app.
Never go through the following process:
Instead, follow this process:
To effectively walk through the entire process, we need two things.
First, present the function list so that the process can be repeated.
Second, effectively interrogate the established function list.
So how do we do it?
Draw the function
Don’t think from a business perspective, think from a user’s perspective.
First, list the user goals. What is the purpose of the user using the app?
Next, draw the user's process.
Go through every step before the user reaches this goal and record it.
You can draw mockups to record every interface the user browses,
You can also use a piece of paper or software to draw a flowchart.
No matter which method you use, remember that your speed must be fast!
Every interface must be on the outline.
If there is a step that will appear on different interfaces, it is necessary to draw them separately one by one.
We need more details!
This process alone can surface all the small and complex things on the app.
Next, let's dive into some issues:
As the questions mentioned above are more open-ended, it is difficult for us to know where to start.
Here is a list of common problems applicable to most software;
The questions are divided into four categories, allowing you to pick out the questions from the outline.
Look at each step in the outline, apply the questions in the list,
If these questions can be extended to a new step, add it to the outline.
The list is as follows:
1. User input
These issues range from users to products.
Open-ended example: freely input the form of text, choose the picture to upload, record the video.
Interactive example: input text into the search bar, display the results that can be selected, select an address on the map, choose from a predetermined option.
2. Message presented to users
3. Communication between user experience
These questions are about how users, products, and other services communicate with each other.
4. Features needed by business owners
What business owners need to get from the product.
The process of constructing the outline and interrogation will let you know what is missing in the app.
Repeat this process several times and you will be confident that you can get a very stable list of features.
Sounds complicated, right? But you will definitely encounter these problems at a certain stage of work.
The function of the software hides a lot of complexity, find out and solve them!
You now have two options:
First, discover user goals, construct models or flowcharts, question your own assumptions, and uncover all problems step by step.
Second, let the engineer start building your app, and each problem will take a week.
After a few months, you will find that you can find exactly the same things in a week with pencil and paper.
Identify each function, establish an outline, and question your assumptions.
Find most of the problems quickly, save yourself stress and pain,
Publish your products to the world and look forward to beautiful harvests!