🎓 When does customer feedback become custom development?
by•
Customer feedback is essential for us building a B2B SaaS product, but not every requested feature belongs on the roadmap.
We currently evaluate requests based on:
Whether several customers have the same problem
Whether the request supports the product’s core use case
How much value it would create
The ongoing cost of maintaining it
The difficult case is when an important customer requests something valuable that only applies to their particular workflow.
How do you distinguish useful product feedback from custom development?
Do you use a specific framework, or is it ultimately a judgment call?
44 views
Replies
Hey!
Before you build, write down the condition that would make you remove the feature. If the answer is "we'd take it out if that one customer left", it's custom development, and the number of people who also asked doesn't change that.
The cheaper test in practice is the request can be expressed as configuration or data instead of a branch in the code. A limit set per account, a field someone defines, a template they fill in: that's product, and the next customer with a similar workflow gets it without you writing anything. A code path that only runs for one account is custom work however many people say they'd like it, because every later change to the core has to keep that path alive
I run several small products rather than one product with several modes, partly for this reason. Separate things can drift apart without asking each other for permission. The cost doesn't disappear, it moves into duplicated setup, and I'd rather pay there than in a core that can't move
@siarheihamanovich Thanks, this is really helpful.
I like your test: if we would remove a feature when one customer leaves, it is probably custom work.
Keen was built from a problem our founder experienced himself, so his knowledge helps us decide what belongs in the product. But I can see how too many special cases could become difficult as we grow.
How do you decide when something should become a separate product?
@magnus_ditlev_sorensen The test I use is whether the two things share a visit
Not if they share code, since that's usually solvable with a library. A separate product is one where somebody arrives for it, does the thing, and leaves without ever touching the other one. Different moment, different job, often a different person. If a Keen user would need a second reason to show up on a second day, that's a product
The cost side is the honest 50/50. Every separate product needs its own landing page, its own support, its own deploy and its own reason to be found. So the practical gate is whether the thing could earn a first visit on its own. If nobody would go looking for it by name, it's a feature in a product costume
Where I got this wrong: I split early, and splitting cost me the people who genuinely wanted two of them. I had to build a way back across the split, a picker in front of a few products that carries your input over when you switch so you don't retype it. That's the part worth deciding in advance
@siarheihamanovich That makes a lot of sense. “Do they share a visit?” is a much easier way to think about it.
In Keen, managing partners, leads, rewards and reporting are usually part of the same visit and the same overall job. Your point about splitting too early is also valuable, especially when the same users actually need both products.
Thanks for explaining it so clearly.