Finding product market fit is notoriously difficult, am I right? Also, water is wet, and pricing is hard. Anyway, I’ve written a bit on the problems of founding a new product, differentiating features from products, and iterating a product until it works. It’s hard when you’re with a team or working on your own. But what if your own organization is standing in the way of success?

This will be difficult to recognize, because no one sits down to the day’s meetings with blocking organizational success as their plan. In fact, the entire framing of this post in conflict and war metaphors is cause for questioning organizational health as well as your own health. If “my company is blocking my team from success” resonates, maybe check out therapy, and then think about what kind of team you are in. After establishing that’s it’s not just you, look around again. Cultural touchstones and articles of faith from the organization’s stories about itself can absolutely prevent recognition of reality, and differing perceptions of reality will always cause conflict. Sometimes achieving product market fit requires doing things that the company does not believe in.

To be blunt, the issue is almost always one of technology. Your team is blocked by a core belief that the technology will work at scale, or with the needed security, or with the proper level of accuracy, or something like that. The conflict is that the use case you’re solving for has expectations that break the technology’s guarantees. There are also scenarios where the core issue is one of people or process, but “towing mines” in one of those scenarios is simply hiring ahead of demand. That’s also dangerous, but better discussed at another time.

If you suspect you’re in a “the tech won’t work for this product” scenario and need to change your organization’s beliefs… there’s only a few options.

Running away

An entirely sensible choice may be to bail: I have seen some very smart and experienced product managers leave their organization after 3-6 months, recognizing that they faced a nuclear level of conflict. That’s three months to recognize the ground truth and decide what to do, and zero to three for finding another role. Those PMs carry a lot less emotional baggage than some others, but it’s also tough on everyone around you to keep jumping until you find something you can work with. Eventually there won’t be new places to jump to.

Change the world instead

Hold your hand up, look the customer or analyst dead in the eye, and slowly intonate “you are actually looking for what this tech does well.” Demonstrate how the main use cases are resolved with the workarounds your team has devised. This path has its benefits, but it is inherently limited to early adopters who can fit your bill into their signing authority or perform the same trick on their own purchasing departments. You’re not likely to cross the chasm with an enterprise product that doesn’t answer the set of features that the market groups together as a category. To succeed here, you have to radically redefine what everyone needs and wants. That is of course exactly what your organization’s leadership wants! So if you’re on this path, don’t own it alone; you need to be working with the CEO and founders on a daily basis. If they can’t make that time for your project, this path probably won’t work. If they can you might still fail, but at least you won’t be doing it alone.

The inside job

Another path is to work within the system, or what I’ve sometimes called “steering from the boiler room.” Communication, upwards as well as all other directions, repetition, and long haul planning are the tools here. Slow and steady bending of opinions and decisions can win the race, or you can get 75% of the way there and have everything tossed by a change in circumstances. No one said product management was easy.

Caution: without a planned campaign to change hearts and minds, you’re not really working from within, you’re just complaining. Acting as the fifth column for customers against your own employer will not produce a long career, even if you feel justified. The working from within path is only valid if you can believe in the organization’s capabilities and core stories. You will be honestly working for their betterment for a multi-year period. It may not work, but this is the safest way to make change happen.

Towing mines

However, let’s say that you decide to really stand up against part of your own organization and fight for the product that your research has told you the customers need. The method I’m going to describe is a crude and dangerous weapon of last resort. It works equally well in a data driven or anecdata driven organization. It can be incredibly effective at producing rapid success, or it can get you and some people around you fired. It goes like this:

Proceed as if the product can meet the need

Sometimes the product’s technical problems are obvious from day one, but sometimes no one is aware that the technology can’t support the customer need. Maybe it’s not being tested at sufficient scale, maybe the design is carefully skirting around the way that customers will actually use the product, maybe the pace is too high for anyone to even look at what might happen when a customer tries it in production. As a product leader with suspicions that the tech has problems, you must remember that you can be wrong. Maybe the horse can sing. So, step one is to believe. Raise your concerns, but make an honest effort to disprove them. Ask the tech’s leading engineers to convince you how it will work. Ask for the scale testing data. Survey customers for their planned use cases and watch how those align to the design plans. Get real users access to design as soon as you’ve got wireframes, and keep trying for more feedback, faster.

