When we were first starting up Guru a lot of our initial Customer Development work was spent validating "Enterprise Search". We were very tempted by this feature set as the promise of Enterprise Search is you just point your enterprise search engine at all your existing content and voila, you have one place to search your entire enterprise for anything you need without doing any work. So we tested this with pretty much everyone we talked to about Guru.

Turns out we were wrong! The promise described above does sound amazing, but the feedback we got consistently was something to the effect of:

"The problem isn't search. I know where to look for things. The problem is combing through a sea of results and wondering if what I find is accurate. I go to the 2 or 3 places where I have to search and I end up getting back a list of files or web pages that look similar or have gone stale. So I just give up and ask an expert. If you build enterprise search capabilities into Guru, you will just be moving this same problem into a new product."

This was definitely surprising. That last sentence in particular really stuck with us. So we decided to dig in. Enterprise Search as a category has been around for a long time. There is really no value to it? Not exactly...but here is the result of our findings.

Who's stuff are you looking for?

Finding "my" stuff is different than finding "other peoples" stuff. There are many products today that do this well. You can hook in your Google Drive/Box/Dropbox/Evernote etc. do one search and get back your stuff wherever it may be. This can work well because the results you get back in the search will be familiar to you because you wrote it in the first place. You will see the 4-5 results you get back and probably think "yup thats the one" and open it. You probably don't need much context because you may have a consistent way you name files or folders. It is also a nice productivity solution on mobile, where apps like email clients are adding this as a feature. You can quickly "attach" a document from these other services without having to jump out of the app you are working in.

But if you are trying to search across a team's collective shared content it's different. You enter your search terms and get back a list of stuff. Who's stuff is this? What are these confusing file names? Am I in the right folder? You need context; whose information should I be looking at? How do I use this information I am finding? When was the last time a subject matter expert verified that this was accurate?. You end up opening a few of the search results, get frustrated and give up.

Static vs. Dynamic Information

Finding static information via Enterprise Search tends to work pretty well. For example searching an email archive. Those emails were already sent and will never change again. Contracts is another great example. If a contract ever changes there is a very clear legal process that gets followed to execute the change. This is why you see a lot of Enterprise Search vendors going after "eDiscovery" type use cases, where a company wants to quickly find content on a topic for a legal matter. You are searching history, and history doesn't change (we hope :)).

But totally different when you are searching for information that changes. Try searching for the latest powerpoint about your product, your search results usually look something this:

  • productnamelatest.ppt
  • productnamelatest_v7.ppt
  • productnamelatest_customer.ppt
  • productnamelatestjohnsedits.ppt
  • productnamelatest_master.ppt
  • productnamelatestmasterv3.ppt
  • productnamelatestfinalmaster.ppt

Madness! It's not intentional of course. People are busy and everyone uses their own conventions. But you will either (1) just pick one of these and go, and likely use something outdated or inaccurate, or (2) go ask someone for the 800th time where the latest deck is.

It's not just a powerpoint problem it's an any file problem. You need more than just a file name and last modified date to know if it's the right thing. And internal websites and wiki's have the same problem too. They can be a little better because you can make a web page with a link to the file in question, and add descriptor text. So at least the usage context can be provided. And there should be less chances of the file proliferation shown above because you are editing the same web page over and over. But 2 key things are still missing:

  1. Has an expert explicitly verified that this information is correct?
  2. When was the last time it was verified, and how often is it verified?

Once you have this, you know that you can trust what you are seeing. Without it you are guessing and will either use it and hope its right, or you will bug the expert of that topic, again.

Push vs. Pull

Search is and will continue to be a core mechanism to find what we need. It is the simplest interface that any of us can use, and allows us to "pull" in information when we need it.

But what about all the stuff we don't know to search for? Search is the path you take when you know you need to look for something, but in our work lives there is valuable new knowledge getting captured all the time. It is not reasonable to assume that we know everything available to us and how to search for it. So even with the best search in the world, there remains a big bucket of valuable information that we miss because we didn't even know to look for it.

As we have written before, we think another big shift that is starting to happen is the rise of "push" based services, where based on the job you need to, your apps come to you to help you complete the job. What if, based on what you were working on, that valuable information could be pushed to you when you need it?

  • Open an opportunity record in your CRM, and get told what case studies to use, what vertical specific messaging will work best, and what value props matter most to your prospect based on their job title.
  • Open a support ticket, and get troubleshooting guides automatically suggested to you based on which product, which support category, where the customer is located, etc.

In these examples, it's unfair to assume that Enterprise Search will solve for this. You can't search for something if you don't know it exists.

Now it makes sense!

So the product category itself makes sense, but like anything you have to apply it to the right problem domains. And for what Guru does, it's not the right problem domain.

  1. Most content in Guru isn't personal. While customers certainly have private content they capture in Guru just for themselves, most of the time our users are searching for someone else's content. As described above, it needs to be easy to find and understand the intended use of that information.
  2. Most content in Guru changes. Many of our customers are capturing information about the products they make and sell. How they message product features, how they position against competitors, how they handle objections, customer case studies, product faqs, etc. And most of this stuff changes. Products change several times a year or more, competitors evolve and release new features, messaging improves as you learn more about why your product wins in the market.

So for our needs, it didn't make sense. The takeaway: it's an important product category, and a very enticing one given how easy it is to get going for company. But like all "silver bullets" don't expect it will solve every problem.

Want to learn about what kinds of solutions will work for your sales enablement needs? Download our Guru Guide to Sales Enablement eBook! 100+ pages of content on how to build a sustainable sales enablement program and how to choose the right enablement solution for your team.

Recommended Reading

The Problem with Proactive Documentation: Flipping the Script With KCS and Guru

How Guru Uses Guru for Employee Onboarding

Let us know what you think!
Customer Contact Central