Diary of a software start-up. Day 48.

Now there, are three-ee, steps to heaven. Wop. Wop.

In just under four weeks, on Monday 5 December, I will be launching ikooloo at TechCrunch Disrupt in London.

At this stage, I don’t actually have a real product. WHAT? I hear you say: ARE YOU MAD?

If you have read any of my previous entries (You can find entry 1 here, entry 2 here, entry 3 here and entry 4 here) you will know ikooloo is all my wife’s fault. Suzie outlined a problem and I thought I could fix it.

As soon as I thought I could fix it, my mind went into overdrive about what solution I should build and it’s this process I want to talk about. I have been asked many times how do you actually design software (s/w) and I am going to tell you…

The truth is, it’s a little more complicated than I am going to outline. I can’t realistically do this justice in a 5 minute read. This is the stuff of legend — of books, professionals and degrees (including a large part of mine) so please, please, please don’t read this and think it’s complete or suddenly think you are an expert.

BUT - I do believe that anyone thinking about starting a s/w company, especially non-technical people, should be able to do what I am going to outline or at least try their best to:

1. Write.
2. Storyboard.
3. Prototype.

Completing these 3 steps will help you understand and articulate your product. They will reduce the costs of developing your product. So as Eddie Cochran sang “Just follow steps one, two and three…”

Step 1. Write. Write anything. Write everything.

The picture below shows my very first notes on ikooloo. My writing is normally much neater than this, but I wrote these notes on a bumpy train journey from London (I can’t remember where I had been) as the problem Suzie was having was bugging me a LOT! I’d failed to find anything that did what I thought Suzie needed (and much more importantly, what Suzie said she needed).

My first page of notes about what would turn out to be ikooloo

This is my first note. There were lots more. You may prefer to write some notes on a computer and do whatever works for you but the point I want to make is (if it wasn’t clear by the bold title above the picture). WRITE IT DOWN. Write anything and everything you think about THE PROBLEM YOU ARE TRYING TO SOLVE.

(WAIT: If you don’t have a problem to solve; you probably don’t have much of a chance of building a successful product so; if you don’t know what the problem is, may I politely suggest you stop and think about finding one.)

I suggested ‘writing it down’ to someone last week. Their response was:

Why? Where does this get me?

This person said they didn’t need to write anything down; it was all in their head. So, I asked them what their problem/solution was. They couldn’t tell me. Sure, they spouted what was in their head; lots of things & random thoughts about how their solution was going to be used by every company. The thing was, I wasn’t actually any clearer about what it was going to do. It was a nice idea, but it wasn’t any more than that.

So where does this get you? The answer is writing it down simply starts the process of building a clear(ish!) view of your solution.

To make progress, you need to be able to articulate what your solution does to a) people who you think may actually use the product b) people who you may get to build the product c) people you may ask to give you money and d) your wife/partner , etc., so they don’t think you are completely wasting your time. This is the start.

Unfortunately, I can’t predict what your notes will contain as the content will depend upon your exact solution. But, if you haven’t done this before it can be tough. You may want to start with the questions from the Lean Canvas (mentioned in the last diary entry) but as we are thinking more about the solution there are 3 questions you need to answer:

Q1. What types or groups of ‘things’ are in my product?
Q2. What information do you need about these ‘things’?
Q3. What do you need to be able to do with/for each type of ‘thing’?

Does that make sense? Err, I doubt it. As I said, this can be tricky so to make it easier, I suggest you try this first using some example software you know and use. Email is a good example.

So, if I was answering Q1 for an email solution I might start by thinking about PEOPLE and NOTES/LETTERS.

Then, for Q2, from a people perspective I need at least a name & email address and from a notes/letters perspective I need some ‘content’ (i.e. I need to be able to write something) and I may also want to know when I sent this NOTE/LETTER… interestingly, this leads me to answer Q3 as, obviously, I need to send a NOTE/LETTER to a PERSON. I may then think about wanting to send the note/letter to more than one person which might add more information to Q1 as an ADDRESS BOOK.

If you look at my notes again, my page focuses on Q1 (People, Sales , etc.) and the column on the left hand side starts to list out where I would get some of that information from (as in my case, ikooloo wouldn’t ‘own’ the information).

Without knowing it, you are designing your solution. Whilst you almost certainly won’t think or write about in this way, the answer to Q1 defines how your information will be stored OR

Q1 = the objects/tables in a database;

The answer to Q2 defines WHAT information will be stored OR

Q2 = the data/attributes in the objects/tables in the database;

And the answer to Q3 is the actions/triggers OR

Q3 = the system logic acting on the data/attributes in the objects/tables in the database)

In simple terms, all software is built like this. And, once we know what information we need and how we are going to use it we can start to think about how our s/w will actually work…

Step 2. Storyboard.

