ORCID is many things to many people. It’s a helpful resource that saves researcher time, it’s a place for researchers to connect to their achievements, and it’s a way of distinguishing one researcher from another. It’s also a tool that can help with reporting grant outcomes, filling out forms, understanding someone’s career, and linking up services. This complex interplay between users and functionality mean that it’s very important that, when we add things to the API or modify the user interface, we’ve really thought it through — not only what new functionality will do, but also who the change will affect, how they will react, and what benefits it will bring.
I’m the Product Director. What does this mean? It means that I consider all the competing requirements and work out how to balance the time they will take to develop, the utility of the changes, and where they fit in our strategic roadmap. My job is to help evolve ORCID infrastructure so that it serves the whole research community. I do all of this while trying to avoid a bad back from my temperamental office chair!
Mine is a new role within ORCID and it marks our transition from energetic start-up to energetic small-medium sized not-for-profit organization. We are now at the point where the ORCID Registry is essential to the functioning of numerous other services — from grant application and manuscript submission systems to individual user profiles — and we need to change the way we work to match. We have over a thousand members: two-thirds of them have one or more integrations, and all of them depend on us continuing to function as they expect. This means we must be mindful about how and how long we take to evolve. When we introduce changes we have to help all our members change along with us.
Requirements for change come from many sources, internal and external to ORCID. Researchers, research institutions, funders, publishers, research facilities, infrastructure partners, librarians, repositories, working groups, data analysts, web developers, our Board and our staff have all got lots of great ideas about the future of ORCID (and If you’ve got a great idea, head over to our iDeas Forum and let us know!). I and our cross-organization Product team ( Paula Demain, Estelle Cheng, and Ana Heredia) attempt to balance these requirements when deciding which things we should start working on. You can read more in How Are New Features Decided? — including how we decide if something is a feature or a bug.
We’re champions of ‘open’ and, because of that, our product development process is as open as our data. You can see what we’ve got lined up for the future on our public product roadmap, which contains all the work we’ve committed to doing at some point. This is the functionality we’ve analysed, thought through, and are confident should be included in the Registry. As time and resources allow, work is transferred from there to our Current Development Trello Board, where it is picked up by our Technology team and implemented, tested, and released. We also maintain a Bugs Board, where we keep track of the bugs we find ourselves and the ones that are reported to us by the community. Having all this out in the open means that if you report a bug, or request a feature, you can see it move through to our production service. Learn more about the process for reporting and fixing bugs in How Are Bugs Fixed?
I think ORCID has done a fantastic job of balancing what we do, who we do it for, and why. ORCID is moving into a new era and we’re refining the way we work so that we continue to get that balance right as we grow. I love my job here at ORCID, and I’m privileged to be involved.
