4 ms·

We are(were) the exact same way, and I hate(d) it. Every customer is a whale and has demands, both on features and deadlines. Failing to meet these can result

We are(were) the exact same way, and I hate(d) it. Every customer is a whale and has demands, both on features and deadlines. Failing to meet these can result in losing the customer and the more customers we get the harder it is to balance/scale it all. Scale is personnel scale to handle each new challenges new clients bring. Somehow no matter what the is always a new client with some new demand we have never seen before. I don't see how your development is way faster, how do you handle multiple requests from multiple companies all different? Last year we started our self serve initiative and have slowly been growing there. Before we might have clung on anyway possible to keep the whale where now if they are too much of a hassle we can comfortably say "no" to something and not sweat their loss. With self serve, we are much more scalable. We don't need to hire more devs just because we have more companies. This is our product this is how you can integrate it and these are the customizations. We still take client requests, but we weigh them with other requests and if we deem them mutually beneficial to a majority it will get prioritized. We talk with our clients weekly and they have access to basecamp/jira/email to communicate individually, you can still get plenty of insights

caseymarquis 7y ago
I hate it sometimes too, and lose a lot of time to frequent interuptions. It still seems to work for us though. I think there may be some differences in our situation based on what you've said. We don't hunt whales. We actually avoid them (whales take a long time to pay you, and are very demanding). If one customer wants something from us which we don't think will benefit our customer base as a whole, we point them to our various APIs, or just tell them no. That said, usually they want things which benefit our whole customer base, and so we're happy to work with them to provide this. Customers almost always buy the software 'as-is'. While customers expect to be able to communicate their future needs to us, and expect our software to improve over time, very rarely does a sale hinge on developing a new feature. If it does, I am always consulted and will advise on whether we should agree to the sale (I'm consulted on unusual sales anyway). The reason we're not 'self-serve' is because we have a services department devoted to providing a complete solution for our customers. Either remotely, or while visiting their facility. Customers pay for this separately. We'll definitely need to hire more developers as we continue to grow, and I'm sure we'll face challenges scaling how we operate now, but I think the benefits are worth it. Regarding getting features out the door faster with a single person. This is because I know the problem domain inside and out, even though it's a moving target. I know the domain because I constantly communicate with our end users and services staff (I used to be our whole services staff; very happy to have gotten past that!). Oddly enough, the frustration of being interrupted is usually rewarded. I've had a lot of phone calls that started with me thinking 'I don't want to deal with this right now...', and ended with me thinking 'What a great idea for adding value to our product! I'm so glad I spoke with them directly!'. Typically the customer asks for something, and then we talk about why they want it, and we eventually (together) figure out an even better way to solve their real problem. Anyway, YMMV. It sounds like the bigger challenge you're seeing is clients demanding new features, and deciding there's not acceptable ROI without them. That's definitely a problem, but I don't think it's necessarily solved by not having a team that does implementations?

caseymarquis 7y ago

I hate it sometimes too, and lose a lot of time to frequent interuptions. It still seems to work for us though. I think there may be some differences in our situation based on what you've said. We don't hunt whales. We actually avoid them (whales take a long time to pay you, and are very demanding). If one customer wants something from us which we don't think will benefit our customer base as a whole, we point them to our various APIs, or just tell them no. That said, usually they want things which benefit our whole customer base, and so we're happy to work with them to provide this. Customers almost always buy the software 'as-is'. While customers expect to be able to communicate their future needs to us, and expect our software to improve over time, very rarely does a sale hinge on developing a new feature. If it does, I am always consulted and will advise on whether we should agree to the sale (I'm consulted on unusual sales anyway). The reason we're not 'self-serve' is because we have a services department devoted to providing a complete solution for our customers. Either remotely, or while visiting their facility. Customers pay for this separately. We'll definitely need to hire more developers as we continue to grow, and I'm sure we'll face challenges scaling how we operate now, but I think the benefits are worth it. Regarding getting features out the door faster with a single person. This is because I know the problem domain inside and out, even though it's a moving target. I know the domain because I constantly communicate with our end users and services staff (I used to be our whole services staff; very happy to have gotten past that!). Oddly enough, the frustration of being interrupted is usually rewarded. I've had a lot of phone calls that started with me thinking 'I don't want to deal with this right now...', and ended with me thinking 'What a great idea for adding value to our product! I'm so glad I spoke with them directly!'. Typically the customer asks for something, and then we talk about why they want it, and we eventually (together) figure out an even better way to solve their real problem. Anyway, YMMV. It sounds like the bigger challenge you're seeing is clients demanding new features, and deciding there's not acceptable ROI without them. That's definitely a problem, but I don't think it's necessarily solved by not having a team that does implementations?