In a previous post, we shared how we uncovered a persistent user need: EL administrators wanting to share content from our system with families, a use case that would introduce us to an entirely new user type we had never supported. We validated demand for this need by testing willingness to pay before committing to full-scale development.
With evidence of value secured, the next challenge was equally daunting: how do we transform this concept into a market-ready product in just ten months - with a lean team of two engineers, one PM, and one designer?
This post takes you behind the scenes of how we moved from incubation to delivery, turning a fragile hypothesis into a reliable, scalable feature set that districts could trust.
Mapping the Risks and Attacking the Riskiest First
With business viability de-risked, our focus shifted to the next existential risk, could we even build this? To make real progress, we had to answer tough questions:
- How would our systems ingest and manage family contact data at scale?
- Could we build authentication that worked for multi-lingual families with minimal user friction?
- How would we reliably and securely deliver content artifacts outside our system?
Following Teresa Torres’s Continuous Discovery Habits, we mapped assumptions across value, usability, feasibility, and viability, then ranked them by risk.
Rather than chasing easy wins or working sequentially, we embraced the “monkey-before-the-pedestal” principle: teach the monkey to sing before building the pedestal. In other words, we steered directly into our biggest risks. Instead of a simple technical spike, we built a functioning hybrid prototype - part Figma for the low-risk elements, and real code for the uncertain pieces - to validate the riskiest technical challenge: wrapping and delivering the external content artifacts.
“Building to learn” often provides the clearest answers and is the best path to surfacing new risks.* Some might question whether early engineering effort is wasteful. We believe the opposite: the greatest waste is building something wrongly validated. By treating the prototype as an experiment - cheap, fast, and disposable - we ensured the value lay in the learning, not the artifact itself.
Seeing the “monkey sing” early gave us confidence the core solution was buildable before deeper investment.
*The pace of gen AI tools is changing this landscape further, live-data prototypes are now faster and easier to create, allowing one to learn while minimizing engineering effort even further.
Moving From Incubation to Delivery
Once we had de-risked the “existential” uncertainties, it was time to shift from incubation to committed delivery, while still carrying forward our discovery mindset and lean principles to prioritize learning outcomes over outputs.
We set a clear launch goal: release by Back to School (July), 10 months away. Working backward, we stripped the solution down to its Shoddiest Viable Product (SVP) and planned a sequence of end-to-end milestones to reach it.
Each milestone was:
- A complete end-to-end version of the product (gradually evolving our Frankenstein prototype into a more polished, real system).
- Explicitly designed to unlock learning, not just deliver features.
Early milestones reduced feasibility risks (e.g., authentication, ETL). Middle milestones addressed viability (pricing, packaging). Final milestones focused on usability (user friction, implementation). Tackling the build in this risk order allowed us to learn and pivot quickly. For example, we discovered our hacked-together content artifact - the biggest earlier risk - was both easy to build and valuable enough in its rough form. We avoided unnecessary refinement, saving significant effort.
This approach gave us growing confidence at every step and ensured we could pivot, iterate, adjust, or even walk away if new learnings warranted it, long before full-scale launch.
Learning from Early Adopters
For the final milestones, the best way to uncover usability and implementation risks was to put the product in real users’ hands. As we closed initial deals during testing, we invited those districts to use the product in live settings.
Their feedback surfaced unexpected usability issues and implementation challenges we had underestimated. Because we still had time and flexibility, we were able to swarm on these problems and resolve them before the broader rollout, ensuring a smoother launch and stronger adoption.
Importantly, this phase also strengthened cross-functional alignment. Sales, marketing, success, and engineering worked in lockstep so that messaging, onboarding, and support accurately reflected what the product could deliver - critical for building trust with both customers and internal teams.
The Result
About 12-18 months after that first design sprint, we had it: a market-ready product that districts could buy and educators and families could use.
But the deeper win went beyond shipping a successful release: we institutionalized a discipline of continuous discovery. By resisting the temptation to overbuild and by tackling our riskiest assumptions in deliberate order, we avoided months (and millions) of wasted effort.
More importantly, we built organizational muscle. The risk-mapping framework and milestone alignment approach we created are now repeatable patterns guiding multiple bets across our portfolio. What began as a single experiment has become a playbook for turning uncertain opportunities into validated, revenue-generating products, strengthening both Ellevation’s strategy and our culture of evidence-driven innovation.
