Caerphilly Accelerator

I have just finished mentoring a group of 4 start-ups as part of the Caerphilly Ice accelerator.

It was a very interesting and rewarding task... and if I'm honest, I learnt a lot from the group as well!

To be more accurate it was more of a Pre-Accelerator. There were 12 companies in total, spread over three cohorts each with their own mentor. They were in a variety of stages, with some of the “companies” being not much more than a person with a good idea! Over the three month program the aim was to get all ideas to become companies that were “pitch ready”. As this was the first time the Accelerator had been run it was a learning curve for the organisers, but the facts are that it was a success with some of the companies securing funding during this period.

As a mentor, my involvement with the accelerator was to act as a coordinator and lead in our monthly “mastermind sessions”. These sessions were new to me but worked really well. Each company had a session focused on themselves, but the group collaborated together as a whole during these sessions. It is noteworthy that a lot of the learning happened by people seeing the problems in the other companies rather than themselves. Its obviously much easier to see fault in others than in oneself! This is especially true for me and how I got a lot out of the program... I could see many of the issues my cohort were experiencing were replicated in my own ventures. Having the group “brain storm” ideas was enlightening. As for the specifics for my 4, I'll describe them in more detail.

First up was Tony, who had the most comprehensive business plan I have ever seen. He had an idea for a Messenger/Chat style app. I can't go in to detail, but his USP actually means I believe he has a chance in this congested space. I think the program benefited Tony as he made two realisations. 1) the pitch needs to explain the concept as simply as possible AND quickly 2) every pitch needs to be tailored to the audience. i.e. drop the techno jargon when speaking to potential investors! His comprehensive business plan is now believable!

Second is Mike with ideas based in the Bot or AI space – meetmaia.com. At first all he really had was some ideas with a few tentative technical examples. Over the three months it was interesting to see him realise that developing a platform that can do anything means you can not target an audience to sell to. By the end of the program he had settled on an intelligent assistant/bot to enhance existing sales CRMs and created a company/product called Maia. The tech always had the potential to be impressive, but now he knows who to target he has the chance to build a company that is equally impressive. His “pitch” sounds good and I hope he gets funding. His idea sits well with some of my other commitments (namely AgileChilli) so I'm sure I'll be continuing to be involved.

Third was Gem – mifuture.co.uk. An ex-teacher, her start-up had been up and running for almost 9months when she started the program. She is targeting the careers market for 16-24 year olds. The program opened her eyes to some of the issues of setting up a double sided platform, but mostly it has helped her produce a polished pitch. It also helped identify the potential barriers and objections customers would have. Luckily we also came up with a few solutions.

Finally Brooke – koherent.uk . I had a head start with Brooke's idea as it was in the Estate Agent industry. Specifically, he wants to tackle the problem letting agents have with instructing 3rd party contractors such as Inventory clerks and EPC assessors. I think Brooke's biggest lesson was the need to focus on one thing. His original idea was 3 apps and 2 websites! Great, but which is done first? We worked on pinning down the core loop (thanks Amy Jo Kim) and focusing on the what prospective customers would really value. Brooke's pitch must have been good as he has funding in place.

All four companies have potential. It will be interesting to see how well they fly now they have graduated.

Open API and how to add PUSH

Having an open API is great for allowing partners to build on your SaaS product. However, when I've been involved in integrations that use other people's APIs I've often thought that the construction of the API has only been considered from one perspective. "People will want to use the functions, utilities and data we have created, so let's allow them to access it!" But what about the user story where my external system is informed of events that have occurred within yours? Polling for changes seems very old fashioned, and incredibly wasteful and inefficient. What we need is an event based system that can inform external parties of appropriate events they want to hear about. We're talking about webhooks, callbacks etc
	The problem tends to end up being "solved" with bespoke calls to specific partners. We need a more generic solution. An architecture utilising a workflow engine will allow events to be raised that can call 3rd party end points, but where WE have defined the data that will be sent. I stick by the “Keep It Simple, Stupid”, and advocate the simplest of data structures... one that lets the 3rd party know what entity type is involved, what has happened (Created, Updated, Deleted), and the IDs (both internal and external). The only additional piece of info you could add would be the URL to the API call that would retrieve the specific entity. It is then up to the 3rd party to decide whether they wish to Read the entity to capture the data.

