Matthew Lang

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

My career has been quite varied when you look at the different sectors I’ve worked in. NHS, risk management, payroll, retail and technology repair and recycle. I’ve worked in a number of other different sectors as an ERP developer as well but largely these were for small periods of time where you rarely get a chance find out a lot about the domain of the business.

Since I started freelancing at the start of the year, I’ve been working largely on public health and information websites for NHS related organisations. Not only do I get to work with my favourite development tools and languages every day but I also get to work in my favourite domain. Health.

I don’t know what the attraction is to health but I find it an interesting domain to work in. Providing tools for health organisations to share information with their patients so that they can lead healthier lives is quite rewarding in my view. Over the last couple of moths I’ve even found myself reading NHS related publications to broaden my knowledge of the work I am doing at the moment. I’ve never done that for any job that I to have had.

It’s got me thinking about whether its worth specialising in health contracts or should I stick to working in different domains to keep things fresh? Working in different domains sure would broaden my experience and there might be another sector that I would be interested in. However health is already such a varied domain that could provide some diversity.

I suppose the real question is this. Which one will allow a steady income of work for the near future?

It’s been a while since I went through all the incoming data I receive and did some house keeping on them. Over the last few weeks I’ve been increasingly adding more and more waves of content that come to me. Anything related to freelancing invariably gets added, but I’m now at the stage where I’ve spread myself to thin. There’s podcasts I haven’t listened to in the couple of weeks, books sitting on my reading list that haven’t been bought, and RSS feeds that I need to unsubscribe from.

It’s time to put up a breakwater.

Books

One technical book. One non-technical book.

That’s the rule I employed a few years ago, but in the last year it’s been thrown out the window and I’ve only been reading one book every few months. Part of the reason for this is that I’ve simply been distracted by other things. Home life, career, finances, programming, gaming, movies and other things have meant that I just haven’t read as much. This isn’t about limiting what I’m reading, but having more time to read by limiting other distractions.

Podcasts

Since I started freelancing I’ve been subscribed to a number of podcasts that focus on this topic and on the Ruby programming language. Truth be told, I haven’t listened to anything on this topic in the last month. It’s merely due to the length of the podcasts themselves. At over an hour each, I find it too long to listen to these. I’ll be unsubscribing to all podcasts with the exception of three. I haven’t decided which three yet, but I need to put a limit in place here if I’m to get any use out of them.

RSS Feeds

I’m currently sitting at just over one hundred RSS feeds in Feedly. Quite a lot if you ask me. My aim is to get this down to 50. Maybe two or three RSS feeds for each topic and selection of my favourites to take it to 50. I could never completely stop using RSS feeds. I find it such a convenient way of reading good content from my favourite blogs.

Half the feeds I simply skip over these days as I’ve found that some blogs just aren’t that active anymore.

Subscriptions

This is paid subscriptions to things such as Railscasts or Caesura Letters.

I’ve got a couple of subscriptions in here that I could do without for the moment. Cutting the subscriptions back that I don’t need at the moment would give me back time to be doing other things.

One thing I have found though is that the email subscriptions I have can largely replace some of the blogs that I am following. Although this does mean more emails hitting my inbox, but my email is quite healthy these days with everything labeled and routed to the appropriate folder when it arrives in my inbox.

I want to make things

Rather than digesting, I need to be producing. Whether it’s a service, product, application or some writing, I’d much rather be making things than reading about what others are doing. In the past I’ve been guilty of worrying too much about what others think and maybe distracted myself with a dig into what’s in my RSS feeds that day. Maybe it’s time to get over that and simply produce something that will intentionally make people think.