How do you manage a product and design a service to a horizon of at least 2050?
The National Public Transport Access Node (NaPTAN) is the data set of “what” is “where” for all of the Great British public transport. It covers every bus stop, tram station, metro station, train station, airport and ferry terminal in England, Scotland and Wales. It is crucial to the whole public transport ecosystem, and it has existed since the late 90’s, with the current form being published as an open data set from 2005.
This is not a typical product in any sense. With critical public sector products like NaPTAN, ‘short term’ is measured in years, and every decision must be made with a view to ensuring the system remains strong and functional in 2050.
We are constantly operating on a longer-term roadmap than my working lifetime, looking at a horizon of 25 years or so.
Learning from the long-term evolution specialists
Consider the evolution and survival of the crocodile, still thriving in parts of the world. Crocodiles as a family are older than the rings of Saturn and have survived two mass extinction events.
Following both extinction events, they’ve evolved out of their niche as apex predators at the water's edge into other roles in the ecosystem, both as herbivores and into fully aquatic predators. In all these cases, they couldn’t adapt enough to survive long term in those environments and were competed out of those spaces by mammalian herbivores and cetaceans.
Since those events, crocodiles have evolved and changed into something truly unique. They have hearts that are more like mammals’, breathe like birds, can walk like either a lizard or a mammal, and have mastered their environment. They are like an iron girder made of muscles, their ability to take down large prey is quite iconic.
NaPTAN is remarkably similar. It has survived three events that would make a lesser data set extinct — migrations to different technology, changes in ownership, and shifts in government focus.
Just like the crocodile, NaPTAN has survived by doing one job well. It is the only solution to the unique way the UK is set up for public transport. It could try and do other things, and that would evolve the whole data set into complications and extinction.
How do you get into this mindset?
So, how do you continue to evolve an ecosystem, a data set, and a system that is so old, so specialised and so crucial to the economy?
How do you add features? To help us make the right long-term decisions around how features are added and work is prioritised, we continuously ask a few key questions:
We use a couple of principles:
Is the change needed?
We don’t change for funsies!
Change (and evolution) has to have a deep purpose. What will this add to the Stability, performance and security of the current solution? Is there a way to make the system more efficient with this change?
What is the value of making this change? What is the value/cost of not making this change?
Can we get away with doing nothing?
Can we measure the outcome of this change?
Funsies are not enough of a measurement.
If it is to meet a standard, either in code or data, does this standard deliver any benefit right now? If we can’t measure the success of a change, that’s an early indicator that it may not be beneficial.
We follow an outcomes over actions rule here. There may be actions that some of the ecosystem wants to take, and before we implement those actions, we ensure the outcome is of value to everyone.
This helps us ensure that all changes are aligned around the same outcomes and build on each other to drive progress towards a valuable outcome.
Why NaPTAN?
Is the NaTPAN the best place for these new funsies?
Before we make any changes to it, we need to be sure that NaPTAN is the optimal place in the public transport service to make that change.
This helps us identify situations similar to those where crocodiles moved out of their optimal space, where change pushed it into new niches where they couldn’t be successful enough to survive long term.
By considering if there are any other areas or systems that could implement the change more effectively, we keep NaPTAN tightly aligned to its core purpose.
How does this apply in the real product world? Where there are no crocodiles to talk about!
A practical example of applying these principles to a product, would be cross-functional requirements to articulate these to the team. Using stability, performance and security as our three focus areas across all stories.
This way of working has given us multiple benefits. For example, the multiple file upload for our data producers has been refined to perform within 10% of the theoretical best it could be. This meant that we could avoid the need for the local authority to compress files, and for us to decompress them. Additionally, this has simplified the security, as we only accept one type of file, and reduced the future maintenance burdens as the same code also manages a single file upload, and this reduces the complexity of the solution.
Focusing on performance allowed all of these valuable effects to also be delivered.
Just like the crocodile, we’ve focused on making sure NaPTAN masters its environment, taking the time to refactor and improve small pieces of code and prioritising cross-functional requirements to help it become the very best it can be at its unique job.
Build in efficiency. Make it beautiful in every way possible. Like a crocodile.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
