Report, understand and prioritize unmet needs

How do we process unmet needs (problems) reported by users that are not yet satisfied by the platform?

1- Needs collection and understanding

When a need that is not currently satisfied by the software is reported by a user, either the user or the local instance support team / product owner will record that need into the "software improvement" category on Discourse, "Wishlist (needs curation)" sub-category. A template is displayed to guide you in how to report the need.

Most of the time, the reporter of the need will not have all info when they start the discussion about this new need. So until the need is clear enough, it remains in "wishlist category". When discussions move on, the curators of the discussion will update the main post to always keep the up-to-date the specification of the need. Some candidates might appear and one option might be quickly chosen in the discuss. When the curators think the need have been clearly understood and well reported, they can change the category to "voting candidates".

WARNINGS: Users will tend to express their needs as solutions or features ("I would like a new button here that will let me do this thing...") and won't explain clearly the need behind it ("I'm having trouble finding this thing and it's one of the most frequent things I do"). It is the responsability of the local instance PO to understand the underlying need, and express that need in a structured way, before starting to brainstorm potential solutions.

2- Needs priorization

Lots of OFN users in different countries have different needs. So how to decide which need we address first?

Each instance will have their way to discuss with their users and decide together with them what are the top priorities for that instance. For now, every active contributor will have 5 votes they can allocate to any voting candidate. Once a feature is moving forward, that will free votes, that can be reallocated. Votes can also be reallocated at any time, until a feature enters the pipe. To make the process smoother, we will send reminders to instance managers so they think to regularly update their votes.

When we forsee some space coming up in the delivery pipe, we can start processing the needs/features that have collected more votes. We will use the delivery pipe standup meeting to invite product owners to pitch the features that are the most urgent and import for our collective. So votes will counts, but we also allow some space to discuss priorities.

The current piroritized pipe can then be seen in Github.

This process needs to be adaptative: if something important happens and might result in modifying this priority list, any instance representative can join the next delivery pipe standup meeting to explain and propose some modification to the pipe.

3- About "emergency needs"

Some users sometimes express their need as an "emergency need". We invite instance managers to question why it is an emergency. In OFN we consider as emergencies only bug severity 1 and 2 that really prevent users to use the platform. For a new need not yet satisfied, if you consider it is an emergency, you can always join the next delivery pipe standup meeting.

‚Äč