Building grants management at Bright Funds

Chris Chappelle
5 min readMar 13, 2018

First of all: why?

Bright Funds helps companies run their giving, matching, and volunteering programs. Time and again, customers asked how we could handle their company grants as well so that they wouldn’t need to bounce between different products to manage all of their social good programs. Building an entirely new product is a lot to bite off, but we knew that there was a need. So we wanted to answer the question:

“Can we and should we build a grants management product and how long might it take?”

What’s out there

Mapping prototype flow and inspiration demos

Our team has been working in the charitable giving space for several years now, so we had a good idea of what a grant management product consists of. With that said, because we were starting from a blank slate we researched what products were available, what current customers loved about what they use now, and what was on their wish list. We quickly learned that:

  • Companies are looking to achieve the same thing: grant money to effective nonprofits that match their company or foundation goals.
  • They follow roughly the same grant making process: 1) A nonprofit submits a request for a grant that outlines what they will use the money for and why they are a good fit for this grant 2) The grant request gets passed through a few layers of review 3) Based on the reviews, the decision makers give a final yes or no decision 4) If the grant request is approved, the nonprofit receives a grant and eventually reports on how the money was used and what the impact was.
  • There are slight variations of each step. For example, Company A may have two levels of review while Company B has three.
  • These slight variations have resulted in grant products becoming highly customized even though the core elements are largely the same.
  • Grants are typically handled by a small team. Usability was largely ignored as a tradeoff for configurability with the assumption that that small team would learn how to operate the product with time and training.
  • Because the products are built for experts, processes like reviewing a request (which might be done by various people outside of the grant team) are complex and convoluted.

Based on what we learned, we wanted to answer these questions

  • Can we build a grant product that standardizes the core common elements of the grant process?
  • Can we prevent the need for hands-on configuration so that companies have the power to control their own processes?
  • Can we make the product so easy to use that there is no need for any training — whether you are running the grant program or reviewing requests?

Building a prototype to see into the future

Building out the prototype

Answering these questions before sinking in extensive time from the team would help us decide whether or not we wanted to invest in building a grants management product at all.

So we mapped out the core features, mapped out the grant process, and built a quick prototype of the key and most difficult workflows. This allowed us to see into the future at what a potential product might look. Starting with the most difficult problems also removed some of the fear around not knowing how we might build some aspects of the product. For example, we were unsure how we might standardize core parts of the grant process while also providing enough flexibility so that the product can adapt to a range of companies. The beauty of building a quick and imperfect prototype right off the bat is that we could answer some of the lingering concerns.

We learned that a lot of the problems around the grants management process were indeed very feasible for our team to build.

Standardize the core elements of the grants process

Standardizing core steps of the grant process allowed us to create a clear and uniform navigation

We saw that across companies the grant process follows largely the same steps. These core steps are built directly into the product.

This is great because now that there is a built in set of guide-rails, we can lead companies down the process of setting up or modifying their own grant programs. It also provides a nice navigation structure in several parts of the product.

Provide flexibility where flexibility is needed

There are some parts of the grant making process where flexibility makes sense. For example, every company will review grant requests in a slightly different manner depending on their teams and processes. Some companies ask nonprofits to submit a proposal prior to the full grant application. Others only ask for a grant application. We embrace this configurability where it makes sense.

Empower companies to take control of their programs

Standardizing the grant process and building in flexibility where needed allowed us to build a grant program setup process that companies can manage themselves rather than reaching out to use when they want to make a change to their program (the status quo when it comes to managing grant products).

Provide clarity

We don’t think you should need training to use a grant management product. The work of granting money to organizations is important and undoubtedly requires experience. With that said, software should make the job easier so that you can use your experience where it makes sense…not towards figuring out how to navigate a software product.

The result

We used this prototype to spark conversations with current and potential clients to collect feedback and see whether we were on track or missing the mark. Moving from idea to prototype quickly gave us the confidence that our team should build a grants product. We were then able to move from prototype to built product, which allowed us to collect concrete feedback from actual people using the product.

For example, we quickly learned that location is a recurring important aspect for grants — what cities and communities does this grant impact. Aggregating and displaying impact results is also key in quickly understand the effect of what all of the grants have achieved. Both of these ideas are being worked on now.

The team largely consisted of three people. Two engineers — Robert Schooley and Julie Miller — and myself as the designer. A small team requires less oversight and allows the team to shift gears quickly. Feedback and guidance also came in from the VP of Engineering and CEO.

--

--