Your Ideas are Always Welcome

A Small "Acceleration" Tip for Friends Who Give Suggestions

As the developers of QuickPlanX, one of our happiest moments every day is receiving your feature suggestions for this iOS/macOS project management app. It makes us feel that it has truly become a part of your work and life.

An excellent app relies on a large amount of user feedback. We welcome any ideas regarding feature improvements, even if it's just a simple sentence.

After receiving feedback, we strive to understand the background information behind your suggestion, analyzing the pain points it aims to solve or the potential benefits. However, if your suggestion can directly inform us of the pain points to be solved or the expected benefits, the processing speed and the likelihood of adoption will be greatly increased.

Why Do We Sometimes Ask "Why"?

This explains why, when faced with a seemingly simple suggestion, we sometimes don't immediately say "Yes," but instead repeatedly confirm details. This is not an evasion, but because from a development perspective:

There are often multiple paths to achieve the same goal.

If we only focus on the "specific feature" you proposed, it is easy to be limited to a specific implementation method. But if we know your "pain points" and "benefits," we possess a broader vision:

• Finding a Better Solution: We might use our familiarity with the app's design and technology to design a more suitable, faster, or more balanced solution for your idea.
• Discovering Existing Solutions: We might find that other existing features can already meet your requirements, allowing you to solve the problem immediately without waiting.
• Avoiding Misunderstanding: The possibility of misunderstanding your suggestion decreases significantly, ensuring that what we make is exactly what you truly need.
• Improving Efficiency: Reducing the communication cost of repeated confirmations allows us to complete evaluation and decision-making faster.

A Real Small Example

A user once strongly suggested: "I hope to add an email integration feature so I can send emails directly within the App."

Although this feature sounds intuitive, we asked about the scenario behind it: "What specific information do you want to send? And to whom?"

The user explained: "I need to send detailed instructions for specific tasks to outsourcing personnel for confirmation."

Hearing this, we understood. It turned out his pain point was not "must write emails in the App," but "how to quickly extract and share information."

If we only did "email integration," the feature would be very limited and bloated. In fact, the fields everyone needs to share vary widely (some want dates, some only want notes), and the sharing channels are not limited to email (maybe also WeChat, Slack).

So, we switched to developing a more flexible "Customizable Task Text Output" feature.

• For that user: He customized the output format (keeping only "Task Name + Notes") and sent it directly via email through the system share function, perfectly solving the problem.
• For everyone: This flexible and configurable output method also met the various sharing needs of other users, such as writing daily reports or sending WeChat messages.

This is the magic of "background information." It helped us transform an originally narrow "email requirement" into a "universal feature" that benefits everyone.

Talk More About "Context," No Need to Write "Docs"

So, next time you feel a requirement is complex or hard to explain in a sentence or two, try briefly chatting about your "Usage Context."

You absolutely do not need to write a formal requirements document (of course, if you are used to writing in detail and professionally, we would be even more delighted).

But in most cases, no professional terminology is needed, and don't worry about being right or wrong; just mention the following two points in passing:

1. What trouble did you encounter? (e.g., The current operation is too tiring, prone to errors, or unclear.)
2. How are you coping now? (e.g., Can only manually calculate with a pen, or have to go to settings to repeatedly toggle switches.)

Ordinary Suggestion: "Add a batch delete feature." Suggestion with Context: "I have to clean up dozens of old data items every day. The current design requires swiping left one by one, and my fingers are sore."

Even with just this one extra sentence, we can often immediately judge: This is a high-frequency efficiency bottleneck, worthy of priority evaluation.

Your Ideas Are Important, and the "Reasons" Behind Them Are Equally Critical

Sometimes, enthusiastic users like you might not help but worry for us: "Is doing this better for the App?" or "Will adding this feature make the application more complete?"

Actually, the specific feature suggestions you propose are very important; they are often the starting point of our inspiration.

But compared to an isolated "solution," what we need more from you is the "problem itself"—especially when we cannot simply understand the underlying motivation (pain points and benefits) from the feature description, this background information becomes particularly critical.

Because from a development perspective, the "desired feature" is just one of the options to solve the problem, while eliminating your "pain point" is our common goal.

Having clear background information (pain points and benefits) brings two direct benefits:

1. More Accurate Judgment: We can understand the real value of this feature to you. Some features seem "troublesome," but if we know they solve your core pain points, we will increase their priority.
2. Superior Solutions: Just like the "Text Output" case above, maybe we can use our familiarity with the system to find a simpler, better solution for you than you originally imagined.

