At Usable we want to make projects better. We want to have fun doing it. And, of course, we want to be successful at it in both terms of finance and everything else. But there’s more to Usable than that. The core of the culture that we’re building in our business is the idea of doing things right.
When you’re a start-up there’s a huge internal pressure to do things the cheapest way possible. No one outside of your company is telling you to save money wherever you can, but there’s an assumption that it’s the norm for every start-up. Everything is about the bottom line. If you can persuade someone to work for free, for the promise of future reward, if you can use a piece of software without paying for it, if you can getaway with doing something that might not be entirely ethical but furthers your business, then people assume that you’re going to do it because you’re a start-up.
At Usable, and we have to say at almost all the other start-ups that we come in to contact with, that is not the case. It’s an attitude that people outside of the start-up scene have about those who are in it. Consequently we felt that we should set out the defining principles of our business clearly from the very beginning.
- We pay for the services that we use. We don’t offer exposure or future work in return for things we need now.
- We contribute back to the open source projects our products are built upon wherever we can.
- We are transparent about problems, errors, and mistakes that we make.
Following these principles is a risk, but we believe it’s one worth taking. We’re in this for the long term. We want to build relationships with the people who buy our software, and we believe that the right approach from the outset is the only way to do that.
Open source at Usable
At Usable we believe in using open source software. Usable Requirements stands on the shoulders of giants.
Open source is the concept that the code that drives a computer application is available to anyone who wants to have a look inside it. Frequently, but not always, open source software is also freely available without requiring any financial payment, although it usually comes with a licence agreement that precludes closing the source and ensures that the code remains free. At Usable we have embraced such software, and happily contribute our fixes and changes back to the community around the apps we use.
We’ve gone further than just the languages and libraries though. Our datastore is MonogDB, a fantastic document database that stores information as objects rather than related columns and fields. This means we can access requirements using a much more logical paradigm than a traditional relational schema – requirements documents are documents after all.
We’re really pleased to use these tools, and we’ll be releasing code and fixes that we’ve built and discovered in the future.
Projects, but better.
Projects, but better. That’s what we’re aiming to do at Usable.
For many, many years the Usable team have been doing projects of various kinds. We’ve been developers, project managers, product managers, and we’ve run our own businesses. We’ve all known the pain of a project that isn’t going to plan. Even the best managed projects have their problems, and problem projects are expensive, late or fail entirely.
We recognised this problem, and we recognised the solution: requirements management software. Unfortunately though, as it stood before we started Usable, requirements management software was either horribly expensive or just plain horrible. Enterprise tools for companies designing a new airliner are available if you’ve got the money to spend, but for the majority of businesses those tools are simply beyond their reach. At the other end of the spectrum there are tools available, stand alone or as part of a project management suite, but they’re not really requirements management: they don’t work the way that requirements management ought to. All too often they’re actually task management. Requirements are not tasks.
Requirements management means you manage what your project’s end goal is about continuously throughout the project lifecycle. By embracing the inevitable changes, by tracking and managing them, and by communicating them to everyone involved in the project you can effectively ensure that everyone is going in the same direction – people missing a line in an email that changes something important is a thing of the past.
Usable Requirements is shaping up to be something that brings most of the power of the enterprise tools to small and medium enterprise. We have real-time collaboration, document import to manage existing requirement documentation, a unique requirements editor that gives you the power of Word with the intelligence of a requirements management application. More than these features though, we’ve thought long and hard about how to best management changes and tracking, we’ve gone to great lengths to make the application beautiful and easy to handle. Things work the way they should. We’re writing documentation, but we don’t want you to have to read it. You’ll be able to pick up our software and run with it, just like you’re used to with Word or GMail.
0 to 100… What we learnt on Ignite.
From the outside looking in, life in a tech accelerator must seem like a lot of fun. A group of about 30 young, enthusiastic, motivated entrepreneurs are shut away in an office suite for a few months to tear down, analyse, and develop business ideas around the things they’re all passionate about. And they get money to do it. Sounds pretty good.
The truth is though, it’s actually far, far, better.
Winning a place on the Ignite100 accelerator, part of the TechStars network, was a huge opportunity without which Usable would probably not be in the position it’s in today. That’s not to say it was easy. It wasn’t. Life in an accelerator is an intense, stressful slog with daily challenges and no free time. Giving up time with your loved ones, your friends, your hobbies and even the time to read a book or get a decent night’s sleep isn’t easy. But you cope. You have to.
Having people criticise your ideas is difficult too. Something that you genuinely believe is a million-pound winning strategy that could change the world is absolutely worthless if you can’t engage with other people to enthuse them and make them believe in what you’re doing. You soon learn that you’re not as good at doing that as you think you are. Sitting across a desk from a successful business owner who has done what you’re doing, often without the support that a programme affords, and hearing them say that they don’t think you’re right is painful. Again though, you deal with it. You cope. At first that coping takes the form of not believing them, perhaps even telling them that you think they’re wrong. But then you learn. Sometimes they are wrong, everyone is. Often they’re not though because they’re not talking about theory – they’re talking about their experience. The opportunity to learn from other people’s mistakes is incredible. For these mentors to volunteer time and knowledge is amazing.
It’s not just the mentors that help you pull your idea apart either. Being in a highly-focused environment with a group of other entrepreneurs means you get to see what they think about what you’re doing too. You comment on what they’re doing. If you’ve tried to explain your latest thinking to someone for 20 minutes and they’re still not getting the point you know that there’s something wrong with your message. If your new friends are bouncing around positive and excited about what you’re telling them you’re doing you can be reasonably sure you’re on the right track – they’re getting it. That’s another important feature of an accelerator – friends. We’ve met some fantastic people through the programme, people we now consider to be firm friends. These people run their own companies, work for other people’s companies, they’ve helped us run ours, we’ve helped them, and we’ve all ended up in the pub occasionally. The friends we’ve made on Ignite are awesome people, without exception.
All of this time on an accelerator culminated in pitching for, and ultimately winning, £100,000 in investment for Usable. Frankly, applying for the programme was the best decision we’ve ever made.
Learning from Apple
With some of the best technology products on the market developed in total secrecy, how does Apple manage their project development process?
To Mac geeks the process behind developing a new product is something akin to Willy Wonka’s Chocolate Factory. Amazing things happen behind the closed doors of Cupertino. Until recently the process of exactly how Apple go from an idea to an iPhone has been a mystery. Now, with the launch of a new book written by an ex-Apple executive, the veil has been lifted and we’ve all been given a little peak inside.
The first thing that has to be said of Apple’s process is that it is expensive. Fantastically, horribly expensive. Apple doesn’t iterate prototypes like any other company might; Apple builds final versions of products, learns from them and then throws them away. That’s an option only open to you when you have $98b in the bank.
Beyond that though, the process is eminently sensible. The process is weighted to design up-front, because design is Apple’s unique selling point. People buy Apple products for the work they’ve put into their industrial design. For a different company it would make sense to load the effort into some other aspect that the customer comes to you for. At Usable, we put the effort into usability. That’s what our customers want.
The process at Apple is very, very fast, especially for such a big company. The iteration cycle used is between one and two weeks. At Usable we use two week iterations, but we’re a young and energetic start-up. We have two employees; Apple has more than 60,000. What’s most amazing is that Apple have managed to create a start-up like environment within their corporate environment. They’ve removed the barriers and bureaucracy that prevent other companies doing such amazing things. Usable seeks to emulate that, with the obvious advantage that we are a start-up. We love the rapid development process and actually enjoy the challenge of managing the changes that arise from going so fast – it’s something Usable Requirements is solving.
The final thing to learn from Apple is that, at every single stage of the process of developing a new product, there is a single responsible individual. Apple does not build products with committees of people arguing over the minutia. One persons word is law. Ultimately that was Steve Jobs, famous for his attention to detail and somewhat obsessive nature about making the best possible product. That is a vitally important facet of project development – if no one takes responsibility for something then it won’t get done properly, or even done at all. Again, Usable knows this. We have clear boundaries that set out who is accountable for each aspect of our products, and in Usable Requirements the workflow of sign off is very well signposted. When you use our app you can tell immediately who is responsible for what.
It’s interesting, exciting, and hugely encouraging to know that we’re using the same sort of processes to develop our software as Apple use to build the products that we use every day. We’re looking forward to bring these tools to you.