Grads, where are your blogs?

MailGuard is at the end of the hiring process for a new junior marketing assistant. We were looking for someone with less than a year’s experience to help with some cool stuff and be cheap. The candidates that made it to my desk had already made it past the first hurdle. I had a dozen or so applications to review.

Oh dear.

The best advice I can give is prove you are interested in the discipline you are being hired for. This applies ten times if you don’t have if any experience. A blog is the best way to do this because it shows me your personality, thought process and passions. Portfolios and Github commits show off your skills, but not who you are. When I’m hiring at this junior level, I’m looking for someone to mentor and invest time in. I only want to mentor someone that is interested and invested in their own development.

Your degree puts you on equal footing with everyone else. How are you proving that you’re better!?

I’ll make it easy for you. You only need to start blogging in your last year of studies. By this time you should know what kinds of jobs you want. Content matters, not design. Write about a topic you studied. Write about related news. Write about companies you like. Do that once a month.

Make me excited to get you in for an interview. Please.

Shutting down Dibbist: mistakes and lessons

Recently I posted about the results of my cold call experiment for Dibbist. Last week I closed down the online appointment service. I made that decision because I had made a lot of mistakes and wanted to do it right with CS Workflow. So what were these mistakes?



Not understanding assumptions

Dibbist was designed to bring the technologies and best practices of web and mobile development to small businesses. It allowed service businesses to take appointments and promote their services online. These are things that small businesses should be doing and care about. However, I didn’t look at the assumptions I’d made. Did businesses care? Were businesses looking for ways to improve their operations and marketing? The reality was that both assumptions were false. The businesses in my segment were focused on serving their clients and not on technology or marketing.

The funny thing is that I didn’t even consider I was making assumptions. From my perspective, I was building a service that was needed, whether prospects knew it or not. Success was just a matter of effective marketing. This led to a poor product-market fit. It even meant I didn’t have a clear market. This was the biggest mistake by far and could really be the summary of Dibbist’s failure.


Unconfirmed marketing channels

I’m a product guy, so I focused on where I felt comfortable. I did have a plan to attract traffic through SEO, blogging and reaching out to industry associations. But before launch I made no effort to build traffic or understand how associations worked. Bad move. Building traffic takes time. Associations are generally administrative outfits and aren’t focused on helping their members. Instead they prefer you to advertise, which is very expensive when compared to online advertising.


Unbalanced co-founder commitment

My co-founder worked full-time and wasn’t able to commit much time to Dibbist. This meant I had all the downsides of having a co-founder (conflicting opinions, reduced equity) and none of the upsides (shared workload, support). My co-founder was a long-time friend, who I felt I couldn’t fire. We had also a simple partnership, which meant 50/50 ownership, with no vesting or other provisions.



Some of the lessons are direct responses to my mistakes and some are things I wish I knew a year ago.


Work through assumptions

Assumptions need to be identified and assessed before doing anything. This is a scientific process of stating the hypotheses and methods to test them. Everyone that knows anything understands this. However, very few people do it. Almost everyone I know involved in startups have untested assumptions, or think assumptions will be sorted out at launch. After Dibbist, and a few other projects, I now won’t do anything until all key assumptions are confirmed to be true. Any assumptions proved false mean a rethink and a pivot.


Talk to customers

This is part of working through assumptions, but also has so many benefits beyond that. I’m naturally shy and reserved, with some fear of talking to people I don’t know. In my mind it’s going to be awkward and I’ll come off looking stupid. I didn’t talk to customers at all with Dibbist. I started doing it with CS Workflow and everyone that I’ve reached out to has been really nice and helpful. I’ve asked what some pretty stupid questions, but have only received supportive. This is now my favourite part of building a startup.


Build an audience

I’m completely onboard with building an audience as most effective marketing method. I’m working on this now, and learning as I go. I’m focused on adding value and communicating with my small audience as much as possible.


Be a one man band

Since my experience with Dibbist I’ve been very cautious about co-founding. I’ve quit projects where the co-founder relationship isn’t ideal. Now it’s so unlikely that I will find a suitable co-founder that I’m not even going to try. I also don’t feel like I need one. I have a pretty good support network of experts and advisors. My wife, Vicky, helps to lighten the workload. For me, going solo is the ultimate in bootstrapping.


