Kablingy

I attended Startup Weekend Dublin 2010 along Kevin Noonan, Darragh Curran, Declan McGrath, Sean Coughlan, and Mike Hughes. You have to build a business in 2.5 days. Good fun had by all.

Lessons learned:

1. Meet your team before-hand

2. Stay disciplined and follow good practices. Integrate software often, test your code, keep your code clean, pair program, and have quick stand up meetings. It'll pay off in the last few hours when panic sets it.

3. Your execution of the idea doesn't really seem to matter to the judges. It's your business case and how 'novel' your idea is are the things that get the bigger points.

4. Bring a DVI monitor connector so you don't look like an idiot when you try to do your presentation on your macbook.

We got 3rd place for classometer.com. We plan on getting it ready for the world soon.

This is based on a few horror stories we've heard from customers recently, who were unhappy with their previous software provider.

Here are 5 questions we think most software consultancies aren't asking their customers. 

1. What are you quantifiably trying to achieve?

Before you hand over your money for software, it's worth asking what you want to achieve from this investment. Do you want your new software to generate a 5% increase in foot fall? Perhaps you'd like €2000 per month deposited in your bank account while you sleep? If nobody asks you this question, then it's a little difficult to know if the software project was a success or not. If you don't think about how to measure success, then your software consultancy will undoubtedly claim it when the project is finished.

2. Why do you need new software and is there any existing software that would do the job? 

Another way of asking this question is "What would be 90% as good, but would be 10% of the cost?". Quite often, a combination of some existing software services e.g. Highrise, Dropbox, Youtube & Overtake (shameless plug) will allow you to achieve most of what you want at a fraction of the price of a perfect, custom and expensive software solution.

3. What is the absolute minimum feature set you need?

If you have a new idea for a software service, and you're not sure if it's going to work, then don't invest upfront in unnecessary features. For example, there's no need yet to build a fantastic user administration and reporting system. Why? Because you don't have enough users yet to necessitate it. You don't have any data to put into the report.

Remember that most software consultancies will be happy to take your money and build unnecessary features for you.  Also, forget scalability for now. You don't need the $1000 hosting package, yet. Concentrate on the bare features needed that will give you the feedback to know if the project is going to be a success or not. If a project is destined for failure, kill it as early and as cheaply as you can.

4. Who are the different types of users?

Identifying 3 or 4 archetypal people by name that will use your software is invaluable to the design process. Speaking in terms of what "Jim the account manager" or "Kate the sys-admin" needs is far better than always referring to The User, or as we call him - The Elastic User. If you build a system for the elastic user, you'll probably end up with software bloated with features. However, by defining user personas, you will be able to identify what features are important for what persona, which is the most important persona to satisfy, and more importantly what features can be eliminated from the system.

5. Who owns the code?

In our opinion, this question doesn't get asked enough, even though it's pretty simple to answer. If you pay us to build custom software, you own the code. If you use one of our software subscription services, then we own the code for the service and you own the data you put into it. We also recommend that you pay for the server hosting directly, and own your website domain. This will avoid any unpleasantness if and when you want to switch software providers.

It's a good idea to have a section covering these points in the Master Services Agreement with your software provider.

You do have a Master Services Agreement, don't you?

Recently I was in the market for a customer relationship management (CRM) tool. I wanted something to track leads, contact dates, and I wanted to store a plethora of custom information with each new lead/customer.

I tried out some open source tools, but they were too complicated for the job. Highrise didn't have what I wanted for this particular purpose. So I tried one out one of the CRM/SaaS market leaders. Let's leave them nameless for the post.

Within 30 minutes of signing up online to try it out, the sales staff phoned me. Holy moly, what quick customer service! Peter, the chap on the other end was delightful. He asked me all about my CRM needs, my business, and touted the benefits of his CRM online service. He was a genuinely pleasant fellow. I raved about the customer service after the call. Unfortunately, Peter set me up for a follow up call with... an account manager.

Enter the forceful salesman.

Bill the account manager emailed me 10 nanoseconds later eagerly looking to arrange a call with me. A day passed before I emailed Bill back. I had solved my CRM needs in the meantime with something much cheaper that his solution, and so I emailed him back to politely decline his offer.

This didn't suit Bill.

Bill ignored my email and phoned me back the very next day, clearly juiced up on one too many orange mocha frappachinos. He was aggressive, dismissive, and never gave up on the sale. He was everything what you would expect from a forceful salesman. I told him annual payments were so 2007, but he parried with quarterly payments.  I told him I disliked lock-in contracts and favoured 37 Signals style, 'cancel anytime' policies. He informed me that they'd be out of business in 8 months.  I told him his user interface was too complicated for me, he countered with the offer of an in-house demonstration. But my favourite part was when he turned IBM on me and started to talk codswallop about The Cloud.

The Cloud, man.

"Steve, you could have your leads integrated with your Facebook, your LinkedIn, your Twitter. If you don't leverage The Cloud, you're going to get left behind. The Cloud is the future of selling."

