Our industry is full of oriental phrases and loanwords to describe strategies for wicked problems. From Kanban and Gemba, to Shu-Ha-Ri and Poka-Yoke, a far-east sounding name suddenly seems to bestow authority, and turn an ordinary idea into ancient eastern wisdom. So here’s another one, especially good for problems people say are impossible to solve: Nijute!
Although it sounds like some secret ninja technique, don’t bother looking up Nijute in a dictionary. This is actually an acronym: Not Impossible, Just Too Expensive. This is one of the best mental tricks I’ve ever used working with difficult stakeholders, especially those that dismiss some idea as impossible to implement.
Of course, there are impossible problems. Knowing one is exactly what differentiates science and alchemy. But our industry rarely deals with truly impossible stuff, apart from an occasional troll posting P/NP to freelance sites to get quotes for laughs from mobile dev outsourcers. If it’s possible to fly helicopters remotely on Mars through the power of clever software, working around corporate bureaucracy or hardware constraints is definitely not beyond our capability. It might be difficult, it might be costly, but it’s rarely “impossible”. In fact, in most cases when people use that label, is just a codeword for “too bloody expensive”.
Proposing that a problem isn’t actually physically impossible to solve, but it’s just too expensive, might sound like stating the obvious. Ironically, I often got paid good money to do exactly that, and help people take a step back when they are too consumed by existing company processes or culture. The magical power of Nijute comes by transmuting an unactionable conclusion outside anyone’s sphere of influence (“impossible”) into a problem statement under someone’s control. (“Where does this expense come from? Can we reduce it somehow?”)
“It’s impossible to talk to a real user”, explained a business analyst working for an investment bank, when I proposed that we need to validate requirements for some ridiculously complicated changes to a risk management application. The issue was primarily political, with several levels of hierarchy separating developers and people who actually used the stuff developers wrote. The implicit expense there was the time of senior business stakeholders, who didn’t want to waste it talking to lowly IT. Applying Nijute, we looked for ways to reduce that cost. Promised to keep it under 10 minutes, and proposed to talk to just one of the users on the phone. After some political wrangling, we got to talk to the actual person who made the original request, and in five minutes got his approval for a much simpler alternative proposal.
“It’s impossible to run automated tests for this service”, insisted a representative of a financial platform vendor, when we were working with a large hedge fund to help them speed up deployments. We proposed using random non-existent stock tickers to have truly isolated automated tests. She went on to explain that the platform communicated directly to a price provider that didn’t have a test system. The platform was so tightly integrated that placing an order for a non-existent stock ticker in the middleware would immediately go to the provider to get the current price, and the company was charged for each such request. Pennies, of course, but our estimate was that running automated test suites as frequently as we wanted would cost a five-figure sum monthly. I thought of an obvious way to reduce the cost. Giving two developers a bit of time to develop a proxy that would return mock prices and cut off the pricing system for test tickers. Surely someone will be able to see the wisdom in that. Speaking to the IT director, he told us that they are understaffed as it is, and taking people from the main migration project is not possible, but if the cost is just five figures per month we should just go ahead and do it. He’ll pay for it out of his budget. Hedge funds are weird places. Automated testing would speed up time to market enough over the next few months that he could justify it, at least until the key migration was done. “We’ll restructure the ticker pricing later,” he concluded.
“It’s impossible to do A/B tests with features in production”, claimed a development manager of an ERP company, when I suggested that the way to resolve a difficult product management unknown wasn’t more theoretical customer interviews, but actually launching two versions with partial implementations and seeing which one gives end-users more value. “Our customer contracts prevent it”, he said. “It’s a nice idea for small web sites, but we’re building a serious enterprise product”. A few years earlier, nobody really knows why, the company signed contracts with all the main customers that they will never remove any features from their product. I can only assume this was a result of some overzealous optimisation driven by wrong metrics. They could get easily sued for breach of contract if they played two features against each-other and then removed one, but the cost wasn’t just financial. The reputational risk of launching half-baked features seemed to be so high that nobody wanted to even consider this option. Applying Nijute, we started looking for ways to reduce that reputational and financial cost. One of the sales representatives suggested that their client was begging for something like this feature as soon as possible, and she might get them to accept launching it as a “beta”. Not truly released (so avoiding the contract problem) but also “not not-released”. A quick phone call later, the key customer stakeholder bought the idea, as long as we could do it within the next week or so, and put a warning on both options for their operators to try the feature out and not to really trust it.
Applying Nijute usually has three steps.
The first is understanding the actual cost. Why is this too expensive? What kind of expense are we dealing with? The second step is to understand the value of solving the problem. Without a good model for value, it’s not possible to see if something is just very expensive, or too expensive. If an idea costs a lot, but brings more in value, it can sometimes be justified just by understanding that relationship and finding someone who can sign off on it.
The third step of Nijute, for ideas when the cost is higher than the value, is to look for ways to reduce that cost. Sometimes starting with a solution to a simpler problem is enough. Perhaps reduce the group of people who will be involved, or the scale of the initial solution.
The fourth optional step, when the cost can’t be reduced easily, is to is to understand that time also plays a role in this equation. The proposed idea might be too expensive now. We can work on reducing the cost gradually, so it’s not too expensive in some near future.
