We use cookies to give you the best experience on our website. In addition to strictly neccesary cookies, third party cookies may track your use of Beehive. If you continue without changing your settings, we'll assume that you are happy to receive all cookies. More about cookies
Beehive is no longer being maintained, and the information presented here may be out of date.

As discussed in a previous reflection it can be easy to focus too much on one area of a services development. This brief reflection looks at the importance of understanding the relationship between the different types of value you want to deliver and using this knowledge to intentionally design and develop services.

By doing so you'll be able to see how different aspects of your service complement or compete with each other and the market, and ultimately have a service which delivers well-balanced User, Social and Financial value.

Through our experience of developing Beehive we've learnt that our approach for realising one type of value can have an impact on another. Most obviously, one of our early strategies for sustaining Beehive was to offer a limited-access free service, alongside a paid for full-access service. Whilst delivering this model we discovered two interesting things:

  1. Financial Value - Because of the scarce and competitive nature of charitable funding people wanted a list of funding opportunities, the bigger the better, and importantly they were willing to pay quite a lot for it.
  2. User Value - The very users we'd set Beehive up to serve (people and organisations with little to no fundraising capacity) were receiving inconsistent User Value unless they paid for full access to the service - which they almost always could not.

This insight raised a dilemma, do we change our market focus and target only those who could pay, or change how Beehive generated revenue. From the beginning we knew Beehive was a tech for good initiative so the ultimate choice was quite easy, but we still decided to take a step back and look at Beehive as part of the wider funding ecosystem. With this view it was clear to see that charitable funders were a key player and their needs and problems had to be considered.

What we knew from user research was that many charitable funders struggled with the amount of inappropriate applications and interest they received. It wasn't that they didn't want people to apply, but instead the mechanisms and tactics they'd put in place for helping people decide if they should apply weren't aligned with how fund seekers were behaving.

Relating this to our other findings we started to see that helping people get a list of funding opportunities alone wouldn't improve the situation for funders, and that it might even contribute to making it worse. In addition, we knew we already had a tool for people to quickly check if they were appropriate for funding, but the business model was preventing the large majority of users from making use of it.

Understanding the relationships and impact that our different strategies for realising User, Social and Financial value had on each other was key to informing the design of Beehive. And its meant we've been able to create:

  • a tool that's free to use in it's entirety when creating a public suitability report;
  • a tool that's able to generate revenue to sustain itself without excluding those most in need of it;
  • and a tool that helps people ensure they only apply to the opportunities they are appropriate for - saving time and effort for both funders and fund seekers.