Being product-led and the scientific method

Since joining NHS England about six eight months ago, one of the topics that has come up repeatedly is being product-led. To be agile, rather than waterfall. To avoid being “programmatic”.

This conversation came up very little during the first twenty years of my career. To some extent this was because we had no historical way of working, and so the “newer method” was therefore the default option. And to some extent this was a result of our financial position. Whether we were bootstrapped (VoucherCodes) or venture financed (Hoop) we aimed to ship small and ship often because the money was always running out and you didn’t know if you’re next idea was going to work or not.

The funding in government is very different, and I am not yet experienced enough to say with any confidence (although I have my suspicions) that the funding has affected the way we choose to build things. What is evident, however, is that historically things have been built in a “programmatic” style: big specs, long delivery cycles, solutions and not outcomes.

And so we talk about the need for, and value of, being agile. A lot. Indeed, this was at topic of a recent round table I took part in for Government Services week: Being product-led in a non-product world.

The opportunity to reflect on this topic reminded me that many of the “new” stories we tell are simply repackaged versions of old ones. And that finding an older, possibly more universal, reference point can be a great way to help people understand what this seemingly new thing is all about. Recasting something in an older form can also help convince skeptics, many people have an anti-new bias.

To that end, I argue that being product-led is not that new. The terminology might be, but the idea of: gathering some data to take an educated guess about what some change might result in; creating the conditions for testing your idea; observing the effect; analysing the data; and, ideally, keeping all this work quite narrow in scope, could have been written in the 1700s. It is inductive reasoning, cause and effect and scientific publishing, ideas that that we now collectively call the scientific method. The environment digital folk work in might be a socio-technical one, made of people interacting with 1s and 0s, rather than the domain of natural sciences, but the principles are the same.

I have found this explanation to be particularly useful given that I am now surrounded by clinical staff, public health researchers and others with background in the sciences. It helps them understand how I like to work, how I think all the product teams should work, and why it’s not that different to the way science has operated for hundreds of years.