Make, Rattle and Code
Folksy founder James Boardwell is into the craft of code and the code of craft
What’s the best way to work with programmers in product design? How and when do you put a price on your goods? Should startup people think about storytelling? Dividing his time between ‘useful hacks’ business Rattle and the ‘British Etsy’, Folksy, Sheffield-based entrepreneur James Boardwell has some useful lessons to share.
First of all, tell
us about your company Rattle – what have you made?
We went through a lot of phases with Rattle. In the late 2000s we had regular hackdays and made loads of products. We were trying to solve problems we identified in our own working lives, and one thing we’d noticed is that it’s actually really hard work to organise staff holiday time. So we made a thing called the Holiday Calculator and pushed it out.
It was a little mobile app and we closed it down after 18 months because it didn’t feel like it was going anywhere. But as soon as we took it down we had a few phone calls from people asking where it had gone. We didn’t realise anyone was using it!
It turned out there was a small community of North Sea oil rig workers who used the app a lot – one of them even offered us a sum of money to get it up and running again. That was the kind of thing we did with Rattle – small-scale hacks that did one thing, that solved a specific problem.
It turned out there was a small community of North Sea oil rig workers who used the Holiday Calculator a lot
Another thing we made was Job Box – a sort of Quantified Self way of showing what each person in the company was working on. It was a real, physical box we made with breadboards, and was particularly good for remote workers. The radio-style dial was turned to one of eight positions, each one representing a different project.
The information was then sent to a
site where it became a simple, live web visualisation of the team’s activity.
It was important to us that it looked and felt fun; it made work a bit
game-like. When we went public with it, the BBC and others wanted to commission
them, but we costed it up and that the sheer labour expense would push the
price up to something like £500 a box! This was pre-Kickstarter, and we
couldn’t see a way of producing them on a bigger scale.
Over the last few years we’ve been thinking more about data, and in particular, storing data well. We’ve noticed there seems to be a gap in the market for presenting business analytics in a simple way and we’ve been working with public reception areas of businesses – the kinds of places where statistics or audience info will be shown on a public screen. How do you present key details to customers viewing those screens?
We’re interested in telling simple stories well. To that end, we’re making something at the moment called ‘Hello Audience’ for the BBC. It’s a real time drop-down graphics display that shows the most recent Twitter mentions – so you can very quickly see what people are saying about BBC content, live.
We’ve found that a few simple data points work better than something complicated; effectively, that data needs a filter. And we’re working towards perhaps building something physical – as you can see on this sketch, it’s already got a handle on it!
TV people get excited about engaging audiences and creating things that are celebratory and fun
The most important thing I’ve learned from spending a bit of time working with television people at the BBC is that TV types get excited about engaging audiences and creating things that are celebratory and fun.
Web people aren’t generally very
good at realising that – they have different priorities – but visual,
telly people tend to have that insight. It’s so important to make things
entertaining; whatever you’re making, that’s how you capture an audience’s
imagination and keep their attention.
run Folksy too, and have a family – how do you manage your time
I try to keep Mondays for Folksy, and the other days of the week tend to pan out according to the tasks. I have my own Trello board with all my own tasks on, and because of the kind of work I do, the tasks for both Rattle and Folksy are broadly similar.
I’ll try to divide my time between the different projects but of course it sometimes makes sense to get some momentum up on something, and I’ll spend a few days on one project.
We have a daily catch-up, but apart from that everyone gets on with their own work. My approach to management is fairly hands-off; anything else just wouldn’t be cost-effective, in terms of my time.
It’s not necessarily a good thing that my system allows me to choose which tasks I do according to what I most fancy picking up – I wish I had the discipline to focus on the things that need doing rather than the tasks I most feel like! It can make things more stressful, especially when there’s a hard deadline coming up.
Across the year it all works out fairly well, but just because of the nature of client work I’ll know there will come a crunch point every so often where I’ll have to work that 16-hour day.
do you find being based in Sheffield?
I love being here for personal reasons, but from a work point of view, I find it quite frustrating. Just maintaining that crucial loose network of contacts is harder up here.
Having a coffee or tea without any particular agenda is incredibly important to maintaining working relationships – but being based here means that London meetings have to be planned, and end up being quite formal and controlled because of that. If you’re not having those informal conversations that lead to work, I really think you’re missing out.
For start-ups especially, it’s all about personal relationships and if you can’t develop those you’re at a huge disadvantage. I’d like to support local clients more, but it’s so difficult because there’s no money in it. All our clients are in London now.
If you’re not having those informal conversations that lead to work, I really think you’re missing out
would be the most useful hack for your business, right now?
It’d be really nice if products spoke to each other more effectively. A long time ago, people like Matt Jones were using the metaphor of the coral reef – talking about building a series of things that are part of the same ecosystem. You get one or two, like MailChimp, which are attached to secondary services, but we could really do with a suite of products that properly talk to each other.
These are services I would love to use with my own companies. We could use something that, for example, lets us move easily from a CRM database into an email product and back into an OAuth service – all the data, names and identities moving between a set of discrete products which each do one thing well.
What’s the most difficult part of the product development process?
The thing that I’ve found most difficult to understand with start-ups is how to decide between the ‘testing and beta’ route and the release of polished products. Of course, it’s partly about the kind of product – you very rarely get a beta approach to a mobile app or a game. But with web apps, the beta route seems more popular and it’s not always clear why.
It’s not always evident to me what the best strategy to take is – do you release unfinished products and keep iterating according to customer feedback, or do you attempt to shape it without feedback? Although it seems most sensible to release early and tweak, with some products, people expect a certain amount of polish.
How can I decide between the ‘Beta’ route and the release of polished products?
Another interesting problem is how you go about pricing things. Towards the end of 2012, we built something called GoGoMargo. We did some research into how people manage small events and found there’s usually no budget, and these things are done through Facebook and flyering. We felt there was a gap in the market for these kinds of things – less formal or conference-like events than the ones served by Eventbrite.
We had a certain amount of polish to it when
we released it, but I think we made some fundamental errors. For a start, we
didn’t charge up front. We just released it for free and thought we’d figure
out where the money was later.
That was a mistake – we should’ve introduced a model from the get-go. We’re still paying £50 a month just for Heroku, which adds up over a year. I think we could easily have made money on it, and we would have understood the value of the product better if we’d started charging something early on, too. There is definitely an interesting opportunity in the event marketing sector.
Putting a value on something, even a low value, teaches you a lot. When you start charging, the long tail of people won’t be interested, but if your product is good there will be a small number of people who will pay proper rates for the service because it fulfils a good need for them.
Putting a value on something from the outset, even a low value, teaches you a lot
Being willing to put a price on something means being willing to fail. It’s a way of finding out early on that people don’t want to buy your product, before you’ve invested your time and money in it. It’s hard to persuade people to pay for something they think of as a ‘free thing’.
Did you learn some good business lessons from the Folksy Summer School?
We learned a lot about pricing! When we held our first Folksy Summer School last August, we canvassed people on what they’d be prepared to pay for a two-day event.
Now, perhaps we canvassed the wrong people, but they were telling us things like £50, and when we researched other two-day events the prices were considerably higher. We wanted people to come, so we went for a low ticket price.
When we looked at the internal costings, we had covered our expenses but hadn’t covered our internal time – so we were really working for free. In terms of goodwill it was probably worth it, but we do have a problem now because we’ve set a precedent. The only way we can do it again is to put the price up. In fact, we’ve been advised: either double in size or double the ticket price.
What do you think about the coding-as-craft mantra that’s so popular at the moment?
Folksy is about celebrating real craft, not just gluing something together – and I do see coding as material building too. It’s harder to understand something in that way when it’s just words on a screen, but there’s no doubt that even if it’s just a simple web app, you’re crafting an artefact that needs to work for different behaviours and workflows.
Some of the older code on Folksy is a dog’s dinner, but we’re gradually replacing it with something much more elegant. When we go back to the old code it’s like wading through treacle, and we think: “Oh! Why did we do it that way?” The code is a reflection of the often bad decision making that occurred at the time.
code becoming more visible – and perhaps therefore better – as a
result of the Github panopticon and the highly critical coding community?
The Github community are definitely sharing much more than other communities, for example, the .NET community – the open source approach and public repositories may have helped with a lot of things. But I still find it difficult to tell whether or not some code is elegant just by looking, because I’m not a programmer. If I work through it with a programmer I can understand, though, so it helps to have a team you trust who can explain what’s going on and make those previously invisible, ‘secrets’ of the coder world more public and accessible.
As management, we can become part of the conversation when you abstract from the code and start looking at the larger model, and getting technical about the whole process – what the code is doing, what function it serves within the business, and that’s a craft too.
I’ve found that when you get developers thinking about business needs and user functionality – encouraging them to be service designers – they can be even more useful. Encouraging ‘code people’ to think in this way wasn’t something that was done until recently but I’ve found it really works.