Matthew Lang

Mmmmmm, shiny!

via FGGT - Photo by Father Tu

Bought myself a couple of books this morning for some light reading. Not the digital kind mind, actual hold in your hand, dead tree books. It's been ages since I done this. For the last couple of years I've bought all my books on my Kindle, but my reading has decreased in the last few months as a result of this.

I put it down to technology wear. I just can't face burying my head in another screen again when it comes to reading at night. Amazon tout the Kindle as a close experience to reading an actual book, but you can never replicate the feeling of reading a book with anything other than an actual book.

I'm not going to completely stop using my Kindle. It's still great for my programming books for quickly looking up something and I've got a ton of books on my Kindle that I read again quite often. There's lots of other reasons why I'm buying books again but the main reason is just to spark my love of reading again.

It's been a year since I started Journalong. It's been a real learning experience. While it might not be the success that I envisioned it to be, the experience of building a product has taught me a few things that I would like to share.

1. If there's no market for it, don't build it

When I first hit on the idea I immediately created a small Google Docs form that asked two questions.

• Would you be interested in using Journalong?
• How much would you be prepared to pay to use Journalong?

Feedback was quite low. Well, really low. Looking back now it was clear that there wasn't demand for Journalong. I should have abandoned the idea and moved onto something else. I didn't though. I wanted Journalong to use for myself so I built it anyway, and added the ability for others to pay for an annual subscription to Journalong if they wanted to use it. Was I building Journalong for myself or others?

What I should have done was simply build Journalong for anyone to use for free. Interest in the product was so low anyway that it wouldn't have made much of a difference anyway. With the focus taken away from trying to market the product to customers, I could have focused on delivering a better experience in using Journalong for myself and others.

If there's no market for your product, then don't build it and put a price on it. Of course you can build it for yourself, just don't expect to profit from a personal project with low feedback.

2. Measure user interaction

The only way to know if your product is being used is to measure key activities in the product. I didn't do this, so it was difficult to see how often Journalong was being used on a daily basis other than looking at page views provided by Google Analytics.

Decide on key activities and interactions you want to measure and build the monitoring of these straight into the product.

For Journalong I should have measured one thing:

• How often were people writing to their journal?

As Journalong writes journal entries straight to Dropbox, I didn't have any record of how often journal entries were being written for each user.

Building metrics like this into your product is just as important as the features your product has. Metrics like this can provide you with data on in-frequent users of your product. You can then survey these users to determine what's stopping them from using your product more frequently and possibly taking a higher tiered plan if you have them.

3. Gather product feedback frequently

Getting feedback using surveys on your product is critical. It let's you find out what's not working, what's attracting users and what's missing.

When I say survey I don't necessarily mean a 10 point questionnaire on the users experience with your product. Bogging users down with surveys like this can turn them away.

A couple of questions would do or you could do something as simple as a 'like' button beside a new feature. A simple button next to a feature could prompt the user when they use the new feature for the first time and ask them if they like it. Once they click it, the response is logged and the button disappears. If they don't click it for a few days then simply remove the button to stop the user getting annoyed.

Using the metrics that I mentioned earlier, you should also survey users that don't use the product very often. The feedback may turn out to reveal a missing feature or an obstacle in your product. You want to convert as many users as possible to using your product

The last place to survey your users is when they delete or cancel their account. This is your last chance to find out why your product isn't to their liking. Is it too expensive? Does it lack something?

Getting the feedback from the customer here, allows you to refine your product for the better to stop users cancelling their accounts for similar reasons.

4. Iterate often

This is important in the early days of your product. After I built Journalong I sat back for a couple of months and watched the activity on Google Analytics. Looking back it wasn't a wise move.

Metrics and surveys will point towards missing features or changes you could be implementing. Getting these in as quickly as possible will mean that less users stop using your product and will attract others. Be selective of the features you implement though. You don't want to burden your users with changes to the product every day. Common sense prevails here. If 90% of your surveyed users are asking for a specific feature that falls inline with your product, then implement it and ship it.

5. Adjust your price based on facts

I've made three pricing changes to Journalong over the last year and making it free next week (that's another blog post) will be a fourth. Pricing products is difficult. I arrived at my initial price based on the value that I thought Journalong would be offering to users and on how much people were offering to pay for the product from my initial survey.

Three pricing changes later and there's still no bite for Journalong. These pricing changes didn't come from any information I had though. I simply thought that reducing my price might spark more interest in Journalong. A stupid assumption to make and one I advise you don't do.

