As a B Corporation, Azavea occupies the space between a purely for-profit professional services company and a mission-driven nonprofit organization. Our staff is committed to our mission of taking on work that has a positive civic, social, or environmental impact. It is this drive that enables us to deliver high-quality software solutions that serve a larger purpose. While we are hired for our services work, the software we build often takes on a life of its own. Though they may have very different origin stories–grant awards, federal grants, or internal software–these projects all follow a version of the product life cycle. They grow, live, and eventually retire just like any product.
The difference for us, however, is that we lack the copious outside investment commonly needed to launch, build, and support a product. Because of this, and because we need our services work to pay the bills, we have to support products with only a share of our available time and resources devoted to them, an approach known as bootstrapping. At Azavea we have years of experience bootstrapping products from cradle to grave. It’s the only way many important but underfunded projects can support the development of a software product. We’ve learned many lessons from our experience on these projects and have distilled them down into a few key insights. Here are five strategies we use to build successful bootstrapped products.
Strategy #1: Fit in customer feedback gathering whenever possible
As a professional services firm, our services work generally takes priority over product development activities. We don’t have the resources for full-time staff dedicated to customer success. Instead, we make a concerted effort to ask for feedback whenever we have a call or email exchange with a user, especially if the conversation is around a support issue. We also spend some extra time with the handful of users that we know are consistently active. OpenTreeMap, for example, has had a few clients that have been avid users since its launch in 2011. We engaged those clients frequently and their input helped shape some of the features.
In other cases, we treat other teams within Azavea as the “client.” The impetus for building GroundWork was an internal need to create training datasets for our machine learning work; other general-purpose labeling tools weren’t able to handle the complexities of geospatial data. At first, we built a basic version of the application and test drove it for about six months. After that–and based on conversations we had with potential professional service clients at the time–we were confident the app we built could provide value to the field and should have a life beyond that of an internal tool. In retrospect, building an application to meet an internal need was a logical extension of the work we do routinely to create and maintain open source libraries that we create in order to deliver on our own projects, like Raster Vision, PySTAC, and Loam.
Strategy #2: Squeeze tasks in whenever schedules allow
All engineering teams at Azavea have client projects and their deadlines are the primary drivers of our development schedule. Unless a user discovers a critical bug that is significantly impacting the application performance, product work has to wait until we have room in the sprint. In an ideal scenario, we set aside a percentage of time each sprint to support product development work. We set the expectation that the percentage may increase if we have additional time but it should rarely decrease (if ever). That works…sometimes. But when it does, how do we decide what to work on?
Our PMs and technical leads continuously maintain an active and prioritized backlog of features we want to work on. We prioritize small features that pack a big punch that we can get out quickly whenever possible. In some cases, we organize what we call “bug bash” days where two or more developers focus on correcting known bugs. Finally, if there is an experimental feature that is of interest to anyone in particular, he/she/they can utilize the 10% time benefit, using up to 10 percent of their working hours to research, test, and build the feature. Some of our most interesting features have come out of our colleagues’ 10% time projects!
Strategy #3: Leverage research-focused or industry-related funding
As with any company that develops products, funding is a constant consideration. At Azavea, we’re lucky enough to have seed funding in the form of 10% time for almost anything. Taking a step up from there, a number of federal agencies provide grants for Small Business Innovation and Research (SBIR). If there’s an SBIR opportunity related to large-scale geospatial data processing, machine learning, increasing civic engagement, or using satellite imagery for environmental purposes, you can be sure that we have at least considered submitting a proposal. Temperate, for example, was created thanks to a series of SBIR grants from the US Department of Energy (DE‐SC0011303) and was most recently supported by the US Department of Agriculture (USDA-NIFA-SBIR-006649).
In addition to SBIRs, we’re constantly on the lookout for any funding mechanisms open to for-profit organizations (directly or indirectly). We also frequently work with partnering organizations that share our belief in the mission or impact we’re hoping to achieve. Having at least one person on the team (usually the product manager) immersed in the product’s field is key. Usually, you can develop a network of familiar faces from attending conferences (in pre-COVID-19 times), signing up for industry newsletters and updates, and generally keeping up-to-date on trends in the field. This can lead to potential partnership opportunities or joint grant proposals being brought to you by others.
For example, we developed DistrictBuilder for the last decennial census but have since maintained a presence in legislative redistricting through blog posts and attendance at the National Conference of State Legislatures (NCSL). When a new nonprofit initiative, Draw the Lines PA, won funding from the William Penn Foundation to create a grassroots community redistricting effort, they sought us out as a technology partner because of our reputation in the space.
Strategy #4: Be honest
At its core, Azavea has a set of values that serve as the Northstar for our decision making. We sincerely believe our products have the potential to have a positive impact. Sometimes, however, our ambitions outstrip a product’s actual use. In those cases, the best solution may be to stabilize but not update or enhance the application.
We took this route with OpenTreeMap: we continue to support the application but are no longer actively developing new features. Cash flow is key. If the software works with just a little bit of maintenance, the savings from foregoing new development can often enable the product to stay afloat, rather than accruing unsustainable costs that can lead to a shutdown. Whether a product is just beginning or is more mature, be transparent about your response time. If a user expects that you won’t be able to get to a support issue immediately, it helps them plan and manage expectations.
Strategy #5: Stay agile
As a software engineering firm, agile is a part of our day-to-day life. Left to our own devices, we would prototype and iterate much more than most of our professional service clients’ budgets allow. One extreme example: the client is a nonprofit that funds the work through a grant proposal that requires specific deliverables; there’s not a lot of room to pivot there. However, product work can and should be much more flexible, driven by market need and user feedback, and open to significant changes.
In response to COVID-19, for example, we altered our 2020 Q2 roadmap feature list for Open Apparel Registry (OAR). Oar is an open source database of facilities in the global apparel sector that works toward improved supply chain transparency. Azavea serves as the technical provider for OAR. We worked with the stakeholder engagement team and the OAR board to discuss what features could be added to OAR to address changes in apparel facilities due to the pandemic. When facilities started producing personal protective equipment (PPE), we adjusted the OAR interface to support uploading and searching for specific types of PPE and viewing contact info for the related facilities. This feature will be available in the next month and will hopefully assist groups in searching for and sourcing PPE.
Summary
Bootstrapping a product may not be as glamorous or high-profile as raising a Series A round of venture capital, but it’s not without its perks. Sure, building out a product quickly, making those first sales to early adopters, and getting to market first is exhilarating and rewarding. But there’s also a tremendous amount of pressure to hit your targets, demonstrate continuous improvement, and achieve product/market fit, even if the product the market wants is not the one you want to build. If you’re like us and you don’t have that kind of time or resources to devote to product development, these five strategies can help you iterate, prioritize, and build the types of products you want to see built. Our products are created to have a positive impact on the world–it may take us longer to get them out there, but they’re out there for a reason.