Have you read a comic? I loved reading comics when I was younger. My personal favorite was Roy of the Rovers. Step 2 is writing your own comic strip for your s/w — otherwise known as storyboarding. My first storyboard sketch for ikooloo is in the picture below.

My first storyboard picture for ikooloo

The start point for this is…

…how will my customer use my solution?

To do this, get a picture of the ONE PERSON whose problem you are solving. Describe them, give them a name, a job, describe their interests… You aren’t building a product for you; you are building it for them and everyone else like them. They become a part of your product team and have the final say in any product decision you make. This is called a ‘customer persona’. ikooloo’s is Suzie.

There are lots of storyboard s/w solutions out there but, again, I am a little old school and prefer to do this on paper as it allows me a little more creativity (I need all the help I can get!). If I am doing it with others, whiteboards and stickies are great also but as it’s just me paper it was.

Next, I mock up a screen and leave lots of space to write. I print out some out and start writing my comic.

I personally use a mock-up of the screen size my s/w will be primarily be used on. Some people suggest that you shouldn’t think about screen size at this stage and whilst I think you have to find what works for you, I think using the actual screen size forces you to think in terms of the device you are using. These are real constraints and to ignore them is pretty self-defeating. So, in the picture, this is a real size iPhone5s. My target is to make what I design fit well into that space.

Now, the eagle eyed amongst you may notice that what is on this picture bears no relation to what is on the first picture. This is because by the time I had finished writing everything down, re-reading it, questioning it, talking about it, thinking about it, writing more down, re-reading it, questioning it (you get the idea?) something happened…

…ikooloo changed.

ikooloo was initially going to be a CRM for small business. Every CRM I looked at (and some of them are listed on the right hand side of that note) didn’t fit with what Suzie needed. Most were built primarily for business-to-business sales (B2C) not business-to-consumer (B2C) so had things like Accounts & Opportunities. Some where nothing more than glorified to-do lists. A lot were cheaper versions of salesforce.com and probably wanted to be Salesforce.com.

But — it was only by going through the first step to heaven that I realised this was wrong. What I was trying to do was fit something I knew a little about (I worked for 15 years with CRM and related s/w), and always thought about building, in to something that Suzie (my customer persona) did not need. Suzie didn’t need a different CRM, she needed something completely different. I didn’t even get to stage two because as I tried to articulate my idea I realised I wasn’t solving the problem. So ikooloo changed.

But let’s get back on track — with your persona in mind think about the first thing they would see when they go to login (assuming they login) page. Sketch out what’s on it. Then, on the next page sheet sketch out what they see once they have logged in. What menus will there be? Annotate each sheet with explanations, notes and things you aren’t sure about. Repeat this process for each and every possible thing that can be ‘clicked’.

As you can see from my storyboard, you don’t have to start with the login — I started with my main navigation or tabs. I started here because from a mobile app perspective; screen space is limited so the right navigation flow becomes more important.

OK, this isn’t easy. It really isn’t. Designing a user experience (UX) is a skill that takes time to master but…

…we aren’t looking for perfection.

Don’t worry if you can’t draw. Accept you will get it wrong, rip pages up and probably do this several times. This is just another step in your journey that allows you to understand and articulate your solution.

You are now just one step away from heaven.

Step 3. Prototype.

I don’t believe you can ever really know whether any software will work until you build it. If you are non-technical, getting something built will cost money, possibly lots of money, actually probably lots of money.

So what to do? The answer is step 3, turn your comic into a reality:

ikooloo prototype

Prototyping used to be a dark art. Years ago, you basically had to be able to program to do it. Then, packages appeared that didn’t need programming skills but absolutely needed design skills. Whilst both approaches are still used and valid, if you are neither a designer nor a programmer it’s a tough gig. However, there are now a plethora of prototyping SaaS solutions out there that certainly don’t need programming skills and don’t necessarily need design skills — the one I used was (is) creator by ionic (https://creator.ionic.io/).

I use ionic creator because, compellingly for me, I don’t need to actually design anything. Everything you need to design a mobile app is included. Buttons, menus, icons, controls, navigation etc.

The previous two steps are no more than steps leading to this. As a start-up, as a non-programming, non-designing founder I can build a protoype that I can:

Download → Use → Test → Show → Share → Get feedback → Improve → Use → Test → Show → Share → Get feedback → Improve → Use → Test → Show → Share → Get feedback → Improve → REPEAT AS REQUIRED.

I can do this again and again and again until I can clearly articulate what my product is and it solves the problem. And, when it does this, only then do I need to show this to agencies, designers & developers. They will understand what you are trying to do. They will want to review it with you. You will need some proper designs done. You will probably need some user experience help. BUT — you won’t be paying them to document what you already know and it will reduce the cost of developing your solution.

THIS is heaven. It took 3 steps to get there and cost $24 (excluding pen, pencil and paper). Who said starting a s/w company was expensive?