Screencastify is the #1 screencasting browser extension for Chrome, and is extremely popular among educators. The product and engineering 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 engineering 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 engineering 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 engineering tasks, the team was spinning its wheels.
Ben observed, analyzed, and improved our product development processes quickly and effectively. But he didn't simply take a boilerplate process and apply it. He was careful to listen to our team's specific requirements, preferences, idiosyncrasies, and appetite for change and turn that into bite-sized, custom optimizations that made the most sense for us. His work is already worth the investment and will continue to pay dividends far into the future.
The company had a strong product vision and a team of competent engineers, but too much refinement of features was happening after engineers began writing code. The product team would describe a new feature leaving many details to engineer interpretation, and the engineers 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.
I think it’s amazing how everyone is contributing and seeking for improvement. [You] did a great job establishing that culture of engagement. You asked a lot of questions and cared to figure out what makes sense. I never felt like you’d be trying to do a one-size-fits-all / this-is-how-it’s-done approach, but always made sure everyone understands the reasons for change, stays onboard and supportive.
First thing, I worked with the team to reoriented all engineering procedures and routines around the delivery of features, instead of disjointed engineer to-do items. Every feature has one engineer 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.
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.
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.
General confusion about what's being worked on and by whom seems to be at an all time low. We're doing really well in terms of communication.
Within two months of my arrival, the engineering 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.
Production deployments occur at scheduled times each week and have been routinized to the point that any engineer 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 engineering team. Engineers can continue working at their regular pace and deployments will happen on their set schedule.
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.
I'd strongly recommend Ben to any product team experiencing any sort of growing pains. Actually, I'm confident he could improve any product team, even if you think you've got everything figured out. Like any great engineer, Ben is extremely logical and methodical. His rare talent, however, is taking that approach beyond the code and into multiple aspects of a business - team building, communication, productivity, career development, and more.
5 lessons you can use right now. I will show you how to create a focused, flexible product roadmap and execute like your business depends on it.
Let's talk about what's holding up your team, and where we can find you some quick wins to pick up your velocity.