One of the coolest things I get to do in a director level role at a software company is meet a lot of different people outside my organization. I get to converse some of the most experienced, intelligent people in our broader industry and getting some incredible nuggets of wisdom.

Earlier this week, I met with a tech consultancy here in Charlotte to talk about some sophisticated data management strategies and techniques. During our discussion, one of their team members sitting off in a corner made a statement so profound to me that I decided to write an article about it.

Strategy Debt is way more expensive to fix than Tech Debt.

I mean, whoa...

Have you ever heard something that you kind of knew intuitively but it didn't really hit you until you heard it phrased that way? This was one of those moments for me. Product Strategy is my job, and yet it somehow hadn't occurred to me to think of strategy decisions using the same frameworks that we think of tech decisions.

Tech Debt

If you haven't heard of the term "Tech Debt" before, it's a common way to describe shortcuts or compromises taken in the software development process. Every piece of software you have ever used has tech debt.

For example, let's say you're building a new product feature to wow a new prospective client that could open the door to a new market segment for your product. The potential customer asks you to show them this feature in just a couple weeks time. Not wanting to miss the opportunity, you ask your developers to get it out the door faster than what it would normally take to build. They of course agree to do their best to hit the deadline, but in the process they take shortcuts. Maybe they hard coded some variables, or wrote really fast, ugly code that doesn't make sense to anyone who has to read it later. The point is, is it wasn't really done the "right" way.

The reason we describe this phenomenon as "debt" is because it functions exactly in that way. You've borrowed from the future in order to get something done today. At some point, that debt is going to have to be paid. A library upgrade makes a breaking change to your implementation, or some other new feature that builds on the one you made in haste requires some refactoring of the first to make the second.

You can think of the types of tech debt as have an interest rate, just like with CRE debt. Some debt has a low, or even a zero percent interest rate, while other debt has really high interest rates that have to be paid off eventually before it puts you under.

Having tech debt isn't bad, just like debt in real life. It's all about using it intelligently and making sure you keep your interest expense down.

Strategy Debt

Strategy debt is really no different, but the interest rates are a lot higher.

Think about it. When you set a strategy in motion, everything that moves to support that strategy is built alongside it. Your company is going to set up operations to support the strategy. Your product and tech teams are going to design software to support this strategy.

Bad strategy decisions are expensive. Even if everything is executed flawlessly, changing the strategy means unwinding everything downstream from it. Bad strategy means you're moving forward burning cash to build up infrastructure to move you in the wrong direction. If you don't recognize the bad strategy in time, you could end up with a flop from what could have been a promising product.

Ambiguity

Broad objectives with no clear direction or appreciation of nuance are usually unsuccessful. If there's no buy-in from your leadership team or real consensus on what your objective is, you're leaving a door open for each stakeholder to make their own interpretation of what needs to be done.

I've become a proponent of a concept called a value pyramid. How does our platform build layers of value? How can we continue leveraging value as we hop from one feature to the next? If you cannot answer those questions with specificity, then we have too much ambiguity in our strategy.

You also have to know where you're starting from. Ambiguity sometimes comes from a lack of understanding your starting point, not a lack of knowing where you want to go. If you don't know where you're starting from, you're going to waster countless man hours and resources floundering for a foothold (anybody remember the Fire Phone?).

Value Drivers

It's absolutely critical to understand your target customers and how you drive value for them. You have to know what that core competency is that you are the best at and how that creates value for a target customer.

Your target market isn't aspirational, it comes from extensive research and testing to discover your target customer and what they care about. Your target customer isn't "everybody", or for B2B companies like mine, "everybody in XYZ industry". There's a specific type of customer with a specific problem, or set of problems, that your product can solve.

Not Making Hard Choices

This is a big one. You can't be all things to all people. You have to make hard choices about what your core competencies are and who you're going to create value for. Avoiding the hard choices inevitably ends with a team trying to support conflicting demands. You have to choose.

This often stems from the idea that adding more and more features, you will automatically create more value out of thin air. Instead, you have to make decisions about what value you can create and then decide whether you can create features off of that.

Bad Strategy Will Happen

Bad strategy can and will happen to every company. Even wildly successful companies have their faceplant moments (a la Apple's Newton, or more than 280 products killed by Google). Just apply a little sanity testing and be aware of where your strategy missteps can come from. There's a lot of resources out there to help.

If you liked this article, consider following me and subscribing to email updates whenever I post an article. You can also follow me on Twitter or connect with me on LinkedIn.