Therefore, that real moment when you get stuck is often more important to us. We will combine your proposed feature suggestion with the actual pain points behind it to conceive the most suitable technical implementation plan for you.

Not Just Making Suggestions, But Sharing Your "Best Practices"

There is another deep reason I want to share with you.

The reason QuickPlanX can become an app loved by everyone is that our goal has never changed: To share the industry's best project management practices with everyone through the form of an application. We don't want to just be a tool for "drawing Gantt charts," but are committed to being a carrier of efficient management thinking.

From this perspective, every suggestion you make is essentially sharing your exclusive experience and best practices with the community.

This is why we are so eager to understand the pain points and benefits behind the suggestions—because only by truly understanding your "practice methods" can we transform them into universal features, ultimately benefiting you and thousands of users like you.

---

Appendix: Under What Conditions Will a Suggestion Be Prioritized?

(If you just want to know "why we ask for background," reading the above is enough. The following content is for friends interested in product decision-making.)

To make the process more transparent, we also want to frankly share the development team's "Decision Criteria."

If we do not understand the "pain points" and "benefits" behind your suggestion, we cannot judge based on the following 7 core dimensions, which may cause an originally good idea to be shelved.

1. Core Alignment

This is the primary principle. Although our application supports extensions, it must revolve around core features.

• Some features are great, but if they are too far from the app's core positioning, we may have to reluctantly give them up to keep the software simple and focused.

2. User Reach

We need to assess whether this is a "universal pain point" or a "special case."

• If a feature can only solve a very special need for a very small number of users, its priority will usually be ranked after features that "benefit the majority."

3. Value Magnitude

Even if it is useful to most people, we also need to see if the improvement it brings is significant enough.

• For example: Saving one click for a feature used only once a week might not be high value; but if it is an operation repeated dozens of times a day, even saving one second is huge value.

4. ROI & Balance

Of course, we also need to balance development resources.

• We will evaluate the cost of implementing this feature (development time, system complexity) and whether it is proportional to the benefits it brings.

5. Generality over Specificity

This is where disagreement most easily arises. Sometimes, the feature you suggest is to solve a problem more "directly," but the app's existing core or basic features actually already support that requirement.

• It's not that existing features are bad, but we tend to maintain the generality of the system. If we add a "dedicated shortcut" for every specific scenario, the software will quickly become complex and difficult to use. Unless the scenario is extremely high-frequency, we will prioritize maintaining universal basic support.

6. Specialization & Ecosystem

Many times, a requirement is actually the strength of another professional field.

• For example, although our app supports table views, our core is "project planning," and we cannot (and should not) replicate Excel's powerful calculation and charting capabilities; or for complex PDF editing or print layout, there are already very professional software on the market that do better.
• In this situation, rather than developing a "crude and bloated" built-in version, we prefer to optimize the "export" or "collaboration" experience, making it easier for you to send data to those professional software for processing.

7. Independence & Best Practices

QuickPlanX is by no means a simple clone of other similar apps on the market. Our goal is to bring industry best practices to the public at an incredibly affordable price.

• To maintain this cost-effectiveness and lightweight experience, we need to avoid piling up features like those expensive enterprise-level software. Therefore, "other apps have it" is never a reason for our development. We would rather remain unique and streamlined than become bloated and expensive to cater to all needs.

8. Appropriateness & Compliance

We reserve the right to decline suggestions that we deem inappropriate.

• This includes suggestions that are unclear, or that conflict with laws, regulations, or cultural norms.
• Any other suggestions we consider inappropriate.

Sharing these is to let you know more clearly the factors we consider during product planning. We hope to use your "background story" to help us find the correct decision among these complex dimensions.

Every Voice Echoes

Finally, we sincerely want to express:

For any suggestion received, we will strive to discover how everyone uses this app and the thinking behind it.

After all, although we are familiar with code, you are the expert of your own workflow. If we only receive a lonely feature instruction, sometimes it is really hard for us to penetrate its mystery in your actual use, and we may regretfully miss the opportunity to help you.

But with just that little bit of extra background information, the situation might be completely different.

Even if your specific suggestion is not adopted for various reasons, it is still of huge help to us. Your feedback helps us piece together a more complete user profile and points out potential blind spots in existing designs. These bits of feedback gathered together might one day give birth to a brand new, better idea.

Thank you to every friend willing to spend time giving feedback; it is your real experience that makes this App better and better.