So if you want to come up with organic startup ideas, I’d encourage you to focus more on the idea part and less on the startup part. Just fix things that seem broken, regardless of whether it seems like the problem is important enough to build a company on. If you keep pursuing such threads it would be hard not to end up making something of value to a lot of people, and when you do, surprise, you’ve got a company.
Recently I was looking into services to offload my new web-app’s email delivery to. A quick search brought up two appropriate services:
PostageApp
PostageApp go for a cheeky, fun, cute design which makes the product feel very accessible. They use illustration on their central graphic, video demonstration, and wonky heading underlines. It is a great design element but feels misplaced on an email delivery service.
I am a big fan of illustrative design. It adds character and fun and can work brilliantly to soften and simplify complex concepts. A great example is Google’s demonstration video for Google Voice.
On PostageApp though it seems to cheapen the product. My web-app’s email demands are not glamorous, sexy or fun! It is critical to my product’s success. The traits I am after in a provider are reliability and professionalism. I am looking to take away the stress and hassle of delivering email. I don’t want to hand over my email responsibilities to a comedian. The company may be having fun but I don’t need nor want to know!
SendGrid
SendGrid on the other hand go for a corporate design. They have thought hard about what their customers are actually buying; peace of mind and security. A prominent counter proudly displays the number of emails their service has sent and I am informed that 3744 other companies currently use their services. This makes me feel that choosing them is the right decision. Cleverly, rather than saying “Thousands of companies use our service” they give me an exact figure, which adds authenticity.
Which did I end up choose?
Both PostageApp and SendGrid target the same audience. They both claim to solve my problem. In an ideal world I would sign up to both and test the integrations alongside one another over an extended period of time. However the real world with it’s time constraints doesn’t afford me these luxuries. As a new customer I have no experience of the quality of these services so I am forced to make judgements. Fickle as it may be first impressions count. Rightly or wrongly I went for SendGrid.
Sure business was about money. That’s what makes it business. But first and foremost, to be successful, business is about people. It took me a while to learn that lesson.
When a customer buys your web application they are not really buying the software. Sure the software is what they get but it is not the reason for their purchase.
Take a backup service such as MozyHome. The user is buying an application which will index the files on their computer and upload them to a server in the cloud. But what they are actually buying is peace of mind and security.
When I purchase a chocolate bar I am buying more than cocoa; I am buying comfort and pleasure. I don’t buy a Mars bar because it gives me piece of mind and by the same token I don’t buy MozyHome because it gives me pleasure.
I am working on my first ‘for sale’ web-app, Flaregun, which helps people manage their domain name registrations. Questioning why a customer would buy my software has highlighted the personality I need to create.
Flaregun falls into the peace of mind and security category. As such the design needs to be fairly serious. The copy should be formal and professional (nobody wants a comedian looking after an importance business service) and the application’s personality should assure the customer that everything is under control.
Designers and marketeers have been thinking and analyising buyers motivations forever but it is something that is easy to overlook in software. Thinking about the underlying motivation of your customers will help steer your decisions and create the right type of personality for your web app.
Last week I stumbled upon SnapABug, a feedback form widget. My heart sank. I had just released my own feedback widget, Barometer, the week before.
I signed up for a SnapAbug account to see the ‘extent of the damage’.
SnapAbug had been around for a while and contained lots of additional advanced features. When you submit a bug via a SnapAbug form your system details, such as your browser version, operating system and plugins, are sent to the website’s support team. In additional to this raw information SnapABug uses some clever Javascript to capture a screenshot from your browser. This extra diagnostic information is infinitely useful for a support team and invariably cuts down the bug resolution time.
SnapAbug also provides some appearance configuration tools so you can choose the colour and position of your feedback button, or even upload your own to seamlessly integrate with your website’s design.
I felt I had wasted my time building Barometer.
This product which I had failed to find during my research appeared to solve the same problem and do it better. I would have to implement SnapAbug’s additional features to salvage the time I had put into Barometer.
However over the preceeding days I realised that Barometer and SnapAbug were not the same product. If I implemented these additional bug fixing aids, Barometer would no longer be a simple feedback form. Barometer was a reaction to the complex social support systems such as Get Satisfaction. I just wanted a fast and easy way for someone to get in touch with me from any page on my website. That was it.
SnapABug is about bug fixing. Get Satisfaction is about social support. Barometer is about getting in touch with the author of a website.
Unlike SnapAbug, Barometer’s primary purpose wasn’t to help fix bugs. I rarely receive browser bug reports from from Barometers installed on my own websites. Typically I get questions about future features, a website recommendation, a job offer, a request for source code, or an idea for a blog post. In all of these situations knowing my user’s Operating system, Java version number, or screen resolution is irrelevant.
I also considered removing the ‘Subject’ field after seeing that SnapAbug only has fields for ‘Message’ and ‘Email’. Removing the subject field makes the form simpler. Why did I not think of that! I am all about simplicity…. But then I started to think about what subject lines are actually for. My form is for quickly sending an email. The subject line of an email adds to it’s value. Therefore it was relevant in Barometer. This is another example of Barometers purpose dictating it’s feature set.
So I will not be implementing the features in SnapAbug as my first instinct told me I should.
Finding a ‘rival’ product has taught me some important lessons:
- Research the marketplace extensively before committing to building a new product.
- Have a unique purpose and vision.
What’s the point in duplicating someone else’s idea? You may as well leave them to it. Vimeo is a video service like YouTube but it serves a different market. As a result it seems to be working. If I set out to build YouTube I will fail. If I set out to build Vimeo I will fail. But if I build a video service with a new interesting purpose I give myself a chance of succeeding.
- Remember why your originally created your product and the problem it solved.
Write this down and put it somewhere you can refer to.
- If someone else is doing x it doesn’t mean you have to do x.
Blindly copying a feature means you skip the thought process and could see you doing something which is wrong for your product. Always refer back to your product’s purpose when deciding on new features. Learn to be strong.
- Only build something you are passionate about.
If you are scratching your own itch then you will instinctively know what is right and wrong for your app and won’t be easily swayed by the competition.
- Know when to cut your losses.
“Whether your activity is a trivial one or a huge one, don’t stick with it because of the time or money you’ve already put in. That time/money is gone: you’ll never have it back. What you can recover, though, is the future time or money you’d otherwise be spending” - Knowing When To Cut Your Losses and Call It Quits
If you find something that does exactly what you are doing and does it better, it might be time to cut your losses. Playing catchup is not a good place to be.
Closing thought
Know what your product is about and don’t let the competition determine your actions. If you do it will no longer be unique. It will no longer be the thing you set out to create. It will no longer be YOUR product.
If you try to start a startup right out of college and it tanks, you’ll end up at 23 broke and a lot smarter. Which, if you think about it, is roughly what you hope to get from a graduate program.
The idea for Barometer came when I wanted to add one of those black feedback tabs you see scattered across the internet to one of my website. The online services I found offering them were fully blown community support systems which were overkill for my needs.
I tried out the actual feedback forms and found they were cluttered and often forced you to sign up for an account just to leave a quick feedback message. The feedback form was data-mining. This seemed wrong when I was doing the website owner a favour and it surely would reduce the amount of feedback other people would send. I couldn’t find any web service which offered me the quick, simple, hassle free form I wanted.
Barometer is that missing free service I was looking for. Barometer allows anyone to instantly add a stylish Lightbox, AJAX, feedback form to their website, without having to do any custom coding. Using “The world’s quickest signup!” Barometer creates a few lines of HTML code which you simply copy and paste into your webpage’s footer. Simple, effective and free forever.
The low down:
Barometer's feedback tab.
- Hide your email address to avoid spam.
- In-page form tab increases user feedback rate.
- Simple fuss-free form. You won’t find a fully blown community support system here.
- Receive feedback into your normal inbox - no login required.
- The world’s simplest signup. No data capturing here!
- Completely free. Forever.
Find out more and get your own Barometer at http://getbarometer.com.
The only acceptable response to a feature request is: ‘Thank you for your feedback. I will take it under advisement and consider it for inclusion in a later version of the software.’
Since starting writing this blog last year I have naturally developed a very specific writing method. Here are the various stages that I go through.
The idea
It all starts with an idea. Usually my posts are based around the experiences I have had over the previous week or month. I like to write posts which are reflective of my current work and thinking which will still be relevant in years to come e.g. Improving your web apps personality with a language file.
I keep a list of potential future blog post ideas but often these become stale. I feel at my best when I have a spark and run with it.
The post setup
I create a new Google Document and assign it a working title. This post was assigned ‘My blog writing process’. I like Google documents as it ensures my writing is backed up and safe whilst providing enough features for the task at hand.
I write the following headings in bold with spaces in between them:
- What am I trying to say?
- Actual post
- Potential titles
- Unused
- References
I then proceed to fill in the gaps.
What am I trying to say? (Aka the plan)
An example plan
I tend to either find it too hard or too easy to start. Both lead to problems. A quick bullet point list of the main points I am trying to make helps create a focused piece of prose and gets me over the initial ‘pen to paper’ hurdle. I also find my short ‘plan’ is useful when editing, ensuring I haven’t strayed from my initial point; on a couple of occasions it has helped me split one long rambling post into two short focused ones.
References
My posts usually involve some research. I often include quotes to add visual interest (more on this later) and I link out to detailed information. I copy the URLs and potential quotas under this heading, to use later on.
Actual post
“Write your first draft with your heart. Re-write with your head.”
- From the movie Finding Forrester
Has the word processor made writing easier?
This is where I start writing. I find I don’t write the post from start to finish, but instead write the various paragraphs as they come into my head. Sometimes I write a sentence or paragraph that reads and conveys a strong message, but doesn’t seem to fit anywhere. Instead of deleting it I cut and paste it under the ‘Unused copy’ heading. Sometimes I find a place for it later. Usually it won’t make it in. Importantly moving instead of deleting gives me this option.
This process feels like a programmers way to write. Move text around, shortening, commenting out, and trying different paragraphs together. A process of re-factoring.
I try to stick to my original ‘plan’ but find that writing unearths new insights and ideas. For me writing has become a learning process. A tool to order my thoughts. I often find several potential titles pop into my head during the process, which I will place under the ‘Potential titles’ heading.
The editing process
“There is no great writing, only great rewriting.”
-Louis Brandeis
“The letter I have written today is longer than usual because I lacked the time to make it shorter.”
– Blaise Pascal
There is some great information about editing.
For me the key is reducing the fluff. We are almost always too wordy. Every sentence should say no more than is necessary. Every word should fight to stay. Every sentence should be necessary. Don’t be afraid to knock out a sentence or paragraph if it isn’t adding anything.
Editing is a real skill, which up until recently I didn’t fully appreciate. As within anything, practice leads towards perfection.
This is also the time to check for spelling and grammatical mistakes.
Into WordPress we go..
When I have a post I am happy with, I copy and paste the ‘Actual post’ into my blogging engine of choice, WordPress. I like to think of this step as prepping the text for the web. I add the block quotes to make my referenced text stand out, add in the links, and make the headings bold. I also link back to previous posts I have made to prevent re-iterating myself and to provide my user with a more fluid browsing experience.
Optimising for the web
“Writing for the web is not the same as writing for print.”
- LSE article on Writing for web
The web is not print. People use and interact with it differently. Web readers rarely read word by word; they scan for headings and keywords. So we need to account for this by adding some visual interest to break up long unwieldy text. A few simple techniques:
- Shorten paragraphs - split one paragraph into two if necessary
- Add headings
- Highlight keywords - This is a new additional to my styling method which I saw used extensively by Derek Sivers. I like the way that it drags the eye into paragraphs and breaks up chunks of dense text.
- Use lists
- Add images - The images don’t actually need to be completely relevant. An image of someone in a hammock when talking about motivation instantly makes your posts more inviting. Including a short informative or questioning caption adds another level of interest.
Read it out loud
“Reading a piece out loud helps you to identify clunky, awkward passages that seem to make sense to the eye, especially to the author’s eye.”
- Lifehack.org
This is my final editing step that I have to force myself to do. It feels silly but really helps you see your writing from a different perspective.
Choose a final title
After approving the final version I pick a title that best reflects the overall feel of the post. I prefer using interesting fun titlesinstead of purely descriptive ones. However perhaps this isn’t the best route for SEO. A good compromise is mixing the two to create a title like Show your web app some affection - the KISS principle
Leave it to settle
Thinking of your post like a printed document encourages proof reading.
The web has given us the ability to edit a text after it is published but does this mean we should?
Is an edited document still valid? Clearly it is no longer the same document. If someone wants to reference or quote it they are pointing to a moving target.
From a technical standpoint a title change will send a duplicate post to RSS readers and your twitter post will contain the wrong title. You could delete the Tweet and Tweet the new title, but your followers will then receive a duplicate link in their timelines.
Learning from my errors I have come to the conclusion that a blog post should be like a newspaper story. If there are errors or changes, a note should be appended to explain any changes that were made.
Publish it
Finally I am ready to go live to the world.