SaaS - really? or just a website!

I've blogged before about the way that tech acronyms have been used in marketing so that their real meaning gets diluted.
One that is currently being diluted by the tech world itself is the term Software as a Service (SaaS). It seems to be used for almost anything that is online and has a subscription model! I think that misses the definition of Service. I would argue that you are only really offering a SaaS if your software's web interface is only 1 of several mechanism's by which your "service" is delivered. This almost always means that you have an API, and truely it should be open and comprehensive with your own product built on top of it - i.e. no backdoors to data! A SaaS product will be looking for opportunities to integrate with other solutions, to share information. Software delivered via a website will be closed, difficult to share information with, uninterested in partners despite using the term service and having a monthly a subscription fee.
	Part of the differentiation between SaaS and Software as a Website (SaaW) is that a company who truely sees the benefit of an open, collaborative platform will want to attract partners. Being open allows other people to build the bits you don't have time for, or even know would be useful! To do this well you need more than an open API. This simply satisfies the PULL aspect to your data... what about the PUSH? (Please tell me you didn't plan on people polling your api for changes in data).
	I promote thinking about an event based model to your architecture that will allow you to attach subscribers to changes in your underlying data. This will allow you to PUSH information to those people who want to know about it. Just as defining a well thought out API is difficult, so is defining how to expose events that can be subscribed to. More on that subject in another blog post. 

Dependencies cause a log jam - Pitched

Hopefully this one is self explanatory! If you've got people waiting on someone else finishing their work before they can start then you will have to get creative with your planning of resource. This becomes a serious source of waste when the problem occurs so often that you are always trying to juggle the order of work and can never seem to get on top of things. If your backlog constantly has a whole load of tickets marked as “blocked” then you are in a project manager's version of dependency hell.

The route cause is one of not understanding the shape of the work hitting the system. In a simple example, if your front end devs are always waiting for back end to finish stuff then its clear you need more back end developers. However, it is rarely that simple. Often you'll hear the phrase, “I have to wait for <insert “specialist” developer's name here> as they are the only one who works on that”. This is the same thing, but based on skill or technology. At this point you should be looking at the skillset that your team has. If your team is big enough then make sure the core technologies are understood by more than one person.

If you are suffering from this problem then I will bet your developers don't have individual learning plans! When was the last time you held a Knowledge Transfer (KT) session, or organised some internal training? Do you schedule some work as a pair programming so you can create the opportunity “for another developer to learn that area”?

I've said frequently that its important to estimate your work and to follow up with measuring what you do, the trick here is what to measure? Step back from the problem and have a look at it. If you already know what “areas” you have problems with, then your intuition will help you create a classification of work that should clearly identify the problem areas! Add this to your estimates and measurements and hopefully you'll have the proof that a course or lesson in <insert “specialist” developer's skill> will help alleviate the blocked items and reduce waste.

Estimation is inherently problematic - Pitched

There is a pretty good article which describes some of the inherent problems with estimates, and that a more statistical approach is needed. It still recognises that some form of estimate is needed and advocates using the t-shirt size approach to estimate features on a broad basis. It still misses one important point in that estimates should not just concentrate on duration! What about the complexity? Just saying something is a Medium (translates as 90% of time it will be done within 3 days!) excludes the fact that it might only be able to be done by the office genius!

Another thing that is missing from most people's estimates is a level of confidence. The accuracy of an estimate depends on when you ask. Ask a developer who has spent 10years working in the domain how long it will take to tweak an existing feature and you'll have a high level of confidence... ask him about an industry he doesn't know or to use an unfamiliar technology and you'll struggle to get anything except an “I dunno”.

This is where the “cone of uncertainty” can be used as a useful visual tool. I would suggest having it printed large and stuck on the wall. Every time you are asked for a time estimate you should point at the cone and say where you think you are on it. It is the developer's best defence to the statement “but you said it would take a week!”. After a while management will start to use estimates for what they are and not as deadlines.