In-Depth

App-To-Market, Part 4: If You Build It, Will Users Come?

You're a developer who's managed to create the killer app. You've also built a well-rounded team and marketing plan to push it. But wait -- is it what users want?

Also Read:

Users are the most important part of your application, startup, and, ultimately, business.  You must provide them something of value.  That something must resolve some pain point that they have.  It must do something to somehow make their lives easier.

This time, I'll look back at three of the startups I have been involved with and how each one worked with the users: The first was a real estate multiple listing service that was successful; the second was a pay-for-placement search engine that was successful; the third was a FourSquare-type of service for searching local services that was formed and worked several years, then saw success dry up when FourSquare started up.

Users' Needs
What do the users need? No one really knows, and users don't really know.  If you ask a user what their problems are, they can't really tell you.  So, how are you as a developer/startup/company looking to solve their problem?  Well, it does take a bit of inspiration.  You must take your knowledge of the marketplace to come up with some idea that will help resolve some type of pain a customer has. 

The pain in real estate MLS systems in the mid- to late-1990s was numerous.  The MLS vendors used proprietor hardware and software for nearly everything.  Third-party integration into systems was nearly impossible without the blessings of the MLS provider.  Perhaps worst of all, the MLS vendors at the time actually owned the listings that were within their system.  This meant that once the listing went into the MLS system, that listing became the property of the MLS vendor. 

Listings could not be exported into other systems without the specific permission of the MLS provider.  Now, many times, this could be negotiated out, but some providers wanted more money to remove this from their license.  Basically, MLS systems were a problem for several reasons.  For realtors who wanted to integrate with third parties, the pain points were the proprietary hardware/software and licensing.  The solution in this case was to use industry-standard hardware/software.  By using industry standard hardware/software, it became easier to integrate with other services as well.  With ODBC, creating a set of Web services allowed third-party applications on multiple platforms to access the data in a controlled manner. 

One of the major focus points was sitting down with users, seeing how these users would use the software, asking users what they needed to be successful, getting that feedback, acting on that feedback, and seeing the happiness on user's face.  We knew that we were creating value for the users.  The startup was eventually sold, and life was good.

In the pre-Google 1990s, there was a question as to what type of search results users wanted.  Would "organic" or "pay for placement" search be the dominant technology?  I built the search system for a "pay for placement" search results provider.  If I remember correctly, we collected somewhere between 1 and 5 percent of searches on the Internet in that timeframe. 

We would continually try different algorithms to attempt to improve our click-thrus, users returning to the service, and such.  While we were not able to interview actual users, we spent a lot of time testing these algorithms, running reports, and seeing what the income results where.  If the users were happy, they would return, and we would achieve more users without having to pay to obtain those users.  Eventually, this startup was sold.

I was recruited to work with a startup trying to do geolocation services in the 2000s.  Ultimately, the service should have been FourSquare.  Unfortunately, the service ended up being a mess.  Every time we talked to end users, the managing partner would cry out "Not my plan" like a parakeet.  Every end user suggestion was buried.  The result was no traction with the users.  Users could care less about our service.  It provided no value to the users whatsoever.  This startup failed and burned through approximately $750K in the process.

User Value
Having users is clearly a desire for all companies.  If you are an enterprise-style company, then customers/users will be paying/subscribing to your software/service.  You must keep these users happy.  These same is true for a consumer service.  Facebook must add value to the lives of its users or its users will do something else.  By solving users' problems and adding value, these users will continue to use the service and Facebook will continue to make money from them.

There is a secondary issue for having happy users.  That is that users talk to each other.  They will recommend services to each other.  Happy users who recommend your software are the most important marketing that any business can have.  Beyond just having happy users who recommend your service, these happy users will become fanatical about your services.  Fanatical users who sell your services for you -- what more can a company want?

Listen, Learn
If you listen to some people, you should never talk to users.  These people will tell you that users don't know what they want; therefore, talking to them is a waste of time.   There is some truth to this.  If you ask users a very open-ended question, they tend to not be able to answer it.

There is a way to talk to users.  You need to get some amount of industry-specific knowledge and begin asking some probing questions.  By talking with the users and working with them, you will be able to iterate on your product and to increase the value that you provide to your users.

Yes, I hear all the talk about Steve Jobs never talking to the users and on and on about this.  Unfortunately, you are not Steve Jobs.  For the rest of us, talking to the users is the best way to get ideas and improve a product.

A fear of talking to users is the risk that someone will steal your idea.  There are at least two issues with this.  If your idea can easily be stolen, is it that good of an idea?  Secondly, ideas have very little value.  What is more valuable is the execution on an idea.  If you get out executed, you were going to be out executed.  It does not matter if they heard about your idea or came up with it on their own.

What Have We Learned?
Figure out what users want, then back that up by listening and obtaining feedback from them. It is important to take the information that you get from users and act on that feedback.  Acting on the feedback helps you build a better product.  It also shows your users that you care about what they have to say.  This gives them more reasons to like you and your product.

Jobs notwithstanding, it is always important to talk to users.  You will always get value from the exchange and discussion.

About the Author

Wallace (Wally) B. McClure has authored books on iPhone programming with Mono/Monotouch, Android programming with Mono for Android, application architecture, ADO.NET, SQL Server and AJAX. He's a Microsoft MVP, an ASPInsider and a partner at Scalable Development Inc. He maintains a blog, and can be followed on Twitter.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube