The Product Change Committee has met twice in the last couple of weeks and for those of you who don’t feel like going through the notes or listening to the recordings, I thought I’d share highlights from the discussions, decisions, and what comes next.
We had extensive discussions about the purpose of this committee and agreed that it is to create a vision and a roadmap for our technical products that responds to and reflects country implementation needs. This committee will set our technical direction and work closely with the Technical Action Committee (TAC) on our technical roadmap, providing Operations with resource recommendations and needs. We can start off with something small that shows how we’ll get something done.
@wanyee highlighted the need to ensure that we have complete and accurate information about what implementations and countries are interested in and what they need. At the same time, we acknowledged that may not be realistic or feasible to have all implementations routinely contributing to this committee so we’ll continue to explore different ways to engage these key stakeholders. Initially, we could look at having those on this committee or the TAC liaise and represent different implementations and ministries. For instance
@wanyee offered to liaise with other implementations in Kenya, others in the same time zone.
@dkayiwa is working closely with the Nigeria and Uganda teams. Until others from those teams join in, he is open to either representing them or working to engage the right person from those implementations.
These meeting are action oriented and we aim to make a decision each time we meet. So what decisions have we made so far?
We’d like to have at least 2-3 implementations contribute to this effort - and we expect more stakeholders will participate in these conversations as we get into the work.
For now, decision making authority will rest with those with “skin in the game” who show up. When implementers see high value in the roadmap, they are likely to commit resources to getting the work done.
If someone can’t make a meeting, then they will send someone in their stead.
Communication
The PCC will meet on a weekly basis. Wednesdays at 4pm UTC was proposed.
Talk will be used to announce meetings, share notes and decisions.
We’ll also use this Talk thread to post key questions for community discussion, updates, meeting announcements, and decisions.
In between calls, we’ll use the #product-change Slack channel for brainstorming and working through action items on a day-to-day basis.
The PCC now has a Wiki page where you can find information about meeting times, links to this thread, the Slack channel, and notes/recordings from any meetings.
Outstanding questions:
How do we effectively engage with countries and implementations so that a) they are more active with the PCC or TAC, and b) our roadmap reflects their needs? There were a few ideas (mentioned above) - let’s keep ideas going!
What tools or approaches can we use to gather input from implementations/countries? @wanyee suggested gathering roadmaps. We also have input from Scrum of Scrums/Community Stand Up and OMRS18’s How Might We?
How do we define our technical products? What are people using and what do they want?
What is our vison? Let’s go beyond “buidling an EMR” and get into the details, such as point-of-care, offline, etc.
What is our approach for getting there (incrementally or all at once?)
Here’s a summary of the key points and decisions that came out of this week’s meeting.
This committee should have the expertise/representation that leads to verifying priorities with implementations instead of asking for information.
We already have information from meetings, community stand ups, squads, etc. For instance, JJ already has a list of 5-6 features that the MF Squad is working on in the coming weeks. He will share this for wider input.
We will set out a foundation using what we already have and know about how the product should evolve in the next 12 months, then build from there. We agreed that we can start with priorities for MF, FHIR, and others already shared with us. We also agreed that other aspects beyond the user facing application should be included (OCL, FHIR, tools for migrating/importing data, etc).
In regard to outreach, all of this means that any outreach to countries + implementations should be focused so that these exchanges are additive and valuable. We can use this as an opportunity to invite implementations to be a part of this process (if they have not been very involved to date).
Several times, we found ourselves referring to or talking about technical solutions - and almost each time, someone paused to either suggest that the Technical Action Committee take something up (i.e: what needs to happen next with Sync 2.0) or question how the two committees work together or overlap. We’re experimenting with these committees, so the fact that these questions and observations are coming up is great. We may not answer all of these questions right now and new ones may emerge in the coming weeks.
At the last PCC meeting, we talked through some important questions around:
What is the role of squads and this committee when it comes to priorities? The squads that we have are forming because people are coming together to work on shared priorities. That’s great! And what does this mean for the community priorities that the PCC is in the process of working out? There isn’t a full and complete answer to this question yet.
How do we organize all of the information that comes to the PCC through squads, conversations with implementations, community stand ups, bootcamps, etc? We looked at this spreadsheet to help us think through this. Some good ideas emerged - and we recognized that we’ll likely make additional improvements as we go through this process.
And here are some key points and decisions that were made:
In order for us as a community to mobilize to meet our needs, we need to know our priorities. Knowing these priorities is only useful if there is a way of accomplishing them. If we don’t know our priorities, then people will either work on tickets that are 10 years old, on a module that isn’t useful to an implementation, or on a feature that is only useful for one or two implementations and not the community more broadly.
The spreadsheet is a good starting point for organizing information - as we work through this process, we will make improvements.
Outstanding/On The Radar
A suggestion was made that we still need to have and communicate a vision. For now, the focus is on completing list of priorities, keep this on our radar to re-visit once we have more information on needs.
Once we have a list to present to the community, how does the community prioritize it? What is this process?
How does this committee handle priorities defined by squads (MF, FHIR) vis a vis related priorities identified by implementations and in turn, the PCC?
Action items:
Review the Priorities by Group tab to identify then fill in gaps in information. These gaps need to be filled through individual conversations.
What individual conversations do we need to have? Who will have which ones?
Everyone is welcome to ask questions, comment, and share ideas. Feel free to respond here, on the #product-change Slack channel, or join the PCC meeting on Wednesdays!
“Priorities by Group” tab review: This list is clinically focused and does not really represent the technical approach, framework, technical underpinnings. We agreed that this list could inform use cases and drive the technical conversation, rather than starting with a hypothetical discussion about functionality
This discussion would be richer, get more details if we had those who provided the information during scrum of scrums on the call. Participation on the call will grow when there are resources made available, or results are seen.
Do we prioritize a short list now (in collaboration with the TAC) with those currently participating or wait until we have a more comprehensive list for the community to prioritize in Maputo? The group decided to identify a short list and ask Operations about resources for a squad to do some sprints.
Several possible issues to focus on. microfrontends, concept management/OCL integration, Sync 2.0.
OCL is of interest to several implementations and is in need of a lead to drive this.
We discussed attendance at both TAC and PCC meetings and the possibility of having joint meetings with the TAC.
Action Items
Share resourcing needs for an OCL squad for some initial sprints with Operations
Have a joint call next week with the TAC to look at integrating the work of both committees (priorities + technical objectives)
The main question we wanted to answer during Wednesday’s joint PCC + TAC call was: are we at a point where we can merge the PCC’s work on known requirements with the technical objectives that the TAC drafted?
Short answer: Not yet.
Key points and decisions
The requirements on the Product Priorities worksheet are more features than core technical frameworks or functionality. Some are too broad to even say. This might only capture what people are working on for the next six months, not what they would like to see or how they would like to see core evolve in order to make building features easier. Decision: We need to learn more about the requirements and flesh them out.
There is also a question about how we align the requirements/priorities with the platform, the ref app or another distribution, a module, etc. We could look at these as core/technical infrastructure, functionality, and feature. We had some discussion about collaboration and whether or not it could happen for features as well as functionality.
It wasn’t immediately clear where all of these requirements were coming from - or how they will be prioritized. Most came from the September scrum of scrums, others from country implementation requirement lists, and still others from squads or individuals.
When it comes to prioritization, what criteria will we use? Something that is requested by the largest implementations or the used by the most implementations? Decision: We need to come up with a prioritization framework.
The technical objectives still need work and there’s an outstanding question about how features will fit in with the technical objectives.
So we have some action items to get started on between now and next week. I’ve added some suggestions around who could take each on (including myself).
Create a framework for prioritizing requirements. @janflowers and @mogoodrich, do you want to work on this? Here is a Google document that could serve as a starting point.
Product Change Committee Action Items
Flesh out the product requirements listed. This will mean following up with implementers to determine what they are actually working on and what core infrastructure/framework/functionality would make it easier for them to build features.
I will suggest that we have a session during the Moz meeting to further discuss priorities for Implementers and particularly identify commonalities. I’m still interacting with Implementers to share their roadmaps.
Yesterday, @wanyee and I thought we’d find ourselves a corner at GDHF to simply review country roadmaps+priorities to find common areas. We managed to bring @terry, @maryrocheleau, @janflowers, and @gschmidt into the conversation and it ended up being much more.
We need a roadmap that strikes a balance between what implementers are asking for and what is needed more broadly.
Can we look at @jteich’s set of core functions and pick a couple of domains to work through generically, building off of work that has already been done for HIV? Hypertension and antenatal came up specifically.
A quick update about the PCC’s meeting times in 2020:
Based on December discussions and next steps, this group will hold off on meeting separately from the TAC until we have some concrete results from one-on-one conversations with implementations about their 2020 priorities and challenges that we can integrate into a more responsive roadmap.
If you are interested in joining @wanyee and myself in those conversations, please let me know. As we go along, we’ll share a summary of key points from those conversations here as well. Once we get to a point where we can move on to the next step, we’ll set something up.
