Home > Case Study: Screencastify

Case Study: Screencastify


Screencastify is the #1 screencasting browser extension for Chrome, and is extremely popular among educators. The product and development teams focus relentlessly on making the best possible product for their core user base of teachers in classrooms.

Here's how I worked with them to create a well defined product development pipeline, achieving a steady, predictable development cadence, weekly release schedule, and reliable model for forecasting the delivery of development milestones.


The C-suite saw a new market opportunity and decided to build a second product in addition to their flagship product. To make sure they were first to market, they temporarily devoted their entire 4-person development team to the new product. The team was working on borrowed time, since every day that the new product didn't ship was another day they were putting off maintenance and feature development on their existing product. Lacking a coherent roadmap describing the path to market, it was impossible to predict when the new product would be ready. And with no defined process for turning business goals into development tasks, the team was spinning its wheels.


The company had a strong product vision and a team of competent developers, but too much refinement of features was happening after developers began writing code. The product team would describe a new feature leaving many details to developer interpretation, and the developers would immediately break those features up into technical to-do items.

Confusion grew as time passed and the context for these technical to-do items was lost. By the time a complete feature was delivered, it had usually diverged significantly from what the product team had envisioned, and the feature would have to be clarified and reworked.

On top of this, there was no defined process for prioritizing work based on business value. Features, bugs, and infrastructure chores would be addressed based on whatever seemed most urgent at the time. There was no clear finish line and therefore no way to measure progress.


Reorient development and product routines around feature delivery

First thing, I worked with the team to reoriented all development procedures and routines around the delivery of features, instead of disjointed developer to-do items. Every feature has one developer who is responsible for delivering that feature top to bottom. To make this possible, the product team defines explicit acceptance criteria from the perspective of an end user. Now when a feature is delivered, the Product and QA teams were much more likely sign off on it the first time, without costly confusion and rework.

Milestone-based product roadmap

I also worked with the Product team to define coherent milestones against which we could track progress. To keep from getting too focused on product delivery at the expense of accumulating technical debt, we defined a flexible policy for prioritizing ad hoc bug fixes and maintenance chores into those product milestones.

Forecasting model for milestone completion

Within several weeks, we had achieved a steady, reliable cadence of feature delivery. This cadence, combined with the new milestone-focused roadmap, enables the product team to reliably forecast the delivery dates of individual milestones, as well as assigning a degree of confidence to those forecasts.

Key Results

Less than 15% variance week over week in features delivered means reliable delivery forecasting

Within two months of my arrival, the development team was delivering features at a pace that fluctuated no more than 15% week over week. It is now possible to accurately forecast the delivery of milestones, as well as visualize the effect of changing scope on those delivery windows. This makes for clearer communication of progress to key stakeholders such as investors, and enables marketing and other business initiatives to be coordinated with the product delivery timeline.

Weekly scheduled deployments with no costly code freezes

Production deployments occur at scheduled times each week and have been routinized to the point that any developer can execute them. The product team always knows when they will be able to see finished work in production, and there is no separate code freeze or deployment prep phase for the development team. Developers can continue working at their regular pace and deployments will happen on their set schedule.

Team has demonstrated ability to maintain process and self-organize

Through a structured phase-out of my involvement, the team has been able to take ownership of all elements of the new process, maintaining their pace of delivery in my absence. Periodic team retrospectives create productive discussion for improvement and commit routines to institutional memory with little or no documentation overhead.

Get help delivered to your inbox

5 actionable lessons will teach you to create a coherent product roadmap and execute like your business depends on it.