3 ms·

This is great feedback, and definitely something we'll need to think about. I had a similar issue at a previous startup I worked at, where we were basically bui

This is great feedback, and definitely something we'll need to think about. I had a similar issue at a previous startup I worked at, where we were basically building SaaS tools for logistics departments at commodity trading companies, and everyone had different edge cases/integrations they wanted from us. It's definitely a rabbit hole I want to avoid... You mentioned Gitlab, and we're trying to figure out how we can borrow from the playbooks of companies like them (e.g. Mattermost, PostHog, etc.) For now, we're just focused on getting users to figure out what the most common feedback and feature requests are, but longer term we plan on carving out a smaller niche and figuring out what our "target persona" is. Curious, do you have any advice on how to avoid these pitfalls?

eggbrain 6y ago
> Curious, do you have any advice on how to avoid these pitfalls? I can tell you some things I've found helpful, but I think sytse (https://news.ycombinator.com/user?id=sytse https://news.ycombinator.com/user?id=sytse) or antirez (https://news.ycombinator.com/user?id=antirez https://news.ycombinator.com/user?id=antirez) could give better advice than I ever could. Off the cuff, for me it always comes back to having a good filter -- which can take time to develop, and can depend heavily on what your goals are with the open core part of this, along with what the goals are of the company. For example, if 10000 users want support for feature X, but 10 users are willing to pay/upgrade to support feature Y, and these features don't overlap (or are mutually exclusive), you many need to make a choice as to which way your goals will point you. Luckily, there will be also a ton of features/improvements that will neatly overlap with everyone, and so you can make everyone happy as well. For prioritization of those, there's a lot of things you can do, but I always like this article's approach: https://www.defmacro.org/2013/09/26/products.html https://www.defmacro.org/2013/09/26/products.html. Another useful tool could be analytics -- the people that use your product the most are usually the people that become your biggest supporters, best suggesters, and paid clients. This might be a bit tough since if you add in an analytics tool to the codebase anyone could rip it out when they have access to the code, but you could do things like watch who is constantly submitting tickets / issues, reaching out via email, mentioning on social media, etc. Just some quick thoughts, but by no means am I an expert here.
- areichert 6y ago
  Thanks for the reply! This is super helpful :) The defmacro article was a great read, definitely some great points in there. We're starting to realize how important having a good filter is -- a ton of people have opinions on what we're building, and we have to figure out how to distill/filter that feedback effectively (because a lot of it likely falls into the "distraction" bucket haha). re: analytics, that's also something we're trying to figure out how to do well -- like you said, it's tricky if folks can just rip out that code if they want to, but we're hoping that we can set up analytics tools that are beneficial to both us (for product insights) and our customers (e.g. to make sure everything is working well for them, alerting them to updates, etc) Thanks again for your thoughts!

eggbrain 6y ago

> Curious, do you have any advice on how to avoid these pitfalls? I can tell you some things I've found helpful, but I think sytse (https://news.ycombinator.com/user?id=sytse https://news.ycombinator.com/user?id=sytse) or antirez (https://news.ycombinator.com/user?id=antirez https://news.ycombinator.com/user?id=antirez) could give better advice than I ever could. Off the cuff, for me it always comes back to having a good filter -- which can take time to develop, and can depend heavily on what your goals are with the open core part of this, along with what the goals are of the company. For example, if 10000 users want support for feature X, but 10 users are willing to pay/upgrade to support feature Y, and these features don't overlap (or are mutually exclusive), you many need to make a choice as to which way your goals will point you. Luckily, there will be also a ton of features/improvements that will neatly overlap with everyone, and so you can make everyone happy as well. For prioritization of those, there's a lot of things you can do, but I always like this article's approach: https://www.defmacro.org/2013/09/26/products.html https://www.defmacro.org/2013/09/26/products.html. Another useful tool could be analytics -- the people that use your product the most are usually the people that become your biggest supporters, best suggesters, and paid clients. This might be a bit tough since if you add in an analytics tool to the codebase anyone could rip it out when they have access to the code, but you could do things like watch who is constantly submitting tickets / issues, reaching out via email, mentioning on social media, etc. Just some quick thoughts, but by no means am I an expert here.

areichert 6y ago
Thanks for the reply! This is super helpful :) The defmacro article was a great read, definitely some great points in there. We're starting to realize how important having a good filter is -- a ton of people have opinions on what we're building, and we have to figure out how to distill/filter that feedback effectively (because a lot of it likely falls into the "distraction" bucket haha). re: analytics, that's also something we're trying to figure out how to do well -- like you said, it's tricky if folks can just rip out that code if they want to, but we're hoping that we can set up analytics tools that are beneficial to both us (for product insights) and our customers (e.g. to make sure everything is working well for them, alerting them to updates, etc) Thanks again for your thoughts!