Adjusting your price isn't a big issue. In the early days of your product you should be continually refining the product based on the feedback from your customers. The pricing of your product is no different. Adjust your price based on feedback from customers. They use your product, they'll tell you if they are getting value for money from it.

6. Set a product trial period

Don't flog a dead horse. I've spent far too much time on thinking how to get customers for Journalong when I could have been using the time to build other products. After six months I should have called it a day for Journalong and moved onto something else but I didn't.

Setting a trial period for your product gives you the chance to review if the product is heading in the right direction. Are you getting sign ups on a daily basis? Are you converting enough users to paid accounts in order to be sustainable?

They say Rome wasn't built in a day but that doesn't mean you should continually hold out for a stampede of new users after you deploy that new fancy feature for your product.

After six months ask yourself:

Is it worth investing another six months of my time into this product?

If you have a number of paying customers using your product then it might be worth pursuing the product for another six months. If not, then I say stop working on that product and move onto something else. Six months working on a product is a lot of your free time taken up. If you're like me and have a backlog of other ideas, then it might be better to leave your product and pick something else up.

There's no secret formula

I started this product with the full realization that it could end up like this. A handful of customers and sign ups that bottomed out three months ago. Not all products end up being successful, but there's no rule to say that your product will definitely be a success. Coming to terms with this fact will make the day you give up on your idea a lot easier.

It's not the end of the road though. There's always that next product idea!

... are you going to take at the fence?

... with Nicholas Bate.

While trawling through my RSS feeds looking for blogs to unsubscribe from, I came across Andrew Chen's blog post about his decision to completely remove the RSS feed from his site.

As of today, I’ve removed the links the RSS feeds on this blog, and ultimately will phase them out completely in favor of email.

— RSS I quit you.. by Andrew Chen

Not a wise decision in my eyes and here's why.

Your inbox isn't an RSS reader

Using email to subscribe to web sites only works for a handful of blogs. You could comfortably subscribe to about five blogs and you would be able to manange reading a few emails a week from these blogs if they were not to frequent. Doing this for anything in the double digits number of blogs is a bad idea.

I don't want to flood my inbox with tons of emails from different blogs. Thats why I use RSS. That's why I use a RSS reader. I subscribe to the sites that I want to follow and then I can batch my reading of those sites to a time that suits me.

It's convenient and it works.

RSS isn't dead

Many people are starting to wonder if Google Feedburner will be next for the chop from Google but even if it was to be shut down, that's no indication to say that RSS is dying or dead. All it says is that Google isn't interested in dealing with a an RSS product.

RSS is alive and well everywhere. You can still find RSS feeds for millions of blogs and websites and Feedly are doing a great job of bringing over hundreds of people from Google Reader to their feed reading service. In the last few years there have a number of great RSS feed readers released on tablets and smartphones so that you read on the go.

Completely removing the RSS feed from your blog is a bad idea. After reading Andrew's post I found another website that I can unsubscribe from.

Sorry Andrew.

I had an idea for an application, so I stuck it into Journalong for later. Two seconds after saving it, I had another idea for an application. Put that in too.

I find this happens quite a lot. Ideas seem to breed more ideas in a short period of time and usually the ideas have something in common. In this case the applications I thought about building were very similar but for different audiences.

Whether I will do anything with them is another matter. The next step will be to flesh them out a bit more with a mind map and see if there is potential in the idea and ask myself some questions.

• Do I want to build this thing?
• Will I benefit from building it?
• Can I monetize this idea? (I ask myself this a lot these days)

If I can answer yes to all these questions, I'll start work on it or schedule it in for later if I'm currently busy. Always having a good side project to work on is a great way to keep on learning.

If I answer no to any of these the idea gets scrapped there and then.

This little workflow has worked well for me in the past. Weeding out the good ideas from the bad ideas means I spend less time on an idea that isn't going to benefit me in some way.

Today I spent an hour getting a script in place that will convert the Wordpress backup of my old Squarespace blog to Markdown posts so that I can pull them into my Octopress blog.

The script itself is almost there but one thing I noticed was how inherently easy it is to work with plain text.

For years I've had the chance of working with a number of different file formats. Some good, some bad. The good ones though were always the formats that contained little or no markup. Not only do they contain less markup, they also require simpler tools to work with them.

Plain text has that advantage.

One thing I will consider in the future when signing up to products and services on the web is how simple the data format is when I need to export data from that service. I'd rather not be wrestling with a difficult to work with file format when simpler formats already exists.

Not often you see one of these with the riser bars on it. Looks good.

via Pedal Consumption