A few years ago, I was working at a company that built document management software. Our hook was that your upstream and downstream customers didn’t need to interact with our system for you to get the benefits. We could accept inbound emails, faxes and even scanned paper images and we could do the same for the outbound channels. It was actually a pretty good system. However, we weren’t getting much traction from our sales pipeline. Everyone loved us, agreed we solved a problem, but just wouldn’t sign on as a customer. We couldn’t figure out why. That is, until one sobering conversation with a very large chemical distributor:
See, what we didn’t realize is that while we solved a problem, it wasn’t enough of a problem for our customers to warrant our solution. We didn’t meet the threshold required for them to introduce a new piece of technology into their everyday workflow. This was especially evident since we were selling to non-technology based companies. We were a bunch of technology guys who were used to working and selling to other technology companies. When we stepped outside of that realm, we found that non-technology people interact with computers in radically different ways on a day to day basis. I know, “no shit” kind of stuff, but many years ago, it was new to us, but not to our potential customers. Sadly, this critical fact is lost on many entrepreneurs. They have ideas for products that, while they solve a problem, they don’t solve enough of a problem to really elicit that stickiness that many products need to become successful with non-technology customer segments. Case in point: I recently had a new analytics package, let’s call it NA, demoed to me. While NA is very new and still evolving, it was very, very slick and incredibly optimized at performing a single analytical function well. NA is positioned as performing this function better than the 800 lb. gorilla in the analytics space, Google Analytics (GA). While GA performed the function, it was one of many that was part of GA and wasn’t really that easy to use. However, while NA performed this function better than GA, it was still the ONLY function NA performed. So their users would have to do two things:
Us: So you see, with our system we can take the 4 hours that Mary spends processing documents every day and cut it down to 1.Them: That’s interesting, but what do we do with those extra 3 hours? Us: What do you mean? Anything else you need her to do. Them: Well, we still have to pay Mary for all 8 hours since we need the work she does in the other 4. So we’d have to pay her existing salary, pay for your product and find Mary work those extra 3 hours a day. Us: (paraphrased) Uhhh…
- Use NA and only NA for their analytics needs ( unlikely )
- Use both NA & GA and somehow manage two analytics packages ( also unlikely )
You can probably guess which direction I would learn towards: GA is good enough in this case. The new product doesn’t solve enough of my problems to warrant the additional overhead and problems it would introduce.
So whenever I talk to a startup about their product, helping out from a CTO perspective or just chatting over drinks, I always ask myself two questions:
- How big of a problem are they solving for their users?
- Could this pass a minimum threshold for a user to integrate it into their daily/weekly/monthly workflow?
By answering those questions, you’ll go a long way towards achieving a product/market fit that can turn into quite a successful business.