Many of you know that I started my career as a developer in the Israel Defence Forces (IDF). After winning a few battles just to get there, I got to participate in a prestigious and very intensive 6-months development training (AKA MAMRAM). Fewer people know that after I completed my own training (25 years ago today!) I was also an instructor in that program for a while before moving to the Israeli Air Force to build command and control systems for the years to come. 

MAMRAM’s development bootcamp is considered one of the best development training programs out there because it teaches so much more than coding. It teaches teamwork, dealing with real-world situations (I remember we had to deal with one of our team members accidentally deleting our entire code base just a few hours before we had to submit our final project), and most importantly, it encourages students to think and make sure they understand everything they do, not just do what their managers say.

I recently read about the history of the program and saw the roots of this unique approach from the very beginning. The first development bootcamp was in 1959, but there was a slight problem: IDF had no computers back then. The first computer arrived only in 1961 and was used primarily for operational purposes and less for training. It resulted in the students having to learn how to code on paper. Those of you who studied computer science long enough ago might remember submitting one or two pages of hand-written code as course assignments. But in MAMRAM they focused on much more complex code, teaching the students to write entire systems. Doing that without an actual computer to run on, required the students to acquire very interesting skills, for example debugging their code on paper. Since computing resources were non-existent to rare in the first years, students knew that once running their code had to be of great quality, since who knows when the next opportunity to run it again would be. They debugged their code on paper, multiple times, before it actually ran for the first time. 

In some ways, this approach is obsolete. It is probably much easier today to simply run the code and see if it works (at least for the simple and happy path). For example, the impact of having an infinite loop these days would mean that your program would be stuck and you will stop it. Back then, the impact was boxes and boxes of punched cards, and endless compilation time on the single computer everyone had to share.

But in other cases, this approach of looking at things thoroughly and understanding why they need to work before you actually try them out is still relevant and very important for developers as well as product people. 

Today I want to focus on one such aspect that is critical for you as a product leader to debug “on paper”, simply because other ways won’t really work. I’m talking about strategic product bugs. Ones that mean that something is fundamentally problematic in your strategy, which means no matter how much you continue to solve for better functionality, success is unlikely to come. If you don’t debug these “on paper” you most likely won’t deal with them at all, because you can always improve this feature or another and see some minor improvement, so you might think you are working on the right things.

Here are a few examples of popular strategic product bugs to be aware of. 

Identifying That You Have These Bugs

The symptoms you see for all of these bugs might be the same. It is usually when things work, but not getting on a roll business-wise. You have users and even happy customers, but the next level of success is yet to come. You work very hard to succeed further, but results are stagnant or linear and not exponential as you would expect.

That’s the most dangerous situation since if things don’t work at all you immediately know that you have a problem. But when things somewhat work, it is very tempting to think that if you simply persist along the route you already started things will be just fine. It is also tempting to think that the problem is not with the product, but rather with marketing or sales that are unable to bring customers fast enough. In my experience that’s rarely the problem. Marketing and sales need guidance about the product strategy and unique value proposition in order to be able to do their magic. They will always continue to do their best and would rarely raise a flag that they don’t know what to do, so it’s on you to make sure they have what they need to succeed.

If you feel stuck, check to see if you have these bugs one after the other. Start with the first, make sure you are fine there (or fix what needs fixing), and only then move on to the next one.

Not Solving Acute Pain

People love it when you solve their problems, and in some aspects even solving a minor problem is better for them than solving none. But solving minor problems cannot lead you to business success – they either won’t pay for it or won’t pay the amounts that you need them to pay. The problem you are solving for them needs to be painful enough so that they will go through the entire process of buying your product, onboarding, and becoming effective, regular users of it. 

To make sure the problem you are solving is indeed an important enough one, you need to start by assuming that it isn’t. Instead of trying to convince potential customers that they have the problem, or in other words trying to find evidence that what you already think is correct, challenge yourself to see it from their point of view, and play devil’s advocate. It’s almost like you need them to convince you that you are working on a problem that is important enough to them. 

When you interview potential customers seek to see how much effort they put into solving this problem today. The more effort they put into it, the more important it is for them to actually solve it. Remember that effort can come in many forms – internal processes, workarounds with existing tools, testing multiple options, and others. Next, see what’s missing in the current alternatives that they have. Remember that even if the original problem was really painful, but the current solutions they have are solving most of the pain, they are less likely to buy anything else. So your benchmark isn’t people having no solution, but rather whatever solution they have or think of using today. 

Customers Can’t or Won’t Pay

Sometimes the problem is indeed important, but they can’t afford your solution. In other cases, especially in B2B, it could be that the people whose problem you are solving indeed see the value, but they don’t have the budget for it or are unable to convince the other stakeholders that it is important enough.

With B2B, you need to make sure that each and every one of the stakeholders involved in the buying decision sees the value of your product. In many cases it will be a different value for different stakeholders, so make sure you interview each persona separately and see each and every one of them as if they were the primary ones that you need to convince (which means providing significant value for each).

To know if you even have a chance, ask potential customers about their purchase process in general, not just for similar products. For example, ask what is the most expensive product they bought (and how much they paid for it), as well as what did it take to get it approved. Remember that you are not looking for bottom-line answers only, it’s the details and nuances that help you to really understand your customers’ world.

TAM Is Not Large Enough

This is one of the most frustrating strategic bugs. You solve a real problem for real people who are willing to pay for it. After having put a lot of effort into it, they are happy customers. It seems like you were doing all the right things, but the hockey stick growth isn’t coming. You might be putting a lot of money into marketing and a lot of effort into sales, and still, it doesn’t work. Selling to additional customers feels like a struggle, instead of becoming easier over time.

The root cause for this could be that your market size (Total Addressable Market, AKA TAM) isn’t as large as you thought it was. It could be that you never thought about it properly, but if you made some calculations early on, most likely some of your assumptions weren’t right after all.

It could be that people aren’t willing to pay as much as you want or need them to pay in order for the product to be considered successful. Going through the previous strategic bugs mentioned here can help you understand if that’s the case. But in many cases, it doesn’t explain all of it and the real problem lies elsewhere.

The really important market size requires a very detailed understanding of your real target audience – the customer profiles who are most likely to buy your product and become happy retained customers. This profiling needs to be done in detail and goes far beyond the characteristics that you can easily segment the market by. For example, if you are in cybersecurity, and sell to Chief Information Security Officers (CISOs), you might need a specific profile of CISO to relate to your product. Say, one that comes from a tech background rather than from an auditing background. That’s not a statistic that you will find anywhere, at least not easily. And that’s just one parameter. 

Don’t let the fact that it’s hard to let you down. First, start by understanding in detail your ideal customer profile. Then, build a model with many assumptions and estimations to understand what you can expect. In many cases, merely by building the model, you will understand where the problem is and whether it is significant enough to pivot in a different direction.

Remember, none of these bugs are blockers. You can keep working and see gradual improvement over time. But as explained here, it is unlikely to get you to where you really want to be, so it is on you to raise a flag and see – proactively – if you have a bigger problem that needs to be addressed. There are many ways to meet the market and get feedback, not just delivering new versions of the product. Make sure you use them the right way.