Eight Steps to Software Products That Delight Customers

How do you want your customers to feel when using your product? Photo credit ~~Tone~~

This is the second article in the series "Are you Sure Your Software Business is Ready for Growth?" Incorrect focus is a top growth obstacle. As your business evolves from stage to stage, your organization's focus and skills need to follow.

If you were successful in the initial stage, you have discovered your early adopters. Customers who believe in your vision, and are ready to work together with you in an early phase.

But how do you make sure you take the full advantage of this opportunity?

How do you translate the feedback from your first users into a product that delights your customers?

#1 Keep Your Ear Close to the Ground

There is no better way to get feedback from your customers than to sit and talk with them. Especially at the very beginning.

However, beware of simply asking customers what they want.

"If I asked people what they wanted, they would have said faster horses" Henry Ford

You are the visionary, the innovator.

You cannot outsource innovation to your customers. This is how the responsibility is divided: the customers are responsible for the problems you solve for them, and the way they experience your product. You are responsible for the solution space and for the design of a great experience.

Here is a rough roadmap for you:

  1. Dig deep into the customers' world to get a good understanding of their problems and their workflow
  2. Scope down the problem, until you are able to design the 20% of product that solves 80% of their problem
  3. Design a simple solution to the scoped-down problem
  4. Put it in the hands of the customers and observe. In the beginning, you can even use paper prototypes—or other kind of mocks
  5. Go back to the drawing board, and iterate

#2 Scope Down

We once spent close to 8 months implementing a list of product features. Most of them did originate from our customers. We talked to many of them along the way.

Unfortunately, it turned out that we have built a product that was a nice-to-have.

And we all know you want to build a must-have, a pain killer—not a vitamin, right?

What we failed to do initially was to scope down. To search for that one killer feature. In words of my CTO:

"If we cannot find that one killer feature that we can sell on its own, adding more of the other features is not likely to make our product a must-have." Jonne Deprez

This is why in the first step you want to scope down the problem you are solving, until you are able to find that one product feature that is able to solve it. 20% of product for 80% of problem, remember?

You may feel like you are giving something away by not implementing all the features you can imagine. That you are making your product less powerful. But know this: people like simplicity, especially in today's overwhelming world. And it takes a great product designer to design a simple and usable product.

Simple does not mean easy.

Of course, you might need other supporting functionality surrounding your core feature. Nevertheless, carry out this one exercise repeatedly. Go through the list of your functions, and ask yourself:

  • Is it absolutely necessary? If the answer is no, remove it mercilessly 
  • Is there an alternative way to implement this? Can we integrate with an existing service? Can it be done manually in the beginning? Often, it is possible to come up with a simpler, more generic—and a more flexible—concept

#3 Don't Design Screens, Design User Experience 

This is the typical product design process:

  1. interview your customer to understand the domain and their needs
  2. create the data model
  3. create screens or wireframes needed to manipulate the data and deliver the required functionality to the user
  4. discuss wireframes with users and then start coding  

Phil Libin, founder of Evernote—a service with 40 million users at the time of writing—once said that everything changed when they stopped thinking in terms of features and started to think in terms of user experience. "Design the experience first, then figure out the details".

What does that mean? At its minimum, it means to:

  • Start from the user, their goals, and their task at hand. What outcome do users really care about? What are they trying to accomplish? What information is really necessary for the user to accomplish their task? Which is most important?
  • Ask yourself: how should it feel? Should it feel simple (hide all complexity from the user), should it make the user feel like they are in control, should it provide a comfortable reading experience...

Hiring a user experience expert to help you out could prove to be a great investment. If your budget is limited, go for a design review, or for them to join your design brainstorm.

#4 Carry out 3 Usability Tests Per Month

Want to design a product people will love? Then you need to do usability testing. 

Usability tests are a special kind of tests that help you understand the usability problems of your product. You let the user use your product, and ask them to verbalize their thoughts. What are they seeing? What can / should they do next? Then, you ask them to carry out a couple of tasks using your product (and again verbalize their thoughts and experience).

You can read more about usability testing in an easy-to-read Steve Krug's book "Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems". A book that can be read during one flight. And according to Steve, you will uncover most problems by carrying out only 3 usability tests per month.

Do less, but be regular. 3 a month. 

If you have a web or mobile-based product, you can also use a service like User Testing.com. It simplifies the process of organizing usability tests. You simply order videos of people using your product and speaking their thoughts.

#5 Measure

The moment you start having real users, you want to start observing how they actually use your product.

Fortunately for you, in software products, you can objectively observe by measuring. You can measure many things:

  • Performance and responsivenessof your product, a major usability concern. There are many services that make this super easy (e.g. Pingdom or NewRelic)
  • How well does your product meet business objectives. Dave McClure gives an overview of useful business metrics: acquisition (% of customers that sign up and have a first gratifying experience), retention (% of customers that regularly use your product), referral (% of customer who bring in new customers on board), and revenue (% of users that buy your license / subscription, especially useful for the freemium business model)
  • Frequency of use of certain features. This is especially interesting for the newly launched features

Not sure what to measure? You can start simply by logging each action users take. You can then analyze that data later, and derive specific metrics before implementing the measurements in your system.

#6 Iterate

You don't do all the listening and measuring just to learn. You do it because you want to keep on improving your product.

In other words, you need to iterate.

That requires a special kind of a development process. In the beginning of software engineering, experts tried to transpose best practices of other engineering disciplines. Good software engineering meant spending lots of time in big upfront analysis. You would analyse the full list of product requirements, perform a functional analysis and translate those requirements in a specification document, then spend time detailing the design of the system before you would start implementing it. Only then would you code and test.

You would spend lots of time building a product that was potentially not the right one to build.

Enter Agile development.

Agile turns this around, and breaks down the development process in short iterations (anywhere between 1 week and a month). All the activities: analysis, coding and testing, happen during one iteration. At the end of each iteration, you deliver a fully functional (albeit limited) product increment.

To get the most out of each iteration, you want to put the product in the hands of your customers as soon as it is available. That is why you also want to consider the following step.

#7 Deploy Continuously

All the code that is developed has no value until is released to your customers. The longer you wait to release it, the longer you will be deprived of precious feedback.

"Product development gets in the way of learning." Ash Maurya

You therefore need to shorten the release cycle as much as possible. The most competitive companies often release daily, or even several times per day.

This requires an advanced process and lots of automation of release procedures: often called continuous deployment.

#8 Watch out: Don't Build a Bespoke System

Listening and iterating will help you create the product your customers will love. However, by listening too much to one dominant customer, you risk building a bespoke, custom product, that is only good for that one customer.

Like I said, you need to carefully listen to as many customers as possible. But then, it's your job to guard your vision. It is in the intersection between your vision, your customer's feedback, and lots of iteration, that great products are born.

 

I hope you enjoyed the article. We often work with companies in helping them achieve greater flexibility and thereby being able to better respond to changing market requirements. Why not book a free meeting with our experts now?