Building New Customer Requested Features

Everyone Loves Building New Stuff!

Chase Roberts @chsrbrts

💡 Here’s a framework for resolving the decision to build: customer-financed product development. The main idea is building new features might make sense if your customer prospect is willing to pay for them and they are generalizable.

Chase Roberts had a great thread recently about how startups can decide when to build new products that specific customers are requesting. It is one of the clearest frameworks I’ve seen for “customer financed product development”. I encourage everyone to read through it fully.

One of the things I think worth expanding on in the above framework is for the pre-product/early in product stage vs post product market fit stage.

Pre-Product/Early in Product: In the pre product or early in product stage, learnings are probably one of the most important things. It’s the classic “do things that don’t scale” example. A customer may ask for a specific feature that either they don’t have high willingness-to-pay for or is not generalizable, but it still way be worth building. The key is what learnings can you get from building that feature and winning this customer. Perhaps, you will get deep access to their workflows that will be replicated with others or understand the process for how the product will be adopted in a similar org, etc. This is why picking those initial customers is so important. You want to thoughtfully spend your limited resources on the customers that have the highest return on time. At the early stages, this is unlikely to be the highest payer actually. There are tons of tradeoffs to evaluate at this stage, learnings, resources needed, how many other customers are out there that could be similarly optimal, etc.

Many of our open source companies have had this exact decision recently. If they are building cloud-first and a customer is willing to pay for an on-prem deployment, is it worth it to do so? The questions mentioned in the paragraph above helps to answer this question of when it could be. There’s really no right or wrong answer, it depends on the founders, what can be learned from the deployment, and the context of the other customers/potential learnings out there.

Post Product Market Fit: Chase’s framework says it so well not there’s not much to add. I think one area in particular that is worth diving into deeper is why High Generalizability and low WTP is “Consider Building” and No Generalizability and High WTP is “Probably Don’t Build”. Products that are highly generalizable can be used to 1) stave off new competitors, 2) potentially create a product wedge into new customers, 3) enable an additional product customer on-ramp if low wtp can be converted into freemium, and 4) increase existing product stickiness thereby potentially lowering churn. Products that aren’t generalizable may end up hurting the company more by skewing the product roadmap and resource allocation away from areas that the rest of the customer base and future customer base may benefit more from.

Of course, not all decisions can easily fit into a framework BUT it’s a great place to get meaningful discussion started on the tradeoffs to building that new feature/product.