Things I learned developing Search Software

Most software starts with someone who is frustrated and is looking for a solution that does not currently exist or or of it does, does not easily solve the problem.  The following insights are from 18 years of developing over 100 tools to make it more efficient to complete my projects.

Is there really a market for it? 

I have to say that 90% of the time there is not a commercial market for most tools. During a presentation at SMX Advanced last year I showed a list of some of the nearly 70 custom tools I have developed. I use at least a dozen of them on a weekly basis and of half of these there is not a commercial equivalent or one that has the specific functions I need. You might ask why is that, if you need it why don’t the multitudes of SEO’s need it? That is always my question, why don’t they need it. The answer might be below in the “easy button” section.

Here is a prime example, a big challenge for web site owners is minimizing the lost traffic from site refreshes and migrations. During these events sites may loose as much as 80% of their traffic post launch.  With such a negative impact on their business you would assume that there would be a market for tools that could mitigate this loss.  

We at Back Azimuth were doing a lot of large migrations and acquisition integrations so we built nearly a dozen tools to facilitate our workflow and demonstrate the potential for loss if the quality control was not present.

These applications were not pretty but highly functional and after presenting the methodology at a couple of development and SEO conferences all the signals showed there was a significant need for the suite of tools. Who would not want a solution that, if used properly, makes migrations and site refreshes nearly disaster proof. With all of the interest and the size of the business problem, we merged them together, improved the user interface and the Site Migration Suite was launched.

Unfortunately for us there was little there was/is little to no interest from either the search or the development community.  We had a few SEO’s want to demo it and ultimately about a dozen subscribers that raved about how it saved them from disaster but that it created more work than they cared to do. It was not a lost opportunity since we have made significantly more money fixing migrations at nearly 10 times the rate of the tool license.

People want an easy button 

I guess it is not unexpected that people want tools to do everyone automatically and present pretty reports. Many don’t want to think or interact with them just want them to do everything and just puke out a successful result.  

Of the last 100 emails related to HREFLang Builder the words that appear most are “automated” “no effort” and “set it and leave it” as what people are wanting to know about the tool.  We get asked almost daily why we have not added AI into the set up to detect the various formats that a site uses for their URL’s.  We do have it but the vast majority of users have complex set ups that require human intervention.   

People refuse to read user guides 

Unless it is painfully easy to setup and use which is nearly impossible for the first few versions of a tool you need to assume you will spend a lot of time on setup.

On-boarding has to be painfully simple and as few steps as possible accounting for any many variances as possible since people will not spend the time to learn how to do it.   We are rebuilding the entire set up function of HREFLang Builder since nearly 100% of those that subscribe do not read the “read me first” documents and have problems getting set up.   This requires us to spend a lot of time hand holding people to get even the simplest of sites set up.  

It seems to be such a problem that my friend Dan Weingrod has built a successful consulting practice using Design Sprints to help identify problems with on boarding and getting people to successfully set up tools.  

How Much Customization do you do?

Nearly every search industry tool developer has needed to build in dozens of functions to account for the craziness and dysfunction of what people pass off as websites. For HREFLang Builder we have over 100 functions in integrated to work around issues that violate some of the most fundamental web dev rules. In one regard this has made is the most powerful tool in the market but often we cannot innovate for advanced functions due to dealing with customization to account for a large customer.

We look customization through benefit test. Simply, if this modification this something that we can use for many customers and will we be a better tool because of it we will spend the time and money to do it. For example, due to the inability for a client to build a complete set of URL’s we needed a method to import 5 URL sources simultaneously. Our system could accommodate all of them but only one at a time. As noted in the on-boarding challenges noted above, we needed to make the initial import easier and this function would make that possible so we added it.

However, if the customization is for a single customer and there is no benefit to others then the customer must change their challenge or pay for the customization. We have turned away a few large prospects that assumed we wanted their business and would do anything to get it. It is often better to say no than take on the risk of developing custom features and not have real commitment from the client.

People don’t actually use the features they request

I assumed this one but until we added tracking to the tools we could not prove it.   We have done a lot of customization to a few of the tools based on customer feedback.   We have at least one report in each of the main tools that has been requested by multiple clients that has never been used by them.  In one case it was deemed mission critical to have it but they have never even clicked the link to generate it even though they wrote the specification and approved the final live version.  

People don’t want to login 

Along with “easy” people really don’t want to use tools or log into them.  A number of years ago when I showed him DataPrizm, Conversion Expert Bryan Eisenberg told me that do anything I can to eliminate or reduce the need to login to the application.  With DataPrizm using the tool is what it is made for and just sending reports diminishes the value.  

He was right, especially today. Nearly every user we have now just wants us to push reports out to Domo, Google Data Studio or some internal system. We have a client that paid us to develop an API so they can customize their exports and integrate them into their dashboards.  

People care about pretty over function 

Not surprising but people care about the user experience. Not really what you expect and we love feedback on workflow, button placement etc But the things people complain about have nothing to do with the actual function of the tool.  

We often roll our eyes at people on the house hunting shows that walk in and decide not to buy the house due to the color of a room or the carpeting. Nothing to do with any function, price etc but the easiest and least expensive things to change.  

We have had people tell us that they would not sign up unless we changed the color or removed a logo etc.   We had someone that said they had 3 basics account clients but before he would sign them up he required a custom URL and his logo and  in the tool since he was showing it to clients. Sure for $75 a month let me get right on that.  

Who will you upset?  

This has been an interesting learning curve with all the tools. In many cases you would assume people would embrace tools that made their work or lives easier.  It comes down to who and what process will you disrupt.  The more you change a process and highlight inefficiency the more people will reject the technology.  

We have had some negative comments from various consultants and agencies that did not want to use automation especially for HREFLang functionality that they were doing manually.  

One of our biggest detractors for HREFLang Builder was an agency team that was spending between 20 and 100 hours a month doing them manually for clients.   They just did not want to loose those billing hours.  In most of the cases the client wanted them to do something more constructive with the time and just license the software. 

Getting Paid  

In the agency example above, you might assume that a tool that costs less than a quarter or the labor hours would be an easy sell to agencies. From my time at Ogilvy and WPP getting agencies to pay for tools has always been a problem they just cannot convert billable hours into tool expenses.

Most agencies live in a world where they have to bill everything to a client. If it was not budgeted or cannot be directly billed is nearly impossible to get adopted.  

Most clients think like rational people, if you go to get your car serviced by a mechanic you don’t pay to use their tools.  You expect them to have the right tools to do the job as part of the price you pay for the repair.  This creates a challenge for everyone.  

You need to have flexible payment options either billing the client yet letting the agency access the solution creates a challenge for most subscription and login applications.     

So what to do with your great tool idea?

The best approach is to create that MVP and go out and test it to see if people will adopt it.  If you don’t get people lining up and raving about it most likely the market won’t adopt it.  

If you can crack some of these key challenges when you launch your application you will be be ahead of the curve and have a better chance of success.