I remember our early whiteboard sessions vividly - We struggled to define the core experience, grappling with discussions like, "It's sort of a project webpage builder.. but sometimes it needs to feel like doing your tax returns."

Initially, the product was broad, reflecting our limited understanding of user needs. With each iteration, we narrowed our focus, uncovering specific unmet needs for foundations and grant-makers.

By the fifth version, we'd built a robust, and configurable reporting tool, that allowed grant-makers to showcase their work in a way that demonstrated both qualitative and quantitative outputs and outcomes - in a way that was tailored to the strategic themes of each philanthropic foundation.

Since Foundgood's product development was primarily grant-funded, we operated quite differently from typical VC-backed teams. We had a lean budget, so we often worked with a skeleton crew: a technical product manager, two engineers (1 × front end and 1 × back end), and myself.

Grant funding also meant we usually focused on one major project a year, with multiple outcomes and features to deliver. Time was always tight, so we needed a process that could get us from concept to code fast. Before any phase of work, we would spend a good amount of time scoping, prioritising and aligning on usually a fairly ambitious backlog, so that everyone knew what exactly needed doing and could execute with claritiy.

We built the front end modularly both in terms of our designed and coded artefacts, which let my design definition and the front-end engineers' development happen in unison. This meant we could move from defined concept to built code incredibly quickly.