The M2W Edu feature roadmap is the list of what the platform plans to build and in what order. It is formed mainly from the real needs of day-to-day users, not from an internal list of ideas.
This article covers how to give input so that a proposal is taken seriously, the criteria that determine priority order, and the types of proposals that will not be implemented no matter how many people request them.
Why input from schools matters
Whoever builds a tool always has a more limited view than the people who use it every day.
The development team knows how the system operates, but does not know how long it actually takes an international cooperation staff member to update tuition fees, or where in the process they end up doing things manually.
Only users know those details, and they are often the source of the most valuable improvements.
So most items on the roadmap come from three sources: direct proposals from schools and partners, recurring issues in support requests, and observations of where users have to work around things manually.
How to give input effectively
How something is presented has a big effect on whether a proposal is correctly understood and prioritized.
Describe the problem first, the solution second. This is the most important point.
A proposal like “we need an export button” tells you the solution the proposer thought of, but not the problem. There may be a better way to solve the same problem.
A proposal like “every quarter we have to manually copy figures from records into an internal report, which takes about half a day” tells you the problem, the frequency, and the time cost. From there, the best-fitting solution can be found.
State the frequency and scale. Does this happen every day or once a year, and does it affect one person or a whole department.
State the current workaround. If there is already a temporary way of handling it, describing it gives much more insight than an abstract description.
Include a specific example. A real situation that actually happened is more persuasive than a general description.
Criteria that determine priority order
Not every good proposal gets built right away. The four criteria below determine the order.
Number of users affected. An issue that many schools face together is prioritized over a specific need of a single school.
Impact on data quality. Features that make data more accurate, more up to date, or easier to verify are given high priority, because that is the platform’s core value.
Time saved. An improvement that saves each school half a day per quarter has large cumulative value.
Complexity to build. Between two proposals of comparable value, the simpler one is usually built first, because it produces results sooner.
The second criterion carries the highest weight. A feature that makes the platform more convenient but does not improve data quality will rank below one that does the opposite.
Types of proposals that will not be implemented
This needs to be stated clearly to avoid wasting time on both sides.
Proposals about display order. There is no way for a profile to get priority display other than by adding sourced information and keeping the verification date current. This is a non-negotiable boundary.
Proposals about ranking or scoring. Even if many users request it, the platform will not build a ranking function, for the reasons already stated in the section on the platform’s boundaries.
Proposals to remove accurate information. If information is accurate and sourced, it will not be removed because it is unfavorable to one party.
Proposals to display learners’ personal data. A hard boundary, with no exceptions.
Proposals that amount to promotion. The profile presents data in a standardized structure; it is not a place for marketing content.
When a proposal falls into one of these five categories, the response will state the reason clearly rather than staying silent, so the proposer understands this is a decision of principle, not a matter of priority order.
How the M2W Edu feature roadmap is published
Publishing the roadmap involves two considerations to weigh, and the approach is to publish at an appropriate level of detail.
Publish what is being worked on and coming up next. Users know what is coming and can plan accordingly.
Do not commit to exact timing for items that are far out. Time estimates in software development are often inaccurate, and a missed commitment causes more harm than no commitment at all.
State the status of each item clearly. Being built, planned, under consideration, or decided against with a reason given.
The last group is worth publishing too, even though it may sound negative. It prevents many people from proposing the same thing that has already been considered and rejected.
Each completed item should come with a notification to the users who requested it, along with a short usage guide.
Testing before wide rollout
For major changes, the sensible approach is to test with a small group first.
Choose a representative group. A few schools of different sizes and usage patterns, rather than only the most active schools.
A long enough testing period for users to encounter real-world situations, not just try it a few times.
Collect structured feedback, focused on whether the feature solves the original problem.
Be willing to cancel it. If testing shows the feature does not solve the right problem, stopping is the correct decision, even after effort has already been invested.
This last point is hard to act on in practice but important: a feature that is not useful still increases system complexity and raises maintenance cost indefinitely going forward.
Balancing new features with stability
A principle rarely discussed but with a big effect on user experience.
Every new feature makes the system a little more complex. After many additions, a tool that was once simple can become hard to use, and new users will take longer to get up to speed.
So the roadmap should include not only additions but also removals. Rarely used features should be considered for removal, and removal also needs advance notice so users have time to adjust.
A practical rule: for every significant new feature, review whether some existing feature is no longer needed. This keeps the system from bloating over time.
Channel for submitting feedback
For input to happen regularly, there needs to be a clear channel and genuine responses.
Kênh chuyên trách. A dedicated address for product feedback, separate from the technical support channel. These two types of requests have different processing rhythms, and mixing them slows both down.
Respond to every proposal. Even when the answer is not yet or will not be done. A proposal that goes unanswered makes the sender less likely to give input next time.
Thông báo khi hoàn thành. Whoever proposed the feature should be told it has been built, along with a brief guide.
Hold regular exchanges with key user groups. One short session per quarter usually yields more information than dozens of survey forms.
This session should include the people who actually build the product, not just the support team. Hearing users describe their difficulties firsthand creates understanding that no summary can fully convey. Many of the most valuable improvements come from an offhand remark made during such sessions. For that reason, the session should stay open-ended in content rather than sticking rigidly to a prepared list of questions.
The role of negative feedback
Comments pointing out where something is hard to use are usually more valuable than praise.
Users often hesitate to raise them, thinking it’s their own unfamiliarity. In reality, when many people struggle at the same point, the problem lies in the design, not the user.
Three types of feedback are especially valuable.
Places where users have to ask. If an action requires asking before it can be done, the interface isn’t clear enough.
Places where users do something wrong and then have to fix it. This is a sign of a design that is easy to get confused by.
Tasks users abandon partway through. If a process is often abandoned midway, it’s probably too long or requires information the user doesn’t have on hand.
When these needs need to be placed in the broader context of international education, data and reports from the Organisation for Economic Co-operation and Development (OECD) provide a reference on general trends.
For proposals related to how degree recognition information is presented, the framework of The United Nations Educational, Scientific and Cultural Organization (UNESCO) is the reference standard used.
Each feature should only be added to the roadmap once it has a user, a problem to solve, and clear acceptance criteria.
Summary
The M2W Edu feature roadmap is built mainly from the real day-to-day needs of users, and the most effective way to give feedback is to describe the problem along with its frequency, rather than proposing a solution.
Four criteria determine priority order, with impact on data quality carrying the highest weight.
And five types of requests will not be implemented no matter how many people ask for them, because they touch boundaries the platform has already stated publicly.
Next Steps
Observe your school’s work over one week and note down the places where things have to be done manually or where the same information has to be entered repeatedly in multiple places.
That list, together with frequency and time spent, is the most valuable feedback your school can send, and it is far more concrete than feature proposals.
There’s no need to wait until the list is complete before sending it in. A single item, clearly described with a real example, is already enough to be considered, and it often opens a conversation that leads to discovering related issues the person who raised it hadn’t even thought of.
