Technical Risk vs Market Risk

As a developer, most of the conversations about project risk I have with coworkers, bosses, and clients tend to revolve around technical risk. On the projects I work on, technical risk generally refers to risks associated with delivering a programmed product. Typically, the most common technical risk I encounter as a full stack web developer is the risk that the project will not be developed in time, or for an appropriate budget.

However, some projects can be significantly higher risk than that – even to the point that it is unclear if a technical implementation is feasible on the project as conceived. For instance, projects that involve "machine learning" or types of artificial intelligence tend to be higher risk because of the uncertainties with performance around current AI implementations, as are projects with hardware components because of the higher cost of hardware development compared to software development.

Typically, the way you want to mitigate technical risk is to work on the highest risk areas first, because if the higher risk areas cannot be implanted, you will not have wasted your time on other features. For example, if I was working on a web app whose primary value was to use a trained neural network to identify construction workers on a site, I would likely want to build a stripped down prototype with just the neural network to make sure it was performing well enough to provide the value expected. I wouldn't want to spend time on lower risk features, like say login and user profile management, until I was fairly certain that the higher risk area was performing well enough to be relied on.

If the high risk area fails to perform (in this example, the neural network) you want to maintain the most flexibility to change things moving forward – both in terms of budget preservation, and preventing technical inertia (aka, the tendency to live with suboptimal technical decisions because of the effort involved reverting unwanted features.) However, one issue you can run into, is that the efforts you put in mitigating your technical risk can actually cause you to take on more market risk.

Market risk is, essentially, the risk that people will not want to use your product so you will not have a market for it. I've observed, often people seem reluctant to discuss market risk openly. Possibly it's just because I'm a developer and they're having these types of conversations with their marketing teams, but I also suspect that people are actually more intimidated by market risk than they are by technical risk.

Simply stated, very few startups hit solid product market fit right out the gate. Usually, if you're lucky, you get partial product market fit and then have to iterate on your product a few times to get it right. If you're unlucky... well, it could be absolute crickets on release. There is a slightly inescapable element of randomness to what people like; you can make reasonable guesses about what may be popular, or what may take off, but you can never be 100% sure. Additionally, if a product isn't performing, there can be multiple reasons for market failure that can be hard to pinpoint. It could be that the sales and marketing component isn't working, it could be that the concept is high value but the implementation is poor, or it could be that the initial idea is simply not valuable enough to attract an audience. When you are in the throes of an under-performing product, it can be hard to differentiate these problems from each other, and often people want to avoid thinking about this complexity because it's unsettling.

After all, it's unnerving that a project you put so much time and energy into could fail based on the fickle opinions of strangers; unfortunately, that's just the reality of the situation. Often, I find, people choose to focus on technical risk over market risk because it's easier to evaluate; either something is functioning adequately, or it's not – there tend to be highly defined parameters in that arena.

In pure software, however, I see more projects fail due to improperly mitigated market risk, not technical risk (Theranos, by contrast, was an example of a company failing due to improperly mitigated technical risk – but of course, it wasn't a software startup.) This happens, generally, because people try to have a large release of a fairly polished product rather than getting feedback from their audience early. The longer you wait to release a product to the public, the more market risk you take on, because the more time, energy, and money you have invested before finding out if people actually want to buy your product.

Now, unfortunately, strategies to mitigate technical risk and market risk often end up opposing each other; when mitigating technical risk, it is often advisable to build a stripped down semi-functional product which only tests the the most uncertain areas of the technology stack. However, to mitigate market risk, you want to get things in front of customers as soon as possible so you can pivot quickly if needed. But, to get something in front of people, you will need something that is at least usable to a general audience, and often technical prototypes are not usable for anyone who isn't the engineer who made it.

It is here that you have to think holistically about your product because you need to devote time to the area where the absolute risk is higher. If you're doing something that is technically very challenging but you have good evidence of a market, you should likely devote more time to mitigating the technical risk first. However, if you still have a lot of uncertainty about the market that you're diving into, then you really want to be devoting time to getting something to market ASAP so you can iterate on it. And, unfortunately, I think there is a tendency for people to be overly optimistic about how good their market fit is; so if in doubt, I think it's good to err on the side of a little pessimism around the market fit.

Because, at the end of the day, if you've got an excited following of people who want your product, you actually have a lot to work with. You can interview potential users, experiment with new features, potentially get funding (or more funding) if you need it, and things like that. If you have a perfectly implemented masterpiece with no users, you functionally have nothing. Harsh though it may be, I have seen scores of projects fail because they had no users. The only time I've seen a project fail for purely technical reasons was when I was watching The Dropout. Yes, technical failure is a real risk (and, higher risk in some areas than others) but I would argue it is a generally well understood risk for seasoned engineers. Market risk, however, is a silent killer that takes down startups before they even know what hit them.