Gather mines

This is the risky bit… in order to produce a compelling argument for change, small indications of trouble won’t cut it. Especially if the technical issue is one of scale, you’ll need to get some customers to use it at scale to see the issue. Furthermore, it should be a large enough group of customers that the concern can’t be explained away by “their SE is holding it wrong” or “their DevOps team doesn’t really like us anyway”. After all, it’s not uncommon that concerns from architects and testers were already ignored, so what’s a couple of complaints from early adopter customers? Instead, you need marquee names, and you need to see production grade usage. To get here, you’re asking sales teams and customers to spend time, jeopardize deals, and potentially disrupt production with a product that you’re not sure of. You might be able to bolster some of that work with internal testing as well, but the customer voices will have the greatest impact. This path means that customer champions are going to take on hard work and real career risk to implement your product at real scale.

Present the mines

In order to really land this pile of evidence, you want it all to show up together. That means organizing data collection to occur in a tight window, so that there’s a cresting wave of feedback coming in with your analysis and recommendation on the top. “We need to do X, because this much money from these customers. Data showing how current solution fails. Unhappy customer feedback. Data showing that X is the best solution.” Effectively what you’re doing is engineering a high speed, impossible to ignore feedback loop. Presuming a real technical problem, if you didn’t meddle this outcome would occur as a trickle of bad news, one or two customers per quarter. Towing mines is delivering ten unhappy customers as a package.

Outcomes

If it works, the outcome of this approach is a changed organization: the technical problem is recognized as a top priority and fixed to allow the use case to work, the sales go ahead, and serving this need is recognized as a real requirement going forward. If the outcome is increased growth and success, you might not even be blamed or remembered for the risks taken… success has many parents after all.

The technique does not always work. People really don’t like to have their beliefs challenged. You might be told you shouldn’t have chosen customers who needed the solution to work in that way, or that you should have given everyone more time to try more ways to make the solution work. If taking this fight on does not succeed, then the outcome is ugly:

• most of those customers are lost, often not just for the one product but for the entire relationship. Real problems aren’t lightweight to tangle with. If they try a solution to a real problem and it doesn’t work, that can poison attitudes towards all of the vendor’s solutions and open competitive doors for takeout.
• Involved product leadership is probably fired. While product leadership is safer than security leadership… You come at the king, best not miss. I have seen engineering leadership let go as well, though more rarely.

Assuming the technical mismatch from customer needs is real, avoiding this drastic technique would not save the product from failure, of course. Maybe there isn’t a solution X sitting around waiting to be implemented. For instance if the technical issue is scale, perhaps the product needs to be recast for a non-enterprise, small-to-medium market. Mine towing pushes your organization into a corner and forces an outcome: a new technology approach, a new go-to-market motion, or firing some people and salting the earth under your desks.

Conclusions

I’ve done this and succeeded through amazing luck and a lot of work. I’ve watched others do it with success, and I’ve seen some painful failures. To be honest, I don’t recommend towing mines at all. The successes produce bigger and better organizations with new verticals to sell into. Maybe that would have happened anyway with a slower and safer course of action. It’s fair to say the difference between towing mines and just doing product launch is the scale of your initial launch and the presentation of your findings. Towing mines is doing product launch without a safety net.

The failure of this approach almost invariably produces job losses. Its business implications are similar to sales pull-forward: success or failure is collapsed from a future uncertainty to a present reality. Maybe taking the safe path would have worked better, or maybe this surge of trouble is jeopardizing an exit event that you didn’t know about (another reason to engage the highest leadership you can when realizing that you have a problem of this scale). The internal job loss implications are to some degree part of the game: R&D and sales losses from a new vertical that can’t be delivered on aren’t unusual. However, there’s also people who didn’t mean to gamble that can lose jobs: customer champions who believed along with the vendor executives and product leader and sales team that the product could deliver.