The call ended there as the cow manure detector was off the chart and I've been known to get belligerent towards the parties of fear, uncertainty, and doubt (FUD).  What a real shame that the whole affair spiralled from "What great customer service!" to "I'm gonna blog about this jackass"

In the meantime, our CRM solution which is a custom Rails application that we built, is serving our needs nicely. Let us know if you need some custom software done right.

Today a van driver almost ran me over. (That’s him above). The details aren’t important, other than he was driving like a maniac in a business car park. It was a quick reminder that we can lose our lives in a flash.

An hour later when I started breathing again, it reminded me that a successful business is more than just the product. The product is probably the least important part. It’s about the systems used to build and distribute the product, the communications used to sell it, the legals used to protect it, and of course the cash flow.

Today’s experience reminded me I need to concentrate less on the product, and more on developing a system that allows me to be killed by an idiot in a blue van and the business keeps running fine without me.

We just returned from the 2009 Meath Enterprise Day, an event organised by our client and friends at Meath County Enterprise Board. Today we lent a helping hand by setting up some online surveys using SurveyMonkey where participants were entered into a draw.  It struck us shortly before the results were to be picked, that we had no elegant way to choose the results.  It was nothing that a little Rails application wouldn’t solve.

Half an hour later, and thanks to SurveyMonkey’s export features, we had this little doozy which allowed an independent judge to choose the winner.

The end result is hardly rocket surgery, but the feeling of having a daft deadline, several hundred onlookers, and no margin for error is still intense and exhilarating. Making a real world app in 30 minutes will test your programming kung fu and ability to focus under pressure. Try it!

P.S Congrats to the prize winner: Clayton Coyle.

As a consultancy,  how can we define project success?

Typically in a project, a client asks for features and a software development consultancy delivers those features, hopefully on time, on budget and to a professional standard. Then everybody claims success.

But how do we know if it was a success? Did we really fail? Could we do better than this?

We think the best way to address  project success is to first understand the project stakeholders' real requirements. The problem is that even the most enlightened agile developer can mistake features and designas project requirements. But by continually asking why, and not how, we can fish out what the client really requires. Consider the following example:

A sample set of  so called "requirements"

The client needs us to develop a web application with the following must have features:

• Users can sign up for free and upload and sell their own books
• Room for Google ads, and sponsors.
• User can upload their own avator and connect to  authors of the same genre
• Forums
• Integration with MySpace, Twitter
• Facebook App

This is not untypical of the kinds of applications we are asked to build. However, if we continually ask our client why (5 times will do the job) she wants these features, we might actually get to the real requirement which is:

The client wishes to increase her passive income by €2000 euro a month, within 6 months

Now that's a requirement and that's exactly where we should start the conversation.  Now we can start to talk about things like the business model  e.g.

• Why is she offering a free sign up? Why not charge her users a flat fee per month or percentage of the sales? 50 subscribers on a €40 a month plan will achieve the goal in a more predictable manner than advertising. Not to mention, can she realistically get enough traffic within 6 months to justify the advertisers fee?
• We might ask her if she would consider trying to aim her product at businesses instead of the consumer, since businesses are usually happy to pay for services, while consumers expect everything for free. Would she consider working with a dedicated sales team to get those 50 subscriptions within 6 months?
• Why bother inventing adding social network features when she could integrate with another established one or avail of a social networking platform service. Will the social network aspect help her to achieve the €2000 in 6 months goal at all?

And so on. You can see how this way of thinking can drastically alter the list of must have features from above. Perhaps the feature list now looks like this:

• Build a subscription based service aimed at professional authors. Authors get a shopping cart and microsite CMS with a spot for video blogging. Charge 40 euro a month for this service.
• Sample chapter of the book can be downloaded as a watermarked PDF
• Offer an auxillary service connecting authors with publishing companies

So coming back to the title of this post, how could we define project success? How about this.

• Get the real requirements. Make sure they have been quantified. If you're feeling saucy, you could even consider a requirements specification language like planguage. Don't be put off by the phrasespecification language, it's quite accessible really and not at all stuffy.
• Get your stakeholders to prioritise the top 10 requirements. Each requirement fits on an A4 sheet of paper. There's no need to mention features - that's for the design and development team to figure out.
• Drive the design from these requirements
• Then, do all of your usual wireframing, test driven development, iterative planning, continuous integration and all that good stuff etc.
• Measure continuously and communicate with your stakeholders on whether the requirements are being met, and thus if the project is going to be a success.

The masters in this department are Tom and Kai Gilb. Take a look at their site, publications, and free books for a wealth of information on requirements gathering and measuring project success. It's exactly what's been missing in the Agile software movement.

Getting started on a new project can be daunting sometimes. It can be difficult to know where to start when you first sit down with your customer and have to extract requirements from them in a structured manner. When I'm stuck, I mind map.

First I draw a central image with the project title.

