Building A Successful Product: Start Small And Listen

In this article, based on my own experience, I’ll describe how it is possible to launch with a really small product and grow from those small beginnings by listening to your customers.

How To Decide On Must-Have Features For Launch

You might be starting small, but you need to draw that list of features that will make up your small but perfectly formed product offering, something that people would be happy to pay for because it brings them value as is. To get your product to launch, I suggest that you consider two main things:

• Who is my target customer?
• What problem(s) will my product solve?

For my own product, our target market was design agencies and freelancers. It’s a CMS, but we were not interested in making it a website-building tool or in appealing to non-coders. The customers we had in mind were the sort of people we were already working with: small agencies and designers who know how to write HTML and CSS, who don’t need a website-building tool and who want to manage content. This was an audience we knew well and importantly where people knew us. I would always recommend that if you are developing a product you target a market you already are well known in; it will make it far easier to spread the word, and for people to have trust in you. We also intended to appeal to people who develop relatively small-scale websites. We were not creating a Drupal competitor. So, our ideal customer is a designer, either freelance or in an agency, who knows HTML and CSS and has to develop smallish websites.

We wanted to solve two problems with the product. First, we wanted it to be really quick and easy to deploy. A small website doesn’t justify days of creating a theme or template. Secondly, we wanted to provide a solution that does not add any unwanted markup, CSS or JavaScript to the website. The designer should have control over everything the CMS outputs.

That was it. As we started to develop, a million ideas came to mind. We thought of so many features and possibilities, but we kept that simple use case and that ideal customer in mind and ruthlessly trimmed features until we had something that felt complete yet was about as small as it could be. That initial version of Perch took about four weekends to write — we were still a consultancy working with clients at the time. We spent about the same amount of time building the marketing website and the infrastructure to deliver the product.

Launching With Confidence

With your product developed, you should launch with confidence. You might have had a million features listed that you wish your product had, but your customers don’t know that. If your ideal customer exists and has the problems that you’ve identified and your product solves them, then you should be able to sell it to them. An advantage of getting to launch quickly is that you can test whether all of those things are true before spending any more time.

Don’t be apologetic about the small feature set. Market and sell the product as it is now, making sure that you are accurate in presenting the scope of the product and what problems it will solve. Assuming that people do buy and start to use it, you’ll soon start to get suggestions and requests for features, and you will probably be surprised by some of them. Some of the things you have already identified will likely come up as requests; but in my experience, customers will have needs that you didn’t even know exist, and they will be very happy to tell you about them.

We heard no outcry from customers who felt shortchanged by our tiny product, because we were selling something that does what it says on the tin; our marketing and sales were aligned with the product itself. We found, however, that those initial customers were delighted as we started to add new features based on their feedback, and many people who use the product today and have developed a large number of websites using it were among that first group of customers.

Listen To The People Who Are Willing To Pay For Your Product

I opened this article saying that getting to the point where people will pay for your product is important. There will be no end of people who are keen to tell you exactly what you should build them for free. Getting to launch means that you can start to hear feature requests and ideas from your paying customers. Requests from people who are happy to pay for your product are far more valuable than requests from people who are not. Paying for a product changes a person’s relationship to it and to the company behind it. The person becomes a customer and feels reasonable for asking for the service and features that they would expect as a paying customer.

Doing The Things That Will Make The Most Difference To The Most People

If you successfully launch with a tiny feature set, then you will quickly start to get feature requests. This is great! But it can feel overwhelming. How do you even start to provide all of these new features, and how do you explain to customers why their pet feature will not be immediately added?

We have always been very clear to our customers that we prioritize those features that would benefit the largest number of users. We collate requests that people post in our suggestions forum, email to us, tweet or tell us in person. We also look for the hidden feature demands that can be found in what people are trying to do with the product. Sometimes we can see someone doing something very complicated to get around the fact that something is not possible out of the box. If we see a number of customers doing that, we can infer that a feature is needed there. The things that would help the most people soon rise to the top. We have always found that as soon as we have picked off the most requested feature, another comes along as the new top request!

Getting Good Use Cases

