Author: lux

This is the final part of a series of posts about how we built Dojo Learning (part one, two, three, four and five).

Software is easy to start, hard to finish

Persistence and hard work are the key to succeeding in software as in most things. If you can maintain the persistence, you'll keep going until you've made your wrong idea into a right one through subsequent iterations.

When we started Dojo, despite it being my 3rd company we still figured we could get something up and running in no time. We quickly discovered we had a much bigger idea on our hands than we originally thought, which is usually the case.

If one thing is true of starting a company, it's that no matter how much work you think it will be, it will be more than that. So find ways to keep motivated and keep each other going, because you'll need it. And if you survive long enough, it means you didn't fail. It means you've bought yourself enough time to get it right, and to make something people truly want and love. Something you can be proud of for the rest of your life.

My last point on Dojo is one way I keep motivated and keep going when things don't go according to plan or when problems arise, as they always do.

Take a step back

Stepping back puts things in perspective. It helps you see the forest for the trees, helps expose imbalances in your work habits that aren't sustainable, and helps you truly appreciate what you're building and who you're building it with and for. Taking a step back helps keep you motivated too, which is critical in a startup.

There's something deeply personal about building a startup. For me, I look at it like writing an album or a book. You pour your heart and soul into a startup. You put in unquantifiable hours. You wake up after dreaming of new ideas and go to bed way too late trying to fix one last bug. And it's the nature of software that much of this happens in your head, alone.

In teams, it's something that brings you closer to another person in a way that few things do. Because of the risks and the ups and downs, you're exposed and your character shows to each other. Bad habits can kill startups, and dying startups often kill friendships too as a result. That's another risk you take in a startup. You face uphill battles, substantial difficulty, and that's something that win or lose you share as a team.

Taking a step back has helped me realize what an amazing thing Les and I have accomplished over the past year or so, and as much as it's been hard work it's also been a privilege to work alongside someone like Les and get to know him in this way.

We started out as acquaintances who would sit in the corner and geek out over technology at parties, teamed up on some projects together (Les hooked me up with a few really sweet clients, who have been awesome to work with too!), and then somehow we decided starting a new startup together was the thing to do. Funny how things work out, but taking a step back helps me fully appreciate it all for the amazing experience it's been so far.

I can't recommend starting a company enough - I'm hooked - but make sure that if and hopefully when you do, you step back enough to realize and appreciate the ride.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch our future posts.

Just letting everyone know that we will be doing some site maintenance this coming Saturday, January 17th starting around 11:00 A.M. Central Standard Time (CST). The site will still be accessible throughout the maintenance, but certain features will be disabled for up to 24 hours while we wait for some DNS changes to propagate across the internet. Those features include:

• New member and learner sign-ups
  
• Creating and editing lessons
• Chatting and posting to lesson lounges
• Notes, journal entries and journal comments

This is a one-time change that will help ensure we can continue to scale the Dojo Learning platform to meet our site growth needs for some time to come. If you have any questions, please feel free to email us.

This is part five of a series of posts about how we built Dojo Learning (part one, two, three and four).

Plan each feature on paper and think it through first

Like I mentioned in the last post, wireframes are a great way to visualize and plan new features out. Each screen of what you're building should be wireframed as best as possible to see how it will flow and to spot flaws in your idea.

This also puts the user first, since you're designing around their experience of your software. A natural extension of this aspect of wireframes is usability testing. You can usability test with just wireframes, before you've written any new code.

We also wireframe mostly on paper. I love tools like OmniGraffle for presenting something professional to a customer, but computer interfaces have yet to even get close to paper and pen in terms of just getting your idea out, and trying multiple iterations and alternatives quickly.

For a good example of how to design a user interface with wireframes, see this paper from 37signals.

Paper is also great because you can write user stories, lists, asides and anything else that helps you get a better idea of what you need to build and who you're building it for.

We also try to get our database schema down at this stage too, since that helps us think about other potential uses for the same data down the road. I find this helps ensure we're not being too limited in our data model, which might hinder future feature additions.

So for us, step one is always designing from the end user's perspective and making sure that comes first. Step two is making sure we've thought of everything from a data and implementation standpoint. From there, the code becomes a matter of connecting the dots.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

This is part four of a series of posts about how we built Dojo Learning (part one, two and three).

Don't bite off more than you can chew

We've been developing internally at Dojo a bit like a traditional software project and a bit like a startup. It's much easier to push bug fixes to customers, since you're all on the same system. So bug fixes get fixed much faster, and more easily too since we only have to test against one server platform (although we still have to test in each browser, no escaping that one).

But the quick push model only scales so well for larger change sets, especially ones requiring changes in several areas or changes that need to be made in concert with each other. For those, we've adopted a more traditional "here's what we want to do for the new version, let's do it" top-down approach.

This removes a bit of agility at first, but gives us several benefits. First, we get to announce each major update as a new version. New versions are one of the few things bootstrapped startups can really use to attract attention from the press, so we benefit from that.

Second, it gives us a specific goal that we're working towards, which helps keep us motivated. And third, it gives us a chance to put the whole product into question and ask all those fundamental questions again.

