Last week’s decision by Samaritans to close their controversial Radar app has come as no surprise. The third sector is pretty good at running projects that help vulnerable people. But when it comes to building digital products and services that do the same, most organisations are still fishing in the dark.
Even big, well-funded organisations struggle. The failure of Radar shows that having good resources and a national profile doesn’t necessarily lead to a quality end product.
Grant funders and commissioners could help. But few have experience of funding digital products and most of their systems are geared up to supporting traditional, service based projects – not innovative ‘social tech’ products.
So for most charities and social enterprises the task of turning their passion and expertise into a successful tech product is usually, and sadly still, a case of trial and error.
Their subsequent failure shouldn’t be surprising.
Why Many Apps Fail
Poor methodology, too many upfront assumptions or even simply a poor choice of tech partner are just a few of the pitfalls charities stumble into. In the case of Radar it was poor research and user testing around the privacy implications of their app’s core concept.
That’s why Comic Relief commissioned James Boardwell and myself to produce Learning from the Labs: How to fund and deliver social tech for charities and social enterprises. It’s free and you can download it in one click here.
The guide is based on best practice from across the ‘social tech’ sector and is pitched at charities with great ideas for apps and online services but either no money or no clear methodology for building one. It also contains advice for funders who are trying to adapt traditional grant making programmes to support more tech-building projects.
“It’s so easy to come up with ideas. Being able to realise those ideas is the real challenge.”
Dan Sutch, Head of Research, Nominet Trust
Let’s have a look at three common pitfalls and what can be done to avoid them.
Poor Methodology
My experience is that too often we try to apply traditional project approaches to building a digital product.
But Prince 2 and all its derivatives won’t work no matter how well you apply them. That’s because building a new product is like building a new business:
You can’t be certain if your problem is the right problem to solve.
You can’t be certain how your solution will fit into people’s lifestyles.
You can’t be certain how you’re going to sustain the product once your funding runs out.
Pretty much everything is uncertain, making it difficult to plan what the product will do, look like or how users will interact with it!
My learning from the tech startup sector suggests there’s three tools and methodologies you can use to increase your chance of building the right product, in the right way, to solve the right problem:
- Adopt a lean approach, validating your initial hypotheses about both problem and solution and using learning, not product development, as the ongoing measure of success
- Use an agile approach to the product’s actual build, working with your developers in short sprints that work well with lean processes
- Use a product roadmap, a short term planning tool that allows for uncertainty and supports an iterative process
Too Many Assumptions
The old adage ‘to assume makes an ass out of u and me’ is as true in the tech sector as in the rest of life. I’ve seen too many well-intentioned digital projects built on the energy of a ‘great idea’ fail because they made a load of incorrect assumptions about how their idea should look and what it should do.
I’ve done it myself, several times.
When a product fails it’s usually because there’s a core assumption that hasn’t been properly challenged and tested before the design and build phase.
For example, Radar failed to test its assumption that regular twitter users would be ok with the app alerting Radar users if they posted messages that suggested suicidal thoughts. As this feature was part of Radar’s core concept, to remove it would be like taking a leg off a three legged stool. The product wouldn’t work or achieve the goal it was designed to. For a more in-depth analysis of Radar’s technical faults click here.
Similarly, tests based on what features users say they would like or what they think they would use tend to deliver misleading results. Tech author Chris Anderson uses the example of a fast food company that asked 1000 people if they’d buy a low-fat burger option if it was on their menu. On the strength of 90% positive replies they developed the burger. But when faced with the real life choice customers overwhelmingly brought their usual burger. The low-fat option was soon dropped.
What people say is not usually a good indication of what they will do. If you don’t test your assumptions then proceed at your peril.
Poor Choice of Tech Partner
It’s easy to go with who you know or, if you don’t know what you’re looking for, to be swayed by the web developer with the nicest looking website.
But how they look and what they do may not be what your project needs.
You need to have a robust process for choosing a tech partner. If you don’t then you’re likely to end up with a creative agency trying to build you an app or a traditional software company trying to use waterfall methods when your product needs agile, iterative methods.
Just like in carpentry where you need the right tools for the job, you need the right developer specialisms for the product.
Broadly speaking you’ve two routes to finding the right developer:
- Identify developers with a broad skillset, a good track record in user-centred design, experience in your sector and comparable values to your organisation. That way they are likely to have a high level of empathy with your users and a range of skills to build a product that meets them.
- Hold off from employing one until you have completed your research and tested your major assumptions. That way you will have a more confident problem statement and the contextual data you need to inform the type of development approach required.
To help yourself choose the right tech partner you should also learn some of their language. You can do this just by asking questions and reading up. It’ll mean you have more meaningful conversations and make more informed hiring decisions.
The Other Pitfalls
There’s too many to list here! But a lot of the main ones are covered in the Labs Guide. My hope is that it will save the sector a lot of time, money and failed products, and lead to the development of some really great ones.
The guide is available for free in one click here.
