Innovation as a Collision of Perspective Frames

(I will be writing a series of articles as a way to close my time at GovTech. If you're interested, do follow my writing and give it a like - share, if you think it's worth a share. I've learnt so much from product teams, I find it hard to remain silent. So here's my first shot at giving back.)

If there is one topic that has seized tech agencies operating in the Singapore public service nexus (think GovTech, Open Government Products, or even Synapxe), surely it must be that of innovation. Speak to any senior executives, and they will likely list it as a major concern alongside the key goal of continuing to improve on core services. It's not a surprising outcome, given the onslaught of new technologies year-on-year, such as Artificial Intelligence, Web 3.0 and more recently, Generative Artificial Intelligence. Given the rate of development, tech has been shaped to become a primarily expansive industry, and I believe many leaders are already looking towards the next bound of Artificial Intelligence agents, Computer Vision models, edge computing and perhaps even quantum computing.

What is Innovation?

What then is innovation in the tech sector? Is it merely a pursuit of the latest technologies, and the endless incorporation of new tech into existing products - but surely that puts us at risk of overengineering? Is it simply generating a new revenue line - but how does one reconcile that with the public service business model where revenue generation is not the key focus of our service? Is it just business process transformation where tech plays an enabler role - but other than efficiency-led productivity, what exactly have we helped to do differently?

In basic Design Thinking and product management programmes, we know that innovation isn't just about incorporating new technology or generating new revenue lines. Sure, an innovation should be revenue-generating if possible - but that's only when you want to turn the product of innovation into part of your core business. If you think about it, I'm sure there're many times you've seen something in your organisation where you remarked, "Hey, that's really quite innovative!" but it was not quite revenue-generating in any way at all.

If you're a technology evangelist, maybe you might think innovation should seek to incorporate new tech where relevant - more if you're in the business of tech, usually new tech doesn't quite allow you to do new things, it just allows you to do old things better, faster, cheaper. Surely there have been many times when you look at the design of a water-bottle, or a simple bag and go, "That's really quite an innovative design!" when there was really no rocket science behind it all.

So what is innovation? At the heart of it, an innovation comes about when ideas from one discipline, sector or domain are implemented within another discipline, sector or domain, that results in something useful that humans need.

So you're kind of right when you say that innovation is "something new", but if you break it down a little bit more, that sense of "something new" derives from the collision of two different perspective frames, and the greater the difference between the two frames, the larger this intellectual collision and thus the greater the perception of innovation. And you're also kind of right to say that an innovation should be somewhat revenue-generating, but that's only true in so far as money is an exchange of value, where people spending money on your innovation is a sign that they need what you've come up with.

This definition helps us to also understand why we commonly refer to innovations as either being incremental or transformative. For those uninitiated, incremental innovation refers to innovation where you're just doing something that's a better version of something that already exists. For example, if you create a digital textbook, that's incremental innovation because well, you're just making a (presumably) better textbook. Transformative innovation refers to innovation where you meet the needs of your users through an entirely new mechanism - for example, maybe the underlying reason why you needed a textbook was because students require a way to learn better, and you now choose to meet that need by creating some kind of online learning community platform that put students in touch with peer experts. Using that collision analogy again, you'll often find that incremental innovation arises when the collision of perspective frames is small, and transformative innovation arises when there's a huge collision of perspective frames.

It's important to understand this fundamental definition of innovation so that you can begin to elucidate the activities of innovation, so as to pursue it in your organisations.

How Does One Innovate?

Here at GovTech, we read a lot of literature from design schools and entrepreneurs. Pick up any book by die-hard entrepreneurs (think Daniel Priestly) or go for any course in product management (think Stanford School of Engineering or d.school), and the number one thing that is taught to bring innovation into your organisation is to drastically increase the number of ideas that are generated.

There really is no secret to innovation other than to have lots of ideas, iterate through all of them (if time and resourcing permits), and then to find those few (or even one) things that people really need. From this maxim, we derive our motherhoody statements of "do fast, fail fast, learn fast", or your design thinking frames like "diverge, then converge". All of these are derivative from that fundamental fact of innovation, which is that you need this huge generation of ideas before you can even land on an innovation.

Most research actually shows that at the level of an organisation, you actually need an order of magnitude of about a thousand new ideas, before you can even land on a commercially viable product. Think about that! How many ideas do organisations dream up, and how big a failure rate do we accept? There's a reason why tech companies invest in hackathons - because that level of idea generation is so fundamental to innovation, that if you don't have a huge base, you simply cannot hope to land on an innovation.

Once you understand that this is the critical ingredient for innovation, you begin to see why design thinking as a discipline teaches you certain things about generating ideas.

For instance, we are taught that we should never bring the solution into the problem statement. Why? Because that limits our vision, to focus only on a certain hypothesis or theory of change - if we start out our product workshops by saying "how do we create a better grants portal for Singapore businesses", we'll most definitely just create a better business grants portal.

We've heard so much about diversity of teams and non-stop conversations with users as being key ingredients of culture. Product managers always say, if you're not out there speaking to your users all the time, your product isn't going to be much of an innovation. Engineering leads always tell us that the best creation comes from that creative tension held between users, product manager, engineers and UX designers. But that's because innovation is about the collision of perspective frames - the more people you talk to, the greater number of such collisions; and the more diverse your team, the greater the collision you will achieve.

Which all translates into that huge repository of ideas you require for innovation.

(there's a side point I would really like to make about Generative AI being good for ideation, but not so much for solutioning, because of its rapid prototyping capability - but that's another article for another time)

So We Just Generate? And Then Do All of Them?

Indeed, you should probably (and any design thinking maximalist will likely agree) seek to maximise quantity over quality of ideas.

But picking which idea to bring to market is an entirely different game.

We live in a world where your organisation's resources are finite, and your bosses' patience is incredibly more finite. Pursuing innovation therefore requires some art behind it. That's why you hear organisational leaders talking about "creating the right conditions for failure" - given that you require a high failure rate, you can't afford to have each failure being too expensive. Again software engineers would tell you about creating "prototypes", even to the extent of "no-fidelity" prototypes where maybe you just act out the product to your potential customers. Even marketing managers tell you to create pamphlets and brochures, to test market demand. That's why entrepreneurs talk about creating "oversubscription" - it's another way of idea validation before you double-down on a smart idea.

Exploring these tricks of the trade will probably be a post for another time. I hope to next write about the activities of innovation at high-level, which will hopefully help us understand the different stages of innovation we often find ourselves in, in our respective organisations.