Lastly though, it gives us a finite goal and limits so we don't get into a scope-creep rut or start adding things that are outside of our agreed upon features for that release cycle.

Break things up for easier digestion

You have to break things up into manageable sizes, or you'll end up with chaos, or worse, wasting time on the wrong problems. We try to break things up into the smallest components we can and then plan those out with wireframes, lists of actions, user interactions, database schemas, etc so that we have as clear of an idea of a feature as possible and how to implement it.

It also helps ensure everyone is talking about the same thing, and that you don't mean something different when you're referring to a feature than the rest of the team means.

Once we've broken each feature down into individual wireframes and tasks, those become the to-do list and away we go.

Set a date

We actually work towards specific release dates internally, and while they're not set in stone, they do help us plan how we spend our time and what we can fit into a development cycle. They also force us to think through our features so we don't over-promise and miss the date.

For me, even though I've done the planning and preparations, deadlines still create a bit of uneasiness early on, but once I'm into a groove I find they create a bit of excitement.

The key to realize is that unless you've already begun marketing or advertising efforts around your deadline, it can be adjusted. It's just an artificial date you've set, and pushing it back isn't the end of the world. And it's a good way to get everyone in sync, and to help give the marketing side of things something to plan around too.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

This is part three of a series of posts about how we built Dojo Learning (see part one and two).

Get to the root of the problem and solve that

Customers are notorious for explaining a feature they want, as opposed to the problem they're trying to solve. It's our job to read into what they're saying, figure out the core problem and solve that. Even our own ideas for features are really just a specific way to solve an underlying problem.

But how do you know you're at the root problem yet? Keep asking questions. Play the five whys game. An excellent indicator you've found the root cause is when the solution to it is so simple you want to smack your forehead for not recognizing it sooner.

I think it was Einstein who had said about his theory of general relativity that he could feel it was right because it was so simple. Occam's razor is a principle that roughly says "all other things being equal, the simplest solution is the best."

This is true of software especially, and what you'll find is that when you've solved the root problem, it has a domino effect on other feature ideas and solves some of those too.

When you solve the root problem, you'll usually find the solution is so simple and obvious that you wonder why you didn't think of it first. The reason of course is that simplicity is hard, it takes hard work and persistence to drill down that far.

My last startup failed partly because when it began to run into trouble, I didn't take a step back and find the root solution for the problems we had. They seem so simple in hindsight, but at the time I couldn't see them. Instead of making one simple change and saving the business, I watched it crumble right in front of me.

There were several other factors (translation: mistakes I made) which I'll save for another post, but one of the key things was that I didn't dig deep enough to see and solve the root problem. So I know first-hand how important this step is. In many cases, it just means feature-bloat. In mine, it cost me a startup.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

This is part two of a series of posts about how we built Dojo Learning (click here to read part one).

Understand your users

Before you can prioritize which features to build and what ideas to focus on, you need to really know your audience. When you're just starting out, that's the first thing you need to figure out. It took us many months, several iterations of our software, and lots of testing and feedback to fully understand who our users are, who they are not, and what their needs are.

Now we're pretty confident we're building a killer set of features that all provide significant value to our users, because now we get it, or at least we have a much better understanding. And that makes prioritization a lot easier.

How we got to understand our users

We started Dojo in partnership with a company, the Centre for Education and Work, who provide services related to training in the workplace and adult learning. This gave us a good leg up, but we still had to decide: are we building an employee training tool, a higher learning tool, something for online trainers and consultants, or something else?

Initially, we went back and forth quite a bit and had to explore each of these areas. Fortunately, there was one group of users who had similar needs in each of these categories: the learners. A learner needs certain tools no matter what company is using our software, and so right off the bat we could focus on the learner experience and add value there while buying time to figure out who our target group was.

We were also lucky in that we were able to harness our partnership to do testing with learners from all across Canada. That provided amazing feedback, and was our equivalent to the "release early, release often" philosophy at that stage.

But you don't need a partnership with an existing company to get that, you can ask your friends, family, acquaintances and contacts to test it out, you can solicit users online to be beta testers, and you can even approach companies directly and just ask them: Do you want to pilot some new software?

Prioritize by value

Once you get that down, any time you think of adding a feature you can hold it up to this measure and see how it stacks up. If it doesn't add real value for your users, then it's clearly not a keeper. If it only broadens your audience and makes it less clear who your software is intended for, that may actually hurt your marketing too. But even if it doesn't, it still wastes time, and time is your best weapon early on.

I look at writing software like writing a story or a movie: If what you're adding doesn't move the plot forward and isn't central to the story, then you should leave it out. Have the confidence to do so, it's tough sometimes but worth it.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

We've been working on Dojo Learning for over a year now and we're progressing nicely towards a really major update we're calling "Dojo 2.0". It's still a couple months away, but we think we've got something that will definitely knock some socks off. I can't say any more yet, but we'll have more details on that soon enough :)

I've also been doing software development for about 10 years now professionally, so I've seen my share of what works and what doesn't. And I learned most of what doesn't the hard way.

But instead of officially employing a particular software development methodology as a standard here at Dojo, we simply try to practice a few informal principles in all of our thinking about Dojo.

