Low Tech De-Risking (Taste the Food First!)

Let's imagine you're opening a restaurant. You dream of being the hardest-to-snag dinner reservation on the block.

A friend calls and says, "You have to hire Alfredo as Head Chef. His cooking is sublime."

Would you: A) Meet Alfredo, get to know him, look at his resume, and taste his famous pasta or B) Hire Alfredo as your Head Chef right away?

The success of your restaurant hinges upon this decision! So obviously you'd go with option A. But throughout my career in software development, I've seen leaders "hire Alfredo" sight unseen again and again.

Let me explain.

In a previous role, an executive came to me with an innovative idea to increase key KPIs with new technology workflows. He was ready to dedicate 3 months of our product roadmap to making the dream a reality.

I considered one week of my team's time to cost about $20,000, and that's before considering the opportunity cost of having them focus on this project instead of other valuable known-quantity projects. This project would cost a minimum of $120,000– a huge investment for an unknown ROI.

I suggested that before jumping into the project, we should try to test some of the riskiest assumptions with no-code processes. The cheapest, fastest way to learn whether our features would work was to change our services workflows to adopt them without the supporting workflow technology.

So how would we test? Someone needed to train our Services team to offer alternatives when an original customer request couldn't be accommodated. We then needed to measure how often the client took the alternative, and thus captured additional revenue. Conversations could be tracked and recorded in Airtable. The cost of this approach was a bit of Airtable configuration and training time. The outcome would be evidence our development time would be worth it.

So what happened? He didn't want to initiate the test or wait for the results. He wanted to "hire Alfredo"– a $120,000 bet.

We started Stradia Partners to help people approach problems like this differently– even if it means less money for us.

Our process would look something like this:

1. Start by calculating the size of the bet you're making with development. What will it cost to build in time, money, and opportunity?
   1. For my example, the cost is $120,000 of development time + opportunity cost of not working on previously validated roadmap projects.
2. Identify the things that need to be true for the bet to pay off (risks). List them.
   1. In my example, the bet would pay off if customers were willing to take alternative options and the revenue gained from those sales was more than the cost of development, maintenance, training and adoption.
3. See if you can de-risk the bet prior to making it. This is known as a Riskiest Assumption Test (RAT).
   1. If customers will take the alternative over the phone or email, then it's likely they'd take it in an app (bet = validated).
   2. If customers don't take the alternative over the phone or email, then it's even less likely they'd take it in the app (bet = invalidated).
4. Run the test (taste the food); measure.
5. Use the test results to evaluate whether there's a case for the bet to pay for the cost calculated in step 1. If so, make the bet (hire Alfredo).

Want help tasting the food and deciding whether to hire Alfredo? We're in your corner; shoot us a note.

Bon Appétit!