Doing the impossible: Using your product to do what the product can’t do

Full disclosure, I work for FileWave as the Vice President of Product, and we have a great solution, but that isn’t the capacity in which I come to you today.

For most of my lengthy career, which makes me experienced (and not at all old!), I have been the one using the products, not building or selling them. That is how I come to you today. With my humble opinion as the user of products, and the manager of engineers.

Throughout my career, wherever I have been, and in whatever capacity, I have worked with people I think of as “product jumpers”.  These are people who, at the merest hint of a problem, or seeing some shiny new bell or whistle, will throw away their entire investment in a current product to chase a new one.  All with the promise of “better”, and usually with no consideration of what might be lost along the way.  Then within two years, they’re switching to another new product that is again, “better”.

I’ll tell you what my experience says: this is almost always a mistake. Or at minimum, should be considered a lot more seriously than it usually is.  Change in product suite takes time, it takes money, it is disruptive to the team and the environment, and it usually isn’t at all necessary.

Let me tell you a story. When I was about 16, my Dad, who wasn’t necessarily a wise man, said something wise to me.  You see, he had been taking me to learn to play golf.  He gave me a hand-me-down set of golf clubs to use.  They were proper old, and not in a vintage, “cool” way.  Nope, these were just old, in a bag with a big hole in the side.  I’d put the clubs away and the shafts would stick through the holes.  Totally embarrassing.  So, I said to my Dad, in my 16-year-old wisdom after a particularly bad shot: “I need a new set of clubs.”  To which he wisely replied: “No, you need to learn to play with the ones you have, and then a new set makes sense.”

That is what I see time and again with people and their technology toolsets.  I see teams say “we need a new tool”, when often they just need to say “let’s learn to play with the one we have”.  But, I am not talking about just dealing with product shortcomings, and getting over it, not at all.  What I am saying is, there’s usually a way of getting more value out of a product than you are currently getting, just by thinking creatively.  Only when you have exhausted all value in a current tool does it make sense to “upgrade” to a better one.

To this last point, thinking creatively, is especially what I see lacking in new engineers, and new managers.  Yes, I am old school, but there isn’t always a button that says “do it” that you press and magically everything is done for you.  In the MDM space in particular, this is what I see as a shortcoming. If the MDM framework doesn’t support it, then you basically can’t do it. GPS is the same thing. What do you do if GPS doesn’t have that particular road listed?  Maybe you need to look at a map!

Thinking creatively with a current product can often turn a “no” into a “yes, if”.  Not only does this provide your organization with increased value in your current investment, but it also makes stronger engineers, which is really where you get the value.  Really strong engineers can definitely outgrow a product, but it behooves you to make sure this is the (actual/real) reason the suggestion is being made to move products, and not just because the team sees something shiny and new.

Let me give an example from my own product, and a theoretical (but practical) application.  Let’s say my team and I manage an environment of 10,000 devices, split pretty equally between macOS, iPadOS, and Windows. Today, one of my engineers tells me we have a problem. The service for our malware protection suite is randomly stopping on some Windows devices, and we need to fix this lest our environment go unprotected (and you just know it’d be the CEO’s device impacted).

Now, does FileWave have a button to push that says “fix this”?  Nope, we don’t.  That’s the end of the story, right? Time to get a new product.

Not so fast.

A logical breakdown of the problem is required, which has little to do with product, but it does require engineering and an understanding of the operating systems being managed. Often, this is an excellent opportunity for growth for the engineer and the team. If we therefore approach this problem logically:

1. We know we have reports of the Windows service not running in some instances.  Hopefully my engineer understands that Windows Services exist, and every service has a current status of Running, Stopped, Stopping (or perhaps even not being there at all).
2. So, the logical question becomes, can we identify which devices are impacted currently? The answer is, no we cannot, because FileWave does not collect services info and state from managed devices. Although that is on the roadmap the VP of Product tells me 😉
3. That the above answer is “no” doesn’t stop us from being able to accomplish this anyway. FileWave does have the ability to collect custom-field based inventory data from Windows (and macOS) devices in the field via script.
4. All we really need is a script that can read the status of the service for us so that we can get the information (which is of course key). Do we have a script for that? No. Case over, right? Again, not so fast.
5. We do have computers, and browsers, and search engines, and we can search for “Windows service status powershell script” and the second result we get is this excellent article: https://theitbros.com/get-service-powershell/
6. That article tells us exactly how to list services, how to get service status, and how to take action on said services, all via Powershell.  We are getting somewhere!
7. Now we have all of the building blocks we actually need:

• Our devices have a client on them that allows us to manage them (FileWave)
• FileWave has the ability to execute Powershell scripts on Windows devices to take actions on services and to report on their status
• We know it’s possible to have a Powershell script do what we want, so now we just need that script

8. Do we have to write the script? We could (and we probably should), but what if you don’t really know Powershell and you are that new engineer on the team? Yes, you could write it, and getting thrown into the deep end of the pool like that is a great way to learn. But, we could also just cheat:

a. AI, please show me how to write the script I want:

1. So now, we have everything we need. 
2. Of course, we need to build it, and we test it, and we test it again
3. And we, finally, apply it in the environment.  Problem solved.

Now, did all of that take some time?  It did.  Maybe an hour or two if we include proper testing, but we just turned a “no” into a “yes”, and we didn’t need a new product, and the organization walks away with:

1. A more knowledgeable/experienced engineer with more tricks up their sleeve
2. A building block for re-use for other services within our current management product
3. A better cost to value ratio out of the product we already own
4. An efficient solution to an immediate technical need
5. And a problem solved, without sacrificing the other good things our current product already does

So, is FileWave great?  In my opinion, yes it is.  But that is not at all the point. We could easily be talking about ANY product here, even FileWave competitors. 

The question is, are you and your team getting the very most out of the products you have on hand?  If you don’t know the answer to this question, then your solution isn’t a “new product”, it’s “learn to use the one you have better”.  If you don’t know how to do that, reach out to your current vendor, and they’ll be happy to help.  I can speak universally for all who build products for a living that we WANT you to squeeze every single last drop of value out of the product you have today! 

Really push those boundaries! Make us better, and yourselves as well!