To add a feature to your product, you need to be able to define a general use case for it. You can’t add a feature as you might for a bespoke build for a client; the feature must solve a more general problem to become useful to enough people to warrant the investment of time required to develop it. We often ask our customers to explain the use case for a feature they are asking for. We want to know the general problem they are trying to solve, rather than how they think their particular problem should be solved.

We often find that by exploring the use case a little with the customer — and in the forums, other customers with similar requirements often pitch in — we start to open a narrow solution into something more generally useful. Once we do that, then the feature becomes far more likely to be one we consider.

That being said, every so often a customer asks for a feature that doesn’t compromise the core use case and is fairly specific but very quick to develop. In that case, we do enjoy being able to quickly pop it into the next dot release and letting them know it is there. One of the best things about working on your own product is being able to delight people and do those unexpected things that help people out.

Looking After The Happy, Silent Majority

We’ve built a product based on speaking with and listening to our customers, but remember that the customers you hear from are probably the minority. If statistics are a part of your customer-support system, then look at how many of your customers ever come to you for support. In our case, it’s about 25%. We hear from only 25% of our customers. So, 75% are quite happy with how our product works — happy enough, at least, not to feel the need to ask us anything or suggest a feature.

Keeping that ideal customer in mind also really helps here. We have on occasion told people before purchase that we were not sure the product was a good fit for them, but they bought a copy anyway. They then spent a lot of time declaring the deficiencies they saw in the product — for example, complaining that it doesn’t come with themes or that they are being asked to write HTML. While these customers can be frustrating, you just have to step back and remember that they are not your ideal customer. The product isn’t really for them, so resist the temptation to add things for people who are not your target audience.

Even within your core audience, a few noisy people can make you feel as if all of your customers are asking for a particular feature. If that feature would take the product in a new direction or change a workflow, then getting opinions from the silent majority would be especially worthwhile. We have found that posting on our blog, talking on our podcast and mentioning a possible feature on Twitter does cause people we never see in the support forum to talk to us. If your usage statistics or sales data are broken down by user, then you can always use that to identify customers who you never hear from but are very active. Customers who like your product will generally be happy that you have asked them for feedback.

When asking customers for feedback, ask specific questions, rather than just what they think of your product. If you are proposing a major change, explaining the change and asking whether they foresee any issues in how they use the product can be enlightening.

Protecting Your Core Use Case

Clearly understanding your core use case — the initial problems your product is intended to solve — is vital to deciding which features to add to the product. We are over four years from launch, and yet the basic way people use our product has not changed — despite it being well into version two and far more full-featured than the tiny product we brought to market.

If a feature will complicate that basic use case, there would need to be a very good reason to add it. Sometimes we find another way to solve the same issue, which is where those general use cases from customers come in handy. You need to be happy to tell customers, however, that the feature they are asking for wouldn’t fit the product, and recognize that some of those customers might go elsewhere. Pleasing everyone is impossible, and your ideal customers wouldn’t want you to try.

New Features Rarely Spike Our Sales

It took me a long while to learn that adding new features is not a huge marketing win in itself. We’ve added some huge and much-requested features to Perch over the years. Many of those features took as long to build as developing the initial product did. However, launching a new feature has never made a blip in our sales figures. Our graph moves upwards at a fairly steady rate, with no evidence that any period of growth was caused by a particular feature.

That is not to say that adding features is not important. As mentioned, existing customers appreciate new features: They can see that the product is actively being developed and is evolving to meet their needs. However, pinning your hope of acquiring new customers on some new headline feature is not realistic in my experience. Instead, focus on marketing activities and on finding new customers and users, in addition to developing new features.

Conclusion

Starting small and focused, with a clear idea of who your ideal customer is and of the core problems that your product solves, is a great way to get a new product to market. For bootstrappers, it not only means bringing in much needed cashflow quickly, but also means that any new features you develop will be useful to your audience.

As your product matures, keeping your ideal customers in mind and speaking with them will help to ensure that you continue to serve your target market, rather than attempt to please everyone. By adding features deliberately and thoughtfully, you will delight existing customers and make the product useful to a wider market, while staying true to your goals.

Interested in learning more? Rachel will be hosting a full-day Smashing workshop on “Shipping Your Product” in Berlin, and she has contributed a chapter on customer support to the Smashing Book #4 (to be released in late November).

Front page image credits: Dave Gray.