INT3: On how to handle unplanned feature requests
INT3: On how to handle unplanned feature requests
Don't interrupt your teams!
Hello, and welcome to my newsletter!
I’m Karim, and every ~2 weeks I tackle questions or problems I’ve witnessed in startups from the very early stages up to late growth stages.. Much of my startup experience has been in leading engineering organizations, but I cover topics outside of engineering as well.
Send me your questions or suggested topics and in return, I’ll try and answer them through a post to this newsletter.
If you find this post valuable, check out some of my other popular posts:
To receive this newsletter in your inbox every ~2 weeks, consider subscribing 👇
In my previous post I described how as a startup scales, it will start seeing more deals contingent on some feature requests, especially in the enterprise software space. The previous post outlined a simple framework that assesses which of these features to build and why. This post is concerned with the staffing model needed to sustain these requests.
Before diving into the staffing model, it would be helpful to first highlight that these feature requests introduce a tension with planned roadmap items. Your product and engineering teams have presumably planned a roadmap that outlines what they hope to deliver over some period of time, typically over a 1 year horizon. This plan is almost always aligned with the available bandwidth across the product and development teams.
Consider the roadmap shown in the diagram below. This roadmap projects some features being developed across multiple teams - four - over a 1 year horizon. The plan also shows that some teams won’t be immediately available. For example, Team C becomes available in Q3 and Team 4 in Q4. The availability of future teams is oftentimes contingent on hiring.
Let’s assume that sometime during Q2, some deal arises and is contingent on building a feature not on this roadmap. At this point, you have two options. You can either divert resources from either Team A or B to build this feature or not build it at all. Refer to my previous post on a framework to help with assessing which features to build and why. If you do decide to divert resources, you will be pushing out your roadmap by the time it takes you to build this new feature. Realistically speaking, your roadmap will move further beyond the time it takes to build this new feature; context switching isn’t free.
For the sake of this discussion, let’s just assume that this new feature can slot into Q2 and will simply offset your roadmap for Team A by one quarter. The new roadmap will hence look like the diagram below.
The deals keep rolling in and sometime during Q2 another large enterprise deal surfaces which is also contingent on building a new feature. You consult your tried and tested feature assessment framework and decide that this one should also be built. At this point you have two choices. The feature will be built by Team A once they wrap up what they are working on, which they project to complete at the end of Q2. Or you could divert Team B, by stopping them from working on Feature E at which point they can start working on this new feature. Either way, your roadmap is now shot. You are at risk of not being able to project the completion of any roadmap items, not to mention demoralizing your product development teams who have to context switch between multiple features. There is an alternate and better option.
Rather than interrupt your roadmap and have your teams context switching, you can allocate one of your teams to be the Interrupt Team, as shown below. The revised roadmap below allocates roadmap items to only 3 teams: A, C and D.
The above roadmap is my preferred one. It offers a few advantages relative to the ones mentioned earlier. The first is it gives us the flexibility to accept incoming deal-contingent feature requests without stopping on other roadmap items. Consequently, it allows us to project the completion of a subset of our roadmap items. Note, that you will still have to forgo some roadmap items to make room for these interruptions. Under this revised roadmap, features D, G, H and I are pushed out in favor of the Interrupt team. Second, the Interrupt Team now acts as a buffer for the other roadmap teams: A, C and D. Those teams are now shielded by any interruptions, which in turn allows them to focus and deliver on their roadmap items. Don’t underestimate the benefits of focusing.
There is one challenge in building a staffing model to support this roadmap. You have to find a development team that is inclined to across various parts of your product. Recall that you cannot plan for these feature requests, they arise as deals come in and hence can’t be predicted. Therefore, when you staff an interrupt team, you have to find individuals that enjoy working across a large surface area of your product. Those would be individuals that prefer to go broad versus deep into one area of your product. In short you have to build a vertical team that can work across all parts of your product and set their expectations accordingly.
If you decide to build an interrupt team, you should start tracking that teams’ backlog. Ideally this interrupt team is short-lived: no more than a few quarters. Your hypothesis should be that this team will handle a few edge case feature requests, which once fulfilled allow you to resort back to your plan of staffing all teams to work on your roadmap items. You should continuously test this hypothesis. One way to do so is to track this teams’ backlog. If it continues to grow over time this suggests some product gaps that you should address structurally versus staffing an interrupt team. If on the other hand, the backlog is small and diminishing over time, then you know you’re getting closer to dealing with these edge cases.