Did you know that the development of new drugs has been unprofitable since 2005? (article, original study) I knew we were approaching that point, but I didn’t realise that we had already passed the threshold 13 years ago.
I have an insight which will completely disrupt (transform) the pharma industry. I have the background of working in two different domains in order to give credibility to my insight. And I have the ability, on a technical level, to execute on it.
How many of you have heard this pitch before? A scientist who is just so damn sure that his invention will change the world, we just have to change everyone’s behaviour in order to interact with it. An inventor who…. Well, you get the picture.
Product Design
We have a multitude of design-driven approaches to product development today. Books upon books are being written on the subject. Ultimately, there is no recipe which guarantees why some innovators will see their ideas or insights taking over the world and others will disappear without trace. But humans are expert pattern discerners – we’re not as good as Deep Networks at finding true statistical patterns, especially not in high-dimensional data – but we always discern patterns, even when they’re not necessarily there. It’s how our brains work.
My own process to see whether I can bring my insight to the world has largely been a combination of Hypothesis Driven Development and Design Thinking. I am not an expert in either process, but my understanding is that nobody is; there are just degrees of experience, which leads to personal takes and customisation. I first read about Hypothesis Driven Development when I used to read Daniel Tenner‘s blog on Swombat. Hypothesis driven development appeals to me as it’s a formalisation of aspects of my upbringing anyway. You setup hypotheses, order them in terms of relevance (a mix of importance and immediate tractability), then knock them down one-by-one.
I have both taught and used Agile development practices and I want to be clear that Hypothesis driven development is pretty much a rephrasing of the same thing. But I like the explicitness of the hypothesis in this approach. And also the removal of the process from software development. You can setup any business using these methods. These are all pretty much variations on a theme, I like them all, but you can read up on it on Daniels’ blog if you have a scientific background and the name appeals to you too.
Design Thinking is, as its name implies, an approach to design. But its use nowadays extends far beyond the worlds of aesthetic or product design. You can design any solution, even a completely invisible algorithmic one. It’s a way of approaching difficult problems, to make them more tangible and then tackle the solution space in a way which is congruent with your target customers (audience) and your own constraints.
I must admit that I came late to the table on Design Thinking. I thought it was something that my artistic friends did. It was. They raved about it. But I was exposed to SAPs approach to Design Thinking in a series of workshops taught as part of the McKinsey Digital Shapers competition in early 2018. During those workshops I was lucky enough to learn about the process from some of the original thinkers in this space; Niels Clausen-Stuck currently head of design at Zeiss, and Heike van Geel from SAP.
I’m used to jumping right in and building solutions. I’m a bit of an expert, in many things, and the cost of failure has never been that high in my life to date. But then, some of the things that I have built have had massive uptake (e.g. my Lactate Analysis software for sports science) while other projects have attracted only the most niche of audiences (I’m thinking of my Julia Users Berlin group here).
I typically analyse my progress on my different projects over time and I can probably tell you why some have succeeded and others failed. But this is a post-hoc rationalisation. And, in good scientific terms, it’s just not as statistically powerful to fit a hypothesis to the data after you’ve already had a peek at the data. You should set out your hypotheses in advance of performing the project and then analyse them, on the basis of the original hypotheses, afterwards.
Design Thinking allows me a framework for understanding the ideation, or problem discovery, phase which I have sometimes felt compelled to undergo and sometimes felt I didn’t have enough time to do and hence needed to skip, on former projects. It’s the bit where you talk to a lot of people, keeping your mind open, and then synthesise your results. The purpose of which is to figure out what the real problem you’re trying to solve is.
Having defined the problem, or at least the shape of the problem, you will have better metrics to refer back to when you begin to design the solution. That’s my merging of the two approaches. Of course, the Design Thinkers would say that I don’t need to merge the approaches Design Thinking contains everything that I need within it. But that’s their way of thinking and this is mine.
Disruption
Disruptive technologies, by their nature, are things which did not typically exist before. They often come from non-traditional players. They are initially underestimated by incumbents. And they change the entire playing field in an industry, upending existing hierarchies.
Having grown up online (I first used the Internet in 1989) I have been exposed to a number of waves of disruptive technologies. The introduction of computers has slowly, then all at once, completely transformed the world. The current fields most predicted as being ripe for disruption are banking and healthcare.
Now, I am working in drug development which is not the typical aspect of healthcare targeted for disruption. Remember, however, that I opened this article by telling you that drug development is no longer profitable. The actual degree of unprofitability is debatable and for another day. One blockbuster drug could change the statistics to a positive income. But let’s just say that the mean is around zero at this point. I am also going to leave my specific proposal (solution) for another day.
Today I really want to focus in on what it means to approach a problem of this magnitude with a potentially disruptive solution. Is it worth my while going ahead and attempting to build the solution that I have in my head? What if I need resources to do so? Can I justify those resources to investors or funding agencies? Am I even the right person to go ahead with this solution? And, most importantly, is the problem that I am addressing one that actually is begging for a solution today?
Engage in the Process
The existence of semi-structured product design processes is a luxury in my case. I could spend two years building a solution and still fail for a myriad of reasons.
Instead, I set aside a number of months and engage in a company building project in order to surround myself with what I consider to be the optimum structure to bring about this solution, if it’s actually what the world needs.
I looked at my own career position last year. I didn’t want to continue with academia unless I really was only one step away from a top-level academic position. I realised that I was two hops away from this position; largely due to a personal decision I made four years ago. And, for similar personal reasons, I wasn’t ready to go through those two hops; despite their feasibility.
I realised that I had an idea about how biology is done that is quite a contrarian view. I presented an opening gambit on my take on this in my article about Mathematics and Biology. I also realised that I am ready for quite a senior leadership position, but I am not so well suited to German corporate structures. So I set about evaluating my various hypotheses as quickly as possible, to iterate to a solution which would see me gainfully employed on something that I really value working on.
I ended up at a position where I realised that the only way I could build my solution, with a credible probability of success, was via a venture funded company. So I entered an incubator.
Now, I did this with an open mind. And this is very, very important. I did not, initially focus on my idea. I focused on process. The process insisted that I focus on my huge technical edge, which eventually led me back to something quite strongly resembling my original idea.
Fear kicked in quite early on in the incubation process. I was worried about walking away from structures which I have spent years depending on. But my friends talked me out of the illogicality of my position. My fallback plan was every bit as risky as the startup option, but without the upside potential.
We quickly began to validate my overall impressions of the drug design process and the need for new solutions. We’re still doing that, but we’ve ticked most of our boxes by now.
Throughout this process, I have managed to keep my cool by falling back on the structure provided by Design Thinking. We are very much in the Discover loop of the SAP diagram. I have some notions about what we need to prototype in the Design loop, and we are talking with potential partners with whom we can build such a prototype. But I most happy about the fact that we are in a process, to which I can point, and which also reassures those around us.
Ultimately, we may or may not be successful in building our business. We may succeed on the science and fail on the sales. I may have been wrong on the science, although that seems unlikely given the feedback we’ve gotten on that front. There are many aspects of execution on which we could fail. And, we may just be unlucky.
But in the meantime, the key to making progress is i) Process, ii) Team, iii) Dedication, iv) Delivery, and v) Honest Feedback Loops.
And I’m ok with all of that.