Feature dealing-making
A framework to assess feature deal-blockers
In the early days of a startup, nothing takes precedence above trying to establish product market fit. The startup is almost entirely dedicated to validating a critical hypothesis: can we build products that serve customers in some, hopefully large, market? In this seminal article, Marc Andreessen defines PMF:
"The customers are buying the product just as fast as you can make it -- or usage is growing just as fast as you can add more servers. Money from customers is piling up in your company checking account. You're hiring sales and customer support staff as fast as you can."
I’ve been fortunate to witness this phenomenon twice in my career thus far. It’s an exhilarating experience, one that adds lots of healthy tension to the company. Growth can be energizing, but it is also very hard to navigate. One area that is often under-looked during the early phases of PMV is one I call “feature deal-making”. Let me explain.
A startup in the early throes of PMF is starting to rapidly scale, mostly on the GTM side like the sales and marketing teams. That is expected. After all, if the startup has validated that it has PMF, then a natural consequence of this is to scale the parts of the business that can dramatically accelerate demand for its products.
As more sales reps are hired and as they ramp up, sales opportunities, or deals, start to flow in. However, not every incoming sales opportunity is perfect fit with the startup’s current product. There will inevitably be some % of opportunities that require some features that the current product doesn’t fulfill. As the deal flow increases, so will the number of deals that are contingent on some feature enhancement increase.
The increasing rate of incoming deals, which is good, and the expected increase of deals contingent on some feature in turn introduces some friction between product + engineering teams on one hand and the sales team on the other. The sales team, understandably, desires that these features be fulfilled as quickly as possible to win the opportunities at hand. On the other hand, the product and engineering teams are trying to balance scarce resources and the overall fit of these feature requests from a product perspective. In short, the sales team desires that all these features be built, while the product + engineering teams are trying to assess this demand by answering two critical questions: why build this feature and how.
One critical tool to help evaluate these incoming feature requests is illustrated in the 2x2 below. For each incoming feature request, you want to answer two questions. Is this feature aligned with the overall product strategy? Meaning, would I have this feature on my roadmap regardless of the current customer ask? The other question is do I have the resources to build said feature. Answering these two questions will help you assess which features to build and at a minimum give you a decision making framework to assess these incoming requests.. Let’s walk through each quadrant starting from the top-left.
The top-left quadrant is fairly obvious. The incoming feature request is aligned with the product strategy and we have the resources to build it. We should proceed with building it. It is to be noted that even though the decision making is very obvious in this case, you will rarely find yourself in this quadrant. Odds are you are always resource constrained, especially on the engineering team.
Moving on to the quadrant to the right of this one, in which the request is aligned with our roadmap, but we don’t have the resources to build it. This one is tricky, and all too common. Remember, you will almost always never have enough resources, so by default you are in the “not enough resources” column of this 2x2. You have two choices when you find yourself in this quadrant.
The first is to punt on the feature and build it when resources free up again. This can delay the deal, or even end up killing it all together depending on the urgency of the feature request and when resources free. The second option is to trade this feature with some other feature the engineering team is working on now. You would be swapping this feature for another in-flight one and asking the development team to context switch from one feature to this one. If you do this, I would recommend that you have some form of written commitment from the customer before you divert these resources. More importantly, is to try to minimize context switching a product development team; it has devastating effects on morale and productivity. I wrote about this in a previous article here. This should be the option of last resort.
Moving now onto the bottom-right quadrant. A feature that isn’t aligned with your product strategy and we don’t have the resources for should not be built, at least not immediately. There are some exceptions to feature requests that aren’t aligned with the product strategy, which we will come to in the last quadrant.
This last quadrant brings up the scenario where a feature is not a strategic fit, yet we do have the resources to build it. I would always err on the side of not building it, because you do not want to be building features that don’t accrue to more than 1 customer. You want to build products that many customers will buy and not just one. Additionally, you do not want to set the precedence that you can build features even though they do not fit the overall product strategy. You need to be consistent, especially as these decisions impact sales. There are however a few exceptions to this default, which can also be applied to the quadrant to the right of this one.
The main exception is when the request comes from a critical, or high profile customer. While building this feature will only benefit this single customer, you might benefit a lot more than just winning that 1 deal. You might get tremendous market validation or perhaps a critical customer testimonial. If winning this deal can push your product and company to a higher elevation, then by all means consider going for it. Another obvious exception is the size of the deal. If the opportunity at hand is substantially larger than your typical deal size, then by all means you should entertain the idea of building it. You do need to be careful and consider the cost implications of building this feature and more generally acquiring this customer. Will they end up derailing your roadmap and your product strategy? If the answer is yes, then perhaps you pass on this opportunity.
There’s one last critical component to this framework: decision making. There are 3 personas that are involved in the decision making process for this framework. These are Product, Sales, Engineering. The representatives from these functions could be the Head of Product, Head of Engineering, Head of Sales, CTO and the CEO. Although there might be 3 personas involved in the decision making process, the decision typically lies in the hands of the Head of Product, CTO or CEO.