I need a web-to-print solution, which one should I buy? I am in the market for a new Print MIS, which one should I buy? My profit margins are decreasing, and my head count is increasing – I need automation, what tool should I buy?

All those questions are about the software technology that could potentially be “part of” a solution to a set of undefined problems. I usually start with the following question as my answer to these questions; what problem(s) are you trying to solve?

The clearer the answer the quicker the recommendation I can give. In some instances, printers have done so much thinking about what they want out of technology, their answer is readily available and organized. When a printer can clearly describe the challenges; I can almost always suggest one or more technologies they should consider as part of their solution off the top of my head. Then I always go down the path of “technology is only part of the solution” your success will be highly dependent on your team’s ability at learning the best way to implement the toolset for your business and drive widespread adoption across your whole team.

Unfortunately, most printers haven’t taken the time to think through the problems they are trying to solve. Their answers are more generic like; drive new business, remove touches, increase efficiency. Those aren’t problems – those are phrases that can be found on every marketing brochure ever written -  they don’t really tell me anything about what you’re trying to solve. The other common response I get is a list of features they are looking for in software. I had a printer say to me the other day; I need a drag and drop interface for ordering complex personalized products online. Features give me some clue as to what you might be trying to solve for but not exactly. It’s way better to speak about your software needs by defining the problem – not listing the features. If you are defining the solution – you are limiting your choices. By defining the problem (not what you think would be a good solution), you open yourself up to learning about alternative ways it can be solved. Drag and drop might not be the best user experience for all software challenges.

If I had a magic wand, I would change every RFQ process on the planet to be a list of problems that you want the software / vendor to solve and then ask each vendor to describe how they solve that problem. Verses the current process which is a list of features – a description of how the customer thinks it should be solved and a checkbox saying if the vendor can do it implying it has to be done in this manner. These RFQ features can get very precise; I saw one the other day that dictated where the login button had to be on the page – what the heck? The problem to be solved is secure authentication of approved users; there are many ways of solving that challenge. The author of the RFQ is actually dictating that the solution be custom built if they want to decide where buttons appear. It would be WAY more interesting in an RFQ to ask the vendor how they solve it vs. dictating to them how you think it should be solved.

In the technology startup world, falling in love with the solution is often referred to as “Innovator’s Bias”.

“When we first get hit by an idea, the solution is what we most clearly see and what we spend most of our energy towards. But most products fail?—?not because we fail to build out our solution, but because we fail to solve a “big enough” customer problem.” Ash Maurya Love the Problem, Not Your Solution

In running your print business, you understand the overall problem, so you start looking for technology to solve it. Our bias comes in when we see a specific feature in software that we like – suddenly we are stuck on that way of solving it. Business software implementations fail not from a lack of features (not even close – most printers use less than half of the available features in their software tools). Implementations fail because the software fails to solve the most important challenges it was purchased for. This is either due to lack of focus on solving those issues but primarily because those challenges were never fully defined before the purchase.

The sales process prefers features. The sales process likes to present more features because more is better right? Why do we create feature comparisons? We buy the one with the most? When in reality what we want out of software is the solution that solves our most important challenges the best. So, more isn’t better. When you shop for software technology; shop with a list of the top five most important challenges you want to solve with this technology. Define the challenges clearly. Then when you are ready for a demonstration – ask the vendor to ONLY show you how their software solves for your top five challenges. Guess what you just did? You just saved ninety minutes of your life because you will not be sitting through a scripted demo where more than half the stuff is completely irrelevant to your business!

I first heard about this phrase when I saw Uri Levine, cofounder of Waze (the traffic app) speak at a technology conference. He was wearing a t-shirt that said “fall in love with the problem.” His advice is more for the software vendors reading this article. Before you code the next feature into your software; define the problem you are solving? Is it worthy of your attention? Does it solve a problem that your customers need to be solved?