Then I draw a branch for Users. I will start to ask about the different kinds of people that will use the application I'm about to build. These days subscription based web applications are all the rage, so that means there's usually at least  3 personas can be identified. So I'll sketch up Barbara the account owner, Julie the web application administrator, and Bill the customer.

Inevitably, that quick discussion will help me to spot at least 5 domain objects. So now I can do a little boxes and arrows diagram of the object relationships between User, Account, Subscription,Plan, Role. As we run through the scenarios of each users, more domain objects present themselves. During this discussion we might also identify more users which we can add on to the Users branch.

I usually draw a branch for business model also, as I really want to understand how the web application is going to make money. It’s a top priority for me that I build just enough software so that the client can get a ROI as soon as possible. Otherwise I run the risk of saying yes to every feature and building an application that doesn’t generate enough income to cover its initial investment. That's bad.

In mind mapping the business model, the users and their scenarios, and the domain model, the project will start to take shape very quickly. Mind mapping around the whiteboard is also a great way for your client to interact in this process. As you draw branches, she’ll immediately start to fill in the gaps of the map, and since it’s very visual and colourful, it sticks in the memory. You’ll find that you can wipe the board and redraw most of it from memory without even trying.

Give it a go – 4 markers and a whiteboard is all it takes. Don’t forget to take photos of it with your camera or phone before you clear it.

Today is a public holiday. We're currently on a crazy sprint to get a project finished, so we're taking advantage of the public holiday today.

Below are photos of the business park that we work in. This business park is mostly populated by small businesses. Yet, as you can see, it's like a ghost town and the shopping malls will be quite popular today.

If business owners want to take the day off and shop in the mall, then that's great. But let's not kid ourselves that this recession is as bad as the 1930s. Clearly, people are not affected by the current economic climate as much as the media would have us think.

Building a successful business involves building a great team. I don't just mean a team of fabulous designers who can out-web-2.0-gradient-shiny-floor everyone else, or developers who can recite the Ruby String API from memory. I mean the people in the background - accountants, tax advisors, solicitors, the bank manager, financial planners, sales consultants.

We've been through a few of each and we're lucky to employ the services of a few great professionals. But there's probably one trait we look for above all when investing in a relationship with a professional - rapport. In other words, can we get along and have a laugh together? And I don't mean the freaky NLP mind control stuff.

I'll choose a professional who drives a Polo but can put me at ease with things like preliminary tax returns and B1 forms over one that drives a Porsche but only calls me 1 day before the end of year returns. Transparency, openness, competence, but above all rapport.

So if your tax advisor doesn't answer your emails or your accountant scares the hell out of you, it might be time to look elsewhere.

Because it's when you're having a coffee with your professional that you get the really great advice.

Kablingy attended FOWA Dublin. It was great to take a little excursion from doing the hustle to see what others are upto. My favourite talk was by Ryan Carson and his lessons selling web apps, based on the acquisition of DropSend.com. Noteworthy advice included:

• No free accounts! Although this point came in later in the talk, it stood out in my mind as the most important one. Users of the free account tend not to upgrade. There are other ways to entice the user such as allowing them to try out the product without any signup.

• Don’t build your own billing engine: I totally agree with this one. Building billing engines can be a quagmire, and I’d rather avail of another’s expertise. Ryan recommended spreedly.com and I shall definitely be checking them out. Notice the “You can set up and test everything with a free account – no strings attached!” wording on their website. I am now enticed. Notice the difference with another  SaaS company, OpSource (formally LeCayla) – “Contact us to discuss how we can get started”. Come on guys, I want to try your product but you’re not making it easy!

• Form a new company for your product: This is one that I hadn’t considered fully, but it makes total sense. It’s much easier to buy a seperate company than to untangle a product and integrate it into another company. The administration costs I’m sure would be cheaper in the long run.

• Invoicing: Send your customer a proper invoice. Ryan suggests using an online accounting solution called Xero.

• Charge in USD Dollars: This makes sense. There’s a much bigger market willing to pay in US Dollars, than in Euros. Exchange rates etc. should be taken into consideration.

• 1 click administration: To build up goodwill, Ryan recommends having admin features such as 1-click forgot password, 1 click refund, 1 click ‘give customer credits’ etc. He says it’s just not worth arguing with an unhappy customer, just give them the refund or $10 to sweeten them up if they’re unhappy. I like this idea a lot.

• Perform usability testing at the wireframe level: He recommends a wireframing tool called balsamiq. It looks very cool. Wireframe mockups in minutes. I shall be trying this one out too.

• Know your numbers and stats: One should know by heart the number of visits/day on your site, the cost per user, margins etc. Very true.

Contrast were entertaining and informative on their talk about conventions and when to use them and when to break them. Robin Christopherson reminded us of the importance of accessibility and the tyranny of captchas. DHH once again encouraged others to build an actual business, not based on VC funding and foosball antics, but one using his controversial business model:

Not sure a crazy idea like that could work in the real world!