Who are your customers, and what do they want from your product?
If they don’t like it, your product won’t sell. Everything you do to create your product will be wasted if you don’t start first with your customer.
You probably already think you know your customers. Maybe they’re already using your other products, and you know the problems they’re trying to solve with this new software product. So far, this all makes sense.
But without real data, you will be disappointed when you try to sell it to them. What you thought was important to them—so important that it would be the reason they would buy your product—wasn’t that important to them after all. But other things are, things that would have caused you to design the product differently.
Don’t guess. It’s very expensive.
Ask.
What do you need to know about your customers before you can sell them your application?
- What the customer is doing now to solve the problem, and how they feel about it. If they’re ambivalent, because their current method (including “doing nothing”) is good enough, it will be harder to sell your solution.
- What else the customer has looked at, and how they felt about the solutions they found.
- What competitors have promised them, and what they believed or didn’t believe about what they were told.
- What they might pay for your product, and how they want to pay. Yes, you can ask about this. You need to know if they insist on up-front licensing, or would be open to a subscription model.
- How they prioritize the features and functions. Which of them are essential, which ones are “nice to have,” which ones are “standard” and “assumed,” and which ones are not really necessary.
- Which of those “must have” features are things they really use, and which ones are just “checklist” items. You’ll be surprised how often those “must have” features never get used. We separate features into two categories: “buying criteria” and “using criteria.”
- How they feel about these types of applications in general—in terms of larger trends. Do they still feel that this type of application is critical, or is interest in this waning? Are people finding other ways to solve the problem, or is the problem less critical than it used to be?
- What other applications—similar to yours—excited them, and why.
- The things that would make your customer say, “I have to have that,” or, “I’ll never buy that.”
Software Usability: How can you make sure they’ll like your software?
As you develop your application, countless decisions will need to be made. Those decisions will determine if your product is a success out in the marketplace. That success will be driven more by the usability of the product than by any other factor.
Today’s customers have become quite accustomed to trying out an application before they commit to paying for it. In just a few seconds, they will decide if it will do what they hope it will do, and if the application is pleasing to use. They won’t have the patience to read a manual or let you train them. They won’t think twice about rejecting it. They will assume that someone else must be doing it right; they just have to keep looking.
Your revenue will suffer if you leave usability decisions to your programmers, or if you let these decisions be made “by accident” as an almost thoughtless part of the development process. Or if you don’t give usability the attention and focus it deserves.
You really don’t want to develop an application, take it to market, and only then find that it is unusable, and that you have to go back to the beginning. Making changes to a program in response to user rejection, after it was supposed to be “finished,” is no small undertaking. It is also disheartening, embarrassing, and expensive.
Here’s how to make sure they’ll like your application:
- Put a key stakeholder in charge of usability. Someone who knows the customer, and who represents the customer’s interests. That person could be you (the CEO), the team leader, or a product manager. It should be someone who is a part of all the decisions being made, who knows how the customer thinks, and who can represent the customer to the team.
- Involve a usability expert in the development process. This can be outsourced, if your budget doesn’t allow hiring someone full-time, but make sure it’s someone who really understands human factors. Adding usability expertise to the team will ensure that your application makes sense to your users, and makes them happy.
- Talk to actual users. Find out who they are, the problems they’re trying to solve, what they want get from your application, what else they’ve tried to do to solve their problems (and how that worked out for them), and how this product would fit into their life or work. Don’t depend on surveys for this; the survey itself will be biased toward your own assumptions (which are always slightly-to-terribly wrong), and users often tell you what they want, which is usually different than what they need. Interview at least seven customers of any given type; this is a sufficient sample size to be able to trust the data.
- Organize your findings into categories. Then analyze your results, and describe the issues that all of these customers have in common. This will provide a roadmap for development, and will result in customer-pleasing decisions.
- Mock up the application. Use anything from PowerPoint to an interactive prototyping tool such as Invision. Take it back to those same customers and get their feedback. Record their comments, organize the findings, then analyze and summarize the results. Again, this will provide a roadmap for development that will result in customer-pleasing decisions.
- Once the application is up and running, get it into your users’ hands early and often. Don’t wait for a “beta release” (unless you want to be like Google and just call everything “beta,” which is fine, too). Start with a small set of users and grow this group as your application matures. Repeat the process of soliciting and analyzing feedback.
- After the product is released, keep gathering user suggestions. Make it easy for users to provide feedback. Keep track of suggestions, build those changes into your roadmap, and make sure someone gets back to the them (and all other users) when new releases come out with the changes. Make your revision history visible to the public. Future revenue depends on how you respond to suggestions, because buyers considering your application will research reviews and discussion groups to determine how well you respond to customer feedback.
If you’re thinking this sounds like a lot of work, just remember how much harder (and more expensive) it is to make these changes after you’ve released your product and have gotten bad reviews or angry support calls.
Also, if you’re worried about bothering your customers with all of this up-front work, don’t be. In our experience, people like being heard. They get excited when a feature comes out that they see as a response to their input. They gain a sense of “ownership” of that feature, and they will tell others how responsive you have been.
Lastly, are you considering all of your customers? We’ve been using the words “customer” and “user” somewhat interchangeably, but in reality they are not always the same. The person who makes the buying decision is your customer, whether or not they ever use the application. And in many situations they are not the ones to use it. We have created complex, B2B applications that are used by one group in the enterprise (the marketing department, for example) but acquired by a different group (the IT department).
This certainly complicates sales and marketing. It also complicates development, because you have to satisfy different stakeholders with a different set of requirements, desires, and “gotchas.” But it’s a necessary step to making an application that actually fulfills its purpose. And there’s a silver lining – when you start truly understanding your customers you will feel better and more confident about your work, because you will know you are creating what your customers asked for.
This article was excerpted and adapted from The CEO’s Guide to Creating Great Software for Your Customers, When Software Isn’t What You Do, by Frank Zinghini. Click here to download the full guide for free.
hbspt.cta.load(2637494, ‘7be9b60b-533e-4a11-9fb1-d6f541024810’, {});
