Attempting validated learning with Sol Trader

Sol Trader has been out just about two weeks now. It’s been great fun to actually launch the product and gain real feedback from people.

I’ve sold about forty copies. It’s a start, and a really good one. Thank you to those of you who have already purchased the game, and for all the feedback and encouraging emails I’ve received. I’ve learnt a huge amount already and it’s really helped me guide the way ahead.

The big question is: what’s next? How do I go from these humble yet encouraging beginnings to turning this game into something truly wonderful?

Validated learning

I’ve read Eric Ries’ excellent book The Lean Startup recently. In it he introduces a concept called Validated learning and goes on to define learning as the one important progress metric of startups: much more important than ‘customer numbers’ or ‘features’. Rather than define startups purely by ‘profit’ or ‘growth figures’, how can we ensure that we’re learning about how our business as fast as possible?

For Sol Trader, there are two main things that I need to find out.

• How can I ensure that I’m creating a game that people want to play, want to come back to, and want to tell their friends about?
• How can I ensure a steady stream of new players for the game?

The Sol Trader Hypothesis board

In order to support this learning, I’ve created the Sol Trader hypothesis progress chart:

This is what I’m using to track my theories. A good week would be one where I’ve managed to prove or disprove a theory or two, rather than simply adding in more and more ‘stuff’.

Note the Kanban limits to work in progress. In order to get theories tested as fast as possible, it’s important to get them through the process as fast as possible.

You can view and interact with the board for yourself: it’s on Trello here. I’m determined to do as much of this learning in the open as possible. I’d love your input into the hypotheses that I’m testing: you can vote and comment on particular theories and tell me why you think they’re a true (or completely wrong). Any input you give here will have an effect on what I work on next, so if you want to influence the development, then get involved!

Freed from featuritis

I’ve really enjoyed freeing myself from the continual focus on “features features features”. Features by themselves mean nothing: they are actually a drag on your product, as you have to spend time and effort maintaining them. It’s only the value that your customers gain from them that’s important. Focusing on theories has meant that I’m always making progress, even if I’m simply learning what doesn’t work.

Hang on: where is creativity in all this?

There’s a delicate balance here between listening to your customers and leading them in the direction you think they should go. I’m not going to sacrifice design flair and narrative to satisfy the baying (buying?) masses. This will likely always be a little bit of a niche game: there is a limit to the number of people interested in the genre. I plan to ultimately build the game I want to play, as opposed to the selling of something rubbish to satisfy everyone. Where’s the fun in that?

The important thing is to learn about your customer base, within the context of your original vision. If you cannot build a product within those constraints, time to look for a new business. Luckily, one of the earliest things I learnt through mailing list signups and a couple of hacker news appearances is that there’s a fair amount of latent demand for the vision I’ve got for the game, which is what spurred me on to get the alpha out in the first place.

What do you think of learning in public like this, and what do you think of my development approach?