4 ms·
It doesn’t have to be so hard, though. One thing you can do is learn to just say “no”. Such as no to cash on delivery. Being flexible is good, but it comes at
by sholladay 2y ago
It doesn’t have to be so hard, though. One thing you can do is learn to just say “no”. Such as no to cash on delivery.
Being flexible is good, but it comes at a cost. When that cost is too high, don’t do it. Realize that the customer who wants that workflow probably isn’t going to be your make-or-break moment. And in fact, they might have flexibility of their own. For example, you don’t accept Amex but they have a backup credit card or cash. It might be annoying to them if they are fussy, but it’s normal enough that the consequences are minimal. And yes, you may occasionally get a customer who doesn’t have that flexibility, but you shouldn’t be pinning your business on rare events. Figure out what’s most common among your target customers and support a few simple workflows. Say no to everything else until you have the resources to do it properly.
Another thing you can do is have a hybrid low tech/high tech solution. Automate structured inputs with software. Write down the rest as notes in a logbook. Over time you will probably see patterns in the logbook that you can automate.
Lastly, remember what Morpheus says in The Matrix, “Some [rules] can be bent. Others can be broken.” For example, you could simply pay the bill on behalf of the customer who wants cash on delivery. Now you assume some personal risk but the computer system doesn’t have to support their workflow. Is it worth it? Maybe, maybe not, but it’s a choice you can make.
- the_sleaze_ 2y agoThis is of course the right answer, reality is often easier to change than software when the goal is to keep reality and software in sync. So much harder to say no that it sounds though - sales is saying yes to everything they can, board is pressuring for more sales, the users are taking every possible opportunity to shift blame onto the software, and engineering is buckling under the churn of changing business goals every quarter.
- SoftTalker 2y agoDepends on the customer too though. Exceptions are always made for big/valuable customers, even if they are a PITA. If you have a long term big customer who has always been able to do COD and you suddenly pull that option with the explanation "it's easier for us" that's not going to go over well. Now you might lose them and they will tell their network "Wow, Foo Corp used to be good now they are just being unreasonable."
- akira2501 2y ago> When that cost is too high, don’t do it. Or just recognize that your software ideology is incorrect for the problem at hand. This guy wanted to write a single piece of software that did everything the business needed. That was clearly a mistake and no surprise that his software ended up very tightly coupled to the business itself. This was an error in interface and component design. Most likely caused by starting to write software before fully understanding the job roles and people who would be using it.
- abakker 2y agoI think it's OK to make that mistake because "starting" is a more positive force than "starting over" is a negative one. if the abstraction or assumptions were wrong, you already built some kind of lossy approximation that is highly useful. its just important to recognize when the prototype needs to be thrown away or retired. the corollary of this, though, is that "there's nothing more permanent than a temporary fix". so, balancing these ideals is the work of engineering and management.
- CPLX 2y agoI mean it depends. Everything depends. Are you selling to restaurants? To grocery stores in a large city's Chinatown? And so on.