Flex funding models based on product types
"We have $10 million in funding, and we have one try to get it right. How can you guarantee we won’t fail?”
During a recent innovation workshop with a Fortune 500 company, one of the executives in the room challenged the team with this question. The unease in the room was palpable. None of the company’s prior “innovation initiatives” had ever gone as planned, so why would this situation be any different? You could see the proverbial cogs spinning in everyone’s heads, calculating the amount of time remaining before the purging flames of failure consumed them.
Generally speaking, digital efforts fall into one of these four categories.
| The category | The ask | The characteristics | The approach |
|---|---|---|---|
| Greenfield opportunities | New service offering or new product | Minimal dependencies on current technology, loosely coupled integrations, and undefined or open-ended roadmap | Minimal change management for current employees |
| Process transformation or digitization | Technology enabling efficiencies | High dependencies on current technologies with more well-defined requirements, often driven by internal customers to address an obvious need | Significant change management around rollout |
| Legacy debt resolution | Feature parity rebuilds or monolith sharding | Legacy applications with tightly coupled, monolithic workflows and high dependency on current technologies, challenging change management process, high technical debt, and embedded business logic | Multiple dedicated product teams for oversight, internal insight on an existing product during migration to a new system |
| Mature product | Scaled approach to building predictable output from multiple dedicated product teams | Establish product in need of rebuild and/or feature delivery at scale | Multiple dedicated product teams for oversight, theme-based funding, predictable velocity output |
Greenfield funding model
Since greenfield products are entirely new, a great funding model to leverage is one used by venture capital for startups.
Establish the hypothesis.
Fund with small, incremental rounds.
Validate using data on adoption or retention.
Fail frequently, fail fast. Only when the hypothesis pans out, and the data backs it up should the organization double down on investment.
There are some prerequisites that the enterprise needs to adopt before implementing this funding model.
Establish a product-centric org structure. Enable cross-functional teams that represent stakeholders from both business and development groups.
Embed the product team within the group pursuing the opportunity. Don’t isolate the product team in an innovation department.
Designate seed capital. Establish a pool of seed funding that can be distributed across several greenfield products each year, fostering a competitive environment where winners get rewarded.
Create a culture of failure tolerance. Celebrate the failures as much as the successes. The key to empowered teams is that they aren’t afraid to test ideas and fail.
Set realistic expectations. Nine out of ten greenfield products experience failure in the early stages.
Correlate the amount of seed funding to the product.
Two constants apply to both internal and external product teams, as well as types of builds in terms of complexity.
The size of the cross-functional product team is fixed. An ideal team size is six to ten members. Less than six members implies the team is not covering all of the necessary skillsets (e.g., product design, product management, front-end, back-end, testing automation, DevOps). More than ten members reduces the team’s ability to communicate and collaborate effectively.
The MVP should be feature-lean and viable to release in three to four months. Any longer and the seed investment grows to a point where failure becomes harder to tolerate. With known variables, calculate the monthly burn rate of the product team at roughly 100k. Set the first release and validation gate at four months, with anticipated seed funding for the product capped at $500K and four months of runway plus a minor margin.
Funding successful outcomes
Microfunding at work
Case study: A secure messaging and scheduling APP for healthcare
The company
A privately held company helps hospitals and providers deliver high-quality patient care through a network of 7,200-plus partner providers and over 400 independently run facilities nationwide.
To provide emergency and hospital care, the company’s schedulers book new and existing providers for shifts at the network of healthcare facilities. On an annual basis, the organization treats more than eight million patients. The clinicians need to communicate effectively to staff the shifts to provide high-quality care to patients.
The need
The organization identified an opportunity to collaborate with providers via a mobile application. They wanted shift scheduling, group chat, provider onboarding, and more to be facilitated in one HIPAA-compliant mobile app.
“We have been able to go to market and solve the business need in fewer than six weeks. With traditional waterfall development, this would have been impossible.”
- Senior VP of Information Technology
The approach
The company enlisted Devbridge to de-risk and validate the new product before making a significant investment. After defining a full roadmap, MVP features were limited to those that would provide immediate value to the business.
In just three months, an MVP was delivered with encrypted communications for providers and schedulers to correspond and fill the open shifts faster. Focusing on a subset of features allowed the organization to get the MVP in the hands of users quickly. This approach allowed the organization to measure and evaluate user adoption before making additional investments. The initial adoption trends validated the product and helped secure funding for the extended roadmap.
The analytics
MixPanel analytics provided the business insight into not only active sessions, daily active users, but also business KPIs such as shifts filled, the number of messages exchanged, and more. The company justified the additional investment to continue building the application feature set by using customer data. In seven months, Devbridge shipped over twelve releases to production, each funded incrementally. The strategy of micro-funding, testing, and validating was applied to several other greenfield products, paving the way to a digital transformation of the company.
Process transformation funding model
Process transformation is less ambiguous than a greenfield build as these opportunities are tech-enabled. For example, the business notes an obvious upside based on the automation of a manual workflow or technicians for a generator manufacturer move to capturing payments directly in the field on an iPad app, drastically shortening the time between the origination of the work order and the collection of funds.
These types of opportunities don’t need market validation, so the funding model should be slightly more risk-tolerant than a greenfield model. This tolerance allows for funding chunks to be larger, with fewer gates in the product roadmap.
For process transformation work, it is essential to validate assumptions with frequent market releases—as well as get feedback from internal customers using the application.
Identify necessary funding and structure delivery to maximize value for spend by using this workflow.
Execute a service blueprint to identify opportunities for automation.
Create a workflow map for a particular touchpoint. Identify dependencies and the necessary change management to roll out a new product.
Run a lean requirements workshop to build out the product roadmap.
Estimate the roadmap and establish release gates (e.g., beta, friends-and-family, V1, V2, V3...)
No phase should be longer than four to six months. Divide and conquer if product complexity is higher.
Perform user testing after each release to refine the roadmap and re-estimate the backlog.
Legacy product debt funding model
Legacy system replacement is expensive and extremely challenging to estimate accurately. When the software is monolithic, business logic gets embedded in the codebase, environments are hard to replicate, testing is often manual. However, there are still ways to manage funding and outcomes better than through lengthy waterfall requirements and delivery.
The most successful strategy currently available is a microservices-first approach that obfuscates the underlying legacy applications. Once the services are in place, a gradual rebuild takes place- slicing away verticals of functionality from the legacy application, building new functionality to parallelize processing across both legacy and new apps, to finally decommission the legacy workflows in favor of the new components. Microservices help hide a lot of the changes taking place behind the scenes so that customer-facing, front-end applications operate seamlessly. To effectively implement this approach, the executive team must accept that legacy re-platforming takes years to complete.
First, establish an overarching investment theme for the effort and execute a proof of concept technical spike to establish a baseline for velocity, complexity, and constraints. Once the proof of concept implementation is complete, the product management team can use the demonstrated team velocity to forecast the overall effort. Multiple workflows are parallelized across several product teams. The demonstrated burn rate and the velocity indicate the overall funding needs. Lastly, each product team should own a vertical (not lateral) cut of the functionality. In other words, a product team works across the full stack—from services to front-end of the new application. This vertical ownership reduces dependencies and helps teams stay self-sufficient.
