Calculated Innovation

“The only way of discovering the limits of the possible is to venture a little way past them into the impossible.” - Arthur C Clarke

I create valuable, user-centred products filled with magical algorithms, quickly.

For the last twenty-five years, starting in my mid-teens, I’ve been a software developer, team leader, and technology consultant. I’ve travelled through the worlds of ultra-violet spectroradiometry, safety-critical automotive systems and offshore renewable energy installation. I was there writing cutting-edge imaging algorithms for the first HD mobile phone into the US, and I’ve spent the last four years providing technology leadership and mentoring to over 60 entrepreneurial teams aiming to get new companies off the ground.

So, back to today. Let’s unpack that starting phrase, shall we?

I create … products

At my heart, I am a maker. I am never content with simply pontificating in meetings. I don’t like sitting around.

If you don’t want someone to actually help make something, then I’m probably not your guy. Unless you’re going to pay me so much that I can then go off and make my own stuff the rest of the time.

Don’t get me wrong, I like people a lot. I just hate pointless meetings, and going around in circles.

Let’s get what we all know out of the way: The majority of innovations fail. And if you’re a start-up, then the vast majority of start-ups fail.

According to CB Insights, the top reason that startups fail is that there is no market need. Another way to put that is that they are not working on a valuable problem. I won’t work on value-less problems.

Before we start work on any products, I’ll want to know:

  1. What is the problem/want?
  2. Do people actually want this to be fixed?
  3. How do you know?
  4. Are people willing to pay for it to be fixed?

If you don’t know the answers to those questions, then we can work on them together, but let’s do it through action, not chat. Let’s find the people, let’s run some MVP tests, let’s try and get some people to actually part with some cash.

Today’s market is saturated with products. And so, if yours is more bothered about itself than the customers it is supposed to serve, then those customers will go elsewhere.

So, at every stage of development, I ask the questions:

  1. What do end users think about this product?
  2. If they are different, what do the paying customers say about this product?
  3. How can we make their lives easier, or richer?
  4. How can we make this product less obtrusive in their lives?

Getting genuine answers to those questions can be hard, but we have to try. And we have to succeed. Because otherwise we’ll make a
wifi juicer. And no-one wants that.

So, there are loads of valuable things being made, apps that need to be made, and business models that can be innovated.

My sweet spot is making stuff that seems a little bit magical, or is so full of magic that you don’t even notice. Like making [mobile phones eliminate purple fringing, have excellent but natural resolution, and natural-looking noise reduction] (https://www.gsmarena.com/nokia_n8-review-523p6.php). Or putting sophisticated routing and scheduling algorithms behind a user interface that complete non-techies can use (I designed the tail too, quite pleased with that one!).

If your problem needs powering with some complex algorithms, I’ll happily dive in.

Finally, speed. If you’re innovating, you need to try stuff, test it with users, and iterate. Iterate, iterate, iterate. It’s no good if you’re stuck waiting for months for some technical problem to be fixed.

How I work quickly?

  1. Experience. I know where to look for solutions. I’ve got a nose for what looks like a dead-end, and what looks plausible. Is that apparently great solution mature enough, and what will it take to get it to the level of maturity we need?
  2. Humility I am never afraid to admit that we’ve gone the wrong way, and need to take a different route. Constant, lightweight evaluation of “is this taking the right amount of time?” ensures that we are not going down rabbit holes.
  3. Reuse. If a problem hasn’t been directly solved before, then something like it has been. Or it can be broken down, and some or all of the components have been. We’ll break down the problem into the constituent parts, and we’ll solve each one a piece at a time.
  4. Quality. I ensure that everything we do is reproducable, testable, and tested. In software development, increasing quality mostly increases speed in the medium term.