Have a clear strategy

A clear strategy sets the direction against which all decisions and priorities can be tested. This is how I make sure I don’t waste time. There are so many distractions and so much advice that unless I ruthlessly stick to my vision weeks can fly by without any progress made.


Know your brand

Most people think brand is about logo and colour scheme. Brand is really about the identity of your company. I think this important because it creates a personality and set of values that I can get behind and promote. Without a defined brand there’s a tendency to fill the void with the founders own values, which may or may not align well with the expectation of the market.


Design is about user flows

I had the privilege of working with some great UX specialists. This biggest thing I picked up is to focus on user flow through the use cases. Doing this, instead of starting with wireframes, creates a more comprehensive solution that makes sense from start to finish.


These are the main lessons from my year with Dibbist that have been seared on my brain. I plan to write a series of posts to cover these topics and more in more detail. I’ll focus on the one man band theme. The aim is to help others and get feedback from more experienced people to build up my own knowledge.

CS Workflow is now taking registrations of interest

Copywriters can now register their interest for CS Workflow. You can do that here:

I’m building an application specially for copywriters to make the review and approval process as painless as possible. If you’re a copywriter or have managed content projects, you’ll know how hard it is to get good feedback from reviewers and compile all that feedback into changes.

CS Workflow will manage the process, guiding and teaching reviewers how to give great feedback. It is a web-based application, so it accessible from any Internet-enabled device. Integration with other services and platforms is straightforward, making importing and publishing content easy.

This service is inspired by a blog post by my good friend Max Johns about giving and receiving web copy feedback.

The next step is a closed beta to perfect the feature set and process flow. Register you interest to receive an invite.

Feedback is always welcome and I’d love to hear more stories about your specific review situation. Email me at

My experiment with cold calling

My first real product was launched last year. Dibbist is an online appointment system for small businesses. I’ve failed to attract any subscribers and I know all the reasons why. I’ll do an more in depth post about what I did wrong. This post is about my cold calling experiment for Dibbist.

I have connections to an owner of a small BPO (business process outsourcing) company. BPOs are always looking for ways to make money. One way is to find an easy to sell product and cold call to a script, taking commission on generated leads. My connection was happy to see if it was possible to sell Dibbist. The purpose of the cold call was to propose a trial to the contacts. This was pretty straight forward. I created a call flow and a detailed fact sheet that provided everything someone would need to talk through the product.

The arrangement was $2 for each generated lead (someone agreeing to a trial), plus $1 if the lead actually signed in. 20% commission would be paid if the lead when on to subscribe. The commission would apply to the first year of the subscription.

I already had contact lists from scraping the national yellow pages. This gave me phone numbers, and for some websites and email addresses. I went through the lists and pulled out any businesses from the list that both fit Dibbist and I could find a contact name.

During the 3 day trial the agent called 159 contacts. 13 agreed to a trial. 2 of those 13 provided fake email addresses.

I provisioned the 11 leads in Dibbist and sent a welcome email, which guides them to log in to their account. None have. 1 of the contacted businesses did come and check out the site.

Obviously this was a failure, but it was really interesting. Going through the contact list gave me a really good idea about the businesses in the market I was going after. I’d made assumptions that this research proved wrong.

The main thing this campaign confirmed is build an audience.

PeepCode’s Ember tutorial is essential

From my previous post on my learning progress, you’ll know I was running through a few Ember tutorials. Through these I learnt a bit, but I wasn’t grasping Ember’s MVC concept with the single model example apps. I was starting to feel like an idiot.

Fortunately, an off topic comment on Hacker News lead to me pointing out the tutorial limitations. A kind gentleman pointed me to the Ember tutorial on PeepCode. It was obvious from the description that this was exactly what I needed. There were screenshots of an example app with multiple associated models in the same view. Perfect.

Now that I’ve finished passively watching the lesson (not coding along), I know perfect is the perfect description. The tutorial didn’t only show how to create a multi-model app. That’s what I thought I needed. I really needed a solid explanation of the Ember basics. I needed to properly understand Ember’s MVC concept. I needed to be shown the automagic of Ember’s non-coding.

Summary: If you’re new to Ember start with PeepCode’s Ember tutorial.