December 2008

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.