Over the next few posts, I'm going to break those down and talk about each one. The first is about managing ideas.

Keep a list of ideas

This may seem like an obvious one to many, but a surprising number of people don't record their ideas and so those ideas simply come and go.

We have a huge number of ideas for new features and improvements to Dojo Learning. We record them all to a big list and revisit it periodically. Most of them will likely never see the light of day, and many end up being solved indirectly anyway (I'll get to that later).

The important thing here is just to keep a list, to keep adding to it, and make it accessible to everyone so they can add to it too. And any time a user suggests something, put it in the list.

We also keep a list of ideas that don't fit the project, but may be things we branch into later, or that pieces of what we've made before can be used towards solving.

You never know where an idea will lead, so jot them down. This is the easiest thing you can do, and gives you an endless supply of material for future brainstorming and planning sessions.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

Here are some thoughts on our API and APIs for Software-as-a-Service companies in general that I wrote in an email recently and thought they might be worth making public.

API in plain English

API is a programming term, which stands for Application Programming Interface. An API is a way of accessing your data directly, instead of going through our website in your browser. A developer or administrator could use it for example to do regular backups themselves, to export data into another application, or to build an entire application outside of our site itself.

We have a few ideas of our own that we'd like to build on top of our API, but essentially it opens things up for customers and enables many possibilities that we may not have thought of ourselves.

Content ownership in software

We see this as very important since content ownership needs to rest with the customer, not with us (the service provider). This has always been a big issue in software, not just with SaaS services, but SaaS does change things up.

Traditionally, proprietary software used proprietary file formats, meaning that while you had your files, you were still locked into their file format, and so you had no choice but to use that software, or change with some difficulty. The Open Source software movement helped change that by raising awareness and by ensuring the code and also the data formats were open and interoperable.

Where SaaS changes things

The problem with the traditional software model is that by installing software yourself, you bear the burden of maintaining that software and the machines it runs on. For complex software, this often requires a full-time system administrator to be hired.

Software-as-a-Service solves that by letting us be your software host so we take care of the technical details for you, which can save a company lots of money, but it can potentially put your data into a closed scenario again.

So customers should be careful to make sure any vendor provides a means of accessing the data in a way they can take with them, that way the control and ownership rests where it belongs, with the customer and not the vendor.

Future interoperability

Over time, I believe standards will continue to develop and be adopted by SaaS companies too, and I think it's in everyone's best interest for that to happen.

Just like today OpenOffice.org can import and export Word files and new file standards are emerging for office documents, so too will ways of standardizing data formats for more specific applications like e-learning. And in the meantime, if we all do our part to make sure customers maintain clear ownership of their data, then we ought to be well poised for a future where customer relationships with SaaS services are built on quality, value and trust.

We should be out enjoying the nice weather today (it may be one of our last up here in Winnipeg!) but instead we spent today doing a bunch of bug fixing. These include several improvements for instructors, people management, messaging pending users, a fix for Firefox 2 users in the lounge, and some minor UI tweaks too.

Now to enjoy the remaining sunshine! :)

This post is our contribution to Blog Action Day, which brings together thousands of bloggers to write about one topic for a single day. This year's topic is poverty.

A friend of mine, Ilan Shwartz, took a trip to South Africa a few years ago to volunteer at a place called the Hillcrest AIDS Centre. Hillcrest provides medical services, education/awareness, emergency food parcels, sustainable agricultural development, and income generation programs for people in an area where the unemployment rate and the rate of HIV/AIDS infections are both over 40% of the population. The number of people there infected by HIV grows by over 500,000 every year. That number is almost the population of Winnipeg (the hometown of Dojo Learning).

When Ilan came back to Winnipeg, he brought with him a few dozen small beaded pins called "little travellers" which were sold at Hillcrest as souvenirs, as part of their income generation program. When people here started expressing a desire to have one of the little travellers for themselves, Ilan started selling the pins here like they were back at Hillcrest.

Things started to pick up quickly, and so Ilan organized a group of volunteers under the name "Little Travellers" (originally the "Simunye Initiative") to promote the pins at local events and find local stores to carry them. Fast forwarding to present, the Little Travellers are now in cities across Canada, and have started spreading into the US and as far as South Korea. To date, the Little Travellers HIV/AIDS Initiative has sold over 30,000 pins, raised over $150,000, and have been endorsed by Stephen Lewis, the former U.N. Special Envoy for HIV/AIDS in Africa.

Each doll is hand-made by women affected by HIV/AIDS, and 100% of the proceeds go to help fight HIV/AIDS and to provide an income source to the families of those who are affected. In addition to all of the  services provided by Hillcrest, the sale of Little Travellers provides an income to more than 100 families affected by HIV/AIDS in one of the most impoverished areas of South Africa.

Please take a moment to check out the Little Travellers website, read the stories of some of the crafters who make the little travellers, and buy a few for your friends and family. At only $5 each, a little goes a long way.

"By making these dolls, families have been fed, lights have been turned on, little children have gone to school, water has poured out taps... but most of all, hope has been restored."
– Paula Thompson, Woza Moya income-generation project, Hillcrest AIDS Centre