In this multi-part series, we discuss how to mitigate your risks in developing new software, while making more progress in less time.
Anyone who wants to launch a new product or service built on custom software faces a great deal of uncertainty. No matter how well prepared you are, or how thorough your business case is, it’s hard to design, build and launch new software. You need to make decisions and take action even when you don’t have all the answers in advance.
Will your customers buy it? Will it have the desired effect? Will it integrate smoothly with your legacy infrastructure? Can you launch on time? Uncertainty comes with the territory.
But being uncertain doesn’t mean you can’t mitigate risks. Launching new software products and services requires managing uncertainty along the way, to keep your project on track, no matter what.
Building Custom Software is an Exercise in Risk Management
The most common mistake inexperienced product owners make is taking risk for granted, as if risk is a feature inherent in anything new.
Hey, we’re smart people, we know this will work… Doing something is always better than doing nothing… You gotta spend money to make money… We move fast and break things!
Honestly, we love these sentiments. It takes a special kind of attitude to think you can create something no one has done before– to defy the odds that your endeavor will be successful, when most are not.
Unfortunately, confidence doesn’t make a risk worth taking, nor does it pay the bills when your project is out of money. Grit and determination can only make you successful if you are also willing to prove every one of your assumptions right or wrong.
1. Recognize What You Don’t Know
Whether you’ve founded a startup or are leading an enterprise-level project at a Fortune 500 company, chances are, you really like the idea that spawned your new software project. And you should. The temptation then is to dive in and build the solution. Not so fast.
We are regularly asked to help build software prototypes or MVPs (minimum viable products) and more than half the time we say No. To be clear, we don’t usually reject clients out of hand. Rather, we ask a lot of questions.
We want to know which ideas are validated with evidence and which ones are still untested assumptions. We want to understand the problem they’re trying to solve, so that the software we build is truly useful to their target users. We want to create solutions that help a project live longer and grow.
While you might be sure of your big idea, and it really seems like a “no-brainer,” more than likely, you don’t yet know what you don’t know. This is not just a startup problem; corporate teams struggle with the same things. Internal projects at large organizations fail at about the same rate as startups, but they sure don’t have to.
2. Put a Price Tag on Your Uncertainty
One recent client who came to us for a prototype was confident and eager to get started. He’d solved his own problem using mostly free online tools and had received positive feedback from peers about his approach. He was convinced it was time to build a shiny new prototype.
However, when learning that the prototype he envisioned would cost about $50,000 to develop, he was less inclined to proceed. The price tag was more than he had planned, but that wasn’t the real sticking point. What if the prototype didn’t get users and investors excited? What if he was wrong about whether users really cared about solving the problem in the way he imagined?
He has many assumptions to test, and we’re going to help him do that, so he can decide what (if anything) he should build. He wasn’t willing to bet $50,000 to prove he’s right about his ideas, but he is willing to bet several weeks of hard work, at a small fraction of the price. Smart move.
Of course, risk applies to any kind of spending, not just building software. AirBnB didn’t hire an employee until 4 months after they were funded. Instead, they kept their burn rate low and learned as much as they could so they felt certain investing in a new employee was a good bet to make.
When you spend time or money on an idea, you are betting that investment will pay off. Because your outcomes are uncertain, it’s irresponsible to blow your budget on one big bet. Place smaller bets you can afford to lose, so you can live (and learn and adapt) another day.
3. Plan to Adapt Quickly
State-of-the-art innovation practices like Lean Startup, business model canvas, customer discovery, outcome-driven innovation and design thinking techniques (among many others) all help to uncover and validate or invalidate insights and assumptions, even before a single line of code is written.
If you don’t plan to adapt, you will likely waste a lot of money on code that could be better spent on learning. This is the essence of the “fail fast” mentality.
According to Astro Teller, CEO and Captain of Moonshots at Google X, failing fast isn’t failing at all– it’s accelerated learning. To resist learning and replace it with lots of planning and activity means you’re hiding from an inevitable truth, and risking more in the process. A couple more weeks uncovering mistaken assumptions could save months of development costs, and could save your entire project.
4. Plan Your Exits
Will you IPO your startup then buy a private island? Get a huge bonus and a promotion?
While those are the kinds of exits many entrepreneurs and innovators dream about, it’s more useful to think about what would make you stop working on your project, or a specific feature set, or marketing tactic or business model. I’m talking about “strategic quitting.”
Let’s say you have an idea and you conduct five user interviews. No one seems to care about the problem you want to solve. You realize your big idea wasn’t one at all. What was lost? Five coffee meetings and a few hours. Maybe that’s your exit.
Or you meet up with your boss to talk about a new project. Turns out it won’t fly because the company is implementing a new ERP and your idea only applies to the old one. Now all you risked was one meeting. Big deal.
Having “exit criteria” for any portion of your project helps you compartmentalize risk by preparing yourself to stop. It could be a learning goal, a budget line item or a time limit. Of course, exiting a stage doesn’t mean you were wrong. You may have gathered enough evidence to validate an idea and move on. At some point, reinforcing what you know becomes wasteful, too, and it’s time to execute: get that new feature live!
Finding the Risk-Reward Balance
We are in the business of designing and developing great custom software. The impact we help our clients make by launching new digital solutions is what motivates us every day. So when a client comes to us, we want to know if they’re ready. We take care to ensure our work creates sustaining value, not lots of billable hours.
We just don’t think it’s good practice to design and develop software that isn’t in the best interest of the client’s company. Which is why the clients we work with find it helpful that we press them on their business case, the context in which they operate, and that their planned investment in software is justified.
Of course, risk takes different forms, from security and regulatory concerns to competitors and changing technology and customer needs. In subsequent articles, we’ll explore how deep user insights, agnostic technical planning and proactive project management help software development projects get and stay on the right track. Because great ideas don’t simply materialize– they take expert execution to become real.