Should you offer services or products?

The old phrase, The grass is always greener … is often heard when discussing the merits of services versus web-based products. Listed below are some of the advantages and disadvantages of both models. Which ones apply to you?

Products — Advantages

• gives you unlimited income potential, because time constraints are minimal (unlike selling services)
• enables lower prices for the consumer, as costs can be amortized over more customers
• allows you to concentrate on building one main project, rather than several small ones
• presents a choice of different revenue models, which are simpler to modify over time
• affords a better opportunity for residual income, in continual license fees
• provides an easier option to sell as an ongoing concern than a small web service does.

Products — Disadvantages

• requires more upfront investment in time and possibly money, especially the marketing aspect
• presents the possibility of competitors creating similar products and competing directly with you.
• necessitates market research to avoid ending up with little or no customer base.
• runs the risk of fielding more support queries than anticipated
• may delay long-term growth because of the lack of immediate cash flow

Services — Advantages

• generates income faster, because it’s easier to sell your services than a brand new product to the marketplace
• provides scope for a variety of projects, maintaining your interest in each new project
• offers more versatility in meeting market demands, rather than having to rebuild a mature application

Services — Disadvantages

• reduces your capacity for income, because it’s based purely on how much you can charge and how many staff you need
• limits short-term growth; for example, hiring staff is more time-consuming than bringing a new server online
• makes you more vulnerable to market buoyancy than product licenses

Also remember, as Dave mentioned, that it’s very simple to have a hybrid model of both: sell your current services while developing and offering products as well. This is similar to how businesses may sell hosting, stock images, and CMS licenses.

This post first appeared as part of Issue 424 of the SitePoint Tribune, a very popular email newsletter that I am co-editor of. Thanks to SitePoint for allowing me to reproduce the work here.

Here’s a question for you. When your last project finished, what was the final communication the client received from you? Was it a bottle of wine and card, a “Thanks for the work, call me if you need anything,” or just an invoice in the mail?

It seems to be very common for us designers, developers, freelancers, and businesses to be keen to talk at the start of a project, but shy to speak at the end.

What we really need to do at the completion stage of projects is to thank the client for their business, and then ask them some hard questions.

Why do I say hard? Well, maybe it’s the human condition, but we as service providers don’t like to imagine that clients are ever anything but absolutely impressed with our work — but I have to tell you, the truth is that they often aren’t.

Think back to the last time you were out for a meal. When you paid, the waitperson probably asked you about your experience. In answer to “How was everything?”, you probably mumbled something like, “It was good, thanks” — even if you didn’t feel that way.

Why? Few of us like confrontation. We don’t like to give neutral or negative feedback (unless it’s within the relative anonymity of an online auction web site!) and we don’t like receiving it, either.

However, feedback is very important to us, as individuals and as businesses, in order to grow and improve — even if that does mean we open our ears to possibly negative feedback as well.

The next time a project wraps up, consider emailing your client a link to an online survey. I have found people are far more willing to be honest completing a form instead of speaking directly to you.

Ask them what they liked most about the project — and then ask them what they liked least. You really do want to know. It could be something really simple that you or your firm is doing over and over, with every project, assuming clients like it when in fact they don’t. This habit or process could be holding you back from success!

In my business, we’ve been seeking feedback in this way for a few years now. We get some great feedback, both positive and negative, which helps us tune our processes and our services to better suit the next customer. We’ve had some really crazy input, too — for example, our coffees were too strong, or we were so good that the client was going to miss our weekly meetings!

There are countless survey software systems available, many of which have a free plan. Alternatively, it’s a trivial matter to whip up your own web-to-email form. The trick is to avoid asking questions that are too leading: “Did you find our design team very enthusiastic?”, or that allow for only yes or no answers — keep questions open. Keep the form brief, too — if it goes on for pages and pages, clients will be hesitant to complete it.

The next important step is to act on the feedback. It may warrant a call or meeting with the customer for further details, or speaking to team members (or yourself) if there was something amiss. And remember to give praise where it’s due — we all enjoy a pat on the back from time to time!

This post first appeared as part of Issue 418 of the SitePoint Tribune, a very popular email newsletter that I am co-editor of. Thanks to SitePoint for allowing me to reproduce the work here.

Egomaniacs who are their own favorite topic. We all know someone like that, right? But are we in danger of coming across that way in our sales proposals?

Pardon, I hear you cry! How could we sound like this? Well, for a start, do you spend the first few pages covering all the awards you have won, and the bright history of your team? How far into the document before you learn what the prospect wants? Are the prospect’s objectives even covered in your proposal?

I’ve read many sales proposals from web companies over the last decade or so, and it still amazes me when I come across this type of example: a mind-numbing twenty pages in length, with pages 1 to 16 about the web company, and page 17 the first sign of discovering what the prospect wanted.

How did I get my hands on this proposal? Well, our company won a job, and the client gave me this blundering document to show what not to do in business. We shared a laugh reading through the novel-length sales pitch together—where they also took the liberty of misspelling the client’s name on the covering page!

The secret of successful proposals is to focus on what the prospect wants to hear. They want solutions to their problems, benefits for their projects, and most of all, they want to be convinced that you understand what they need. Sixteen pages talking about yourself (especially at the beginning) is subconsciously stating that you believe you are far more important than their project!

You should mention who you are and what you do, but after their project details, and one or two pages should suffice. Or perhaps make it a separate document entirely.

Make sure you’ve included the basics: timeline, budget, and deliverables. Reiterate your understanding of the prospect’s requirements, and make sure your proposal clarifies how your solution will help them.

Spell-check, then spell-check again—misspelling a prospect’s name is just plain lazy. Use short sentences, avoid long paragraphs, and keep the entire proposal succinct; a technical specifications document can run to dozens of pages, but a sales proposal shouldn’t. Speaking of technical, don’t get all abbreviated on the client. The average prospect doesn’t know what half the abbreviations we use mean, and we shouldn’t expect them to, either.

Sell benefits, not products. You may have a great content management system, email gateway, or other product, but talk about the benefits of these, not the product features.

Include testimonials or links to similar projects if you can. This shows you have a proven track record, and understand their requirements.

If you lack any design skills, ask a colleague to give the document some sparkle, and then use this as a template. A polished document is clearly marked with headings, sub-headings, and block quotes (if required).

Conclude the proposal with a call to action. Don’t just end it with a price for the job. State what the terms are, and make it easy for the prospect to action the starting process. For example: “Send this page back, signed and dated, and we can commence immediately” is far better than a dollar figure on the last line.

This post first appeared as part of Issue 417 of the SitePoint Tribune, a very popular email newsletter that I am co-editor of. Thanks to SitePoint for allowing me to reproduce the work here.