Here’s a question I get all the time.
“Should I get (some popular plugin)?”
There are times when the answer is easy, but much of the time the answer isn’t clear-cut because it depends on the person’s business goals, their process, and a bunch of other factors I can’t know without talking to them extensively.
Here’s how I think through those questions, in consultation with the customer.
The One Main Thing
Software creates ease by applying constraints.
If you learn nothing else from this blog post, that’s your takeaway. Software creates ease by applying constraints. And this is true for everything from a WordPress plugin to Gmail to Microsoft Word to multi-million dollar government computing systems.
But what is “ease” and what is “constraint” in this case?
“Ease” seems almost self-defining, but I like to think of it in a very specific way. “Ease”, to me, implies the simplification of targeted tasks.
WordPress is a great example. To design a website fifteen years ago, I’d have to make a new HTML file for each page, manually add that page to a menu “include block”, code all the layout by hand, format all the content by hand, and then upload the page to a server.
Now, I login to WordPress, click “new page”, type whatever I want, and click “Publish”.
That’s “ease”, in my definition.
“Constraint” can apply to dozens of different aspects of a project, but the way I’m thinking of here is “reduced flexibility”.
Again, WordPress is a fantastic example.
If I want to change the width of my sidebar column on a single page, that’s very easy to do if I’m manually coding HTML for each page. I just toss in a line of code, and it’s done.
But if you’re using WordPress, that code is all hiding in a template file somewhere. And changing that sidebar width is going to change the sidebar width on your whole website, not just the one page.
Sure, you can make a second template with a different sidebar width, but the logic to switch templates, the coding of the second template, and all the attendant details are more complicated than if you knew HTML and were just coding pages by hand.
It’s A Trade-Off
That’s not a bad constraint, per se, but it is definitely a constraint.
An Example Of A Bad Constraint
I used to work for a company that bought some point-of-sale software. For reasons completely inscrutable to me, if their part number was numeric (no letters, symbols, hyphens, etc.) it could be 26 characters long. But if there were any letters, symbols, or hyphens in it, their part number could only be 12 characters long.
Since they were using a distributor’s part numbers for most of their inventory, this meant that they might have a part number of 69886XJC-92412. Which is two characters too long for their software.
In trying to create ease of managing inventory, tracking sales, operating their cash register, etc., they accepted a constraint on the part number that meant they had to completely re-work the way they number their inventory.
That’s a pretty serious negative constraint. We’re talking about hours, and possibly days, of coming up with a new inventory system – and the new system wasn’t nearly as easy as the old one.
This might still be worth the trade-off in the long term, but here’s the key – they didn’t discover this until they’d plunked down thousands and thousands of dollars for the software. If something this simple wasn’t discovered ahead of time, the odds are good there are other things coming down the road that they’re not prepared for either.
And that’s bad.
Why Does This Matter?
When you’re looking to use a piece of software, you’re usually trying to solve a particular problem. That problem might be very complex (“how do I sell products online and keep inventory up-to-date on my computer at the office?) or very simple (“how do I show a random testimonial in my blog’s sidebar?”), but one thing is always true:
Software creates ease by applying constraints.
The trick is to figure out whether the constraints are reasonable for your workflow, and whether the ease created overshadows the constraints.
If you’re using an online scheduling system, for example, it might let you book twenty clients a week and integrate with your desktop calendaring software. That’s definitely “ease”.
The constraints are harder to see sometimes. Let’s say that your workflow is to get a client contact, send a questionnaire, get it back, and then you need a week to review it. There is no problem whatsoever doing this all via email, as email is almost infinitely flexible.
When you transition to the online system, there are a number of things you might find. The online system may not know how to send the questionnaire. So you still have to do that manually. It probably doesn’t have a way to track the submitting of the questionnaire, and it probably doesn’t have internal logic to delay them a week beyond that.
So now your workflow has to change to accommodate the system.
I’ve seen people that will react to that sort of thing by waking up in the morning and filling up their schedules in the online system so people can’t book less than a week out. Or contacting clients to ask them to reschedule using the online form. Or other similar (but still bizarre) things – all in service of the online scheduling system.
At that point, if you only have three client contacts a week, the additional workload created by the constraints are probably drowning out the ease.
That doesn’t mean you can’t simplify your process, and it doesn’t mean that the online calendaring software might not be perfect for somebody else – it just means that it’s not good for your particular situation.
But What About Cost?
You’ll note that I haven’t discussed cost yet. That’s intentional. First and foremost, software selection should be primarily driven by whether or not it helps you solve your stated business goals. It doesn’t matter how cheap the software is if it doesn’t solve your problems.
Knowing that a $1,000 software package will solve your problems, and that a $100 software package won’t, will save you the hassle of wasting $100 on software that’s not going to work. On the other hand, sometimes you get pleasantly surprised and discover that a $40 software package may solve your problem in a better way than a $5,000 system.
Understanding the problem, and understanding how to solve it, is the key – not the cost of the software.
Software, as a whole, is great. The right software makes our lives easier and more efficient. But the wrong software can make our lives harder and more cumbersome.
Before investing in software to solve a problem, try to consider the “big picture”. What are you trying to do? How, ideally, would that look? Does this software actually move you in the direction of those goals? Does it do so in a way that complements your existing process flow?
Asking a lot of questions in the beginning is a really good way to not wind up with a software-powered nightmare a year down the road.
And if you’re stuck, I have good news. Ironing out processes is something I do rather well. And it’s something I help clients do. So if you’re in a scenario where you need to figure out how to get from Point A to Point B without going crazy in the process, drop me a line – I’d love to talk to you!