Do you make ‘things’? You probably do. So do we — things are brilliant. Okay, you and I are a bit more sophisticated than that; we don’t call them things - not us - we know them as services, products, systems! We get the complexities of integrating platforms and prototyping user flows. The word ‘things’ doesn’t really cut it — these products can’t be dropped into an organisation as neat, self-contained packages. They have to be wired into the existing business or service. They are not islands, they are an extension of the organisation itself...

In situations like this, technical feasibility is a matter not only of ensuring the product in question can be built, but that it can be elegantly integrated it into existing systems. No one would argue with the importance of this. I’ve never been in a meeting where someone has said “Hey! Enough with the feasibility talk - does it really matter if we can integrate this into our product or not?”

But something strange happens when the conversation turns to integrating a product into a company’s ‘human systems’. How will the product will be adopted culturally and politically? Are employees likely to embrace it? How will it be run? How will it support or conflict with the work and ambitions of internal product teams and IT? Are they for it or against it? 

In other words, is it operationally feasible? 

This is a perfectly valid line of questioning, but somehow it usually doesn’t feel like it’s our business. It’s political and sticky. Indeed, a client might feel they need tangible, advanced progress in order to get support internally. But every day spent working on something in isolation of the wider ecosystem is a risk. 

Operational feasibility is as important as technical feasibility (or any other kind of feasibility for that matter), and yet it can be the first thing to get brushed under the carpet. The conversation changes and that ‘intelligent system’ everyone was discussing is transformed back into a mere ‘thing’: a deliverable to drop into the organisation. We’ll find out later if we can make it happen; if we can weave it into departments and hearts as successfully as we can plug it into software platforms. 

Working Lean means minimising waste. And operational feasibility should surely be fed into product development cycles like any other critical component.

We sometimes manage to do this. Take our redesign of the ITV news service. Delivering news in smaller, faster fragments required rethinking not just the website, but the content management system used by ITV journalists. In the words of our case study, we “prototyped the workflow, not just the product, shadowing the news team at ITV for a day every week and creating the content in real-time as they would have to.” Makes total sense - and it’s supported by the words of Andrew Sprinz, who worked on the project (I just emailed him to see if this post made me sound like an idiot, but thankfully he concurred):

“We were, ultimately, trying to transform the way people consumed news, but in order to do so, we had to transform the way the business worked: operational feasibility was as vital as user testing.”

With ITV, there was an unignorable link between product and staff. It’s not always that clear-cut, but really this link exists wherever the success of a product depends on the organisation’s ability to implement it. It’s another human layer of the system, as intrinsic to success as user adoption.

As client relationships become more like partnerships, perhaps the next step is to share the burden of politics more equally, and make operational feasibility a core part of the iterative development cycles. Easy to say, less easy to pull off. But surely a goal worth pursuing.