How do you troubleshoot new tech before supporting it?

When given the opportunity, the first thing I do with any new bit of tech, be it hardware or software, is give it a hands-on once over. See what I can reason out without any guidance or instruction. This gives me a baseline on where end-user questions may originate, as it lets me see it through their eyes. Next is the classic, RTFM. I read the manuals and instructions that are supplied (or, failing that, find them myself online). I also do a search using key information, such as developer name, company, etc and see what sort of results come up.

Careful study of the macro features (assuming this isn't software) can often lead to a fundamental understanding of the design. All new tech is based on old technology or old concepts at the least, so it takes a bit of reorientation if something is truly novel. I love finding the patents (if they exist) as this will really dive into the foundational technical details and at least provide breadcrumbs for more researching. But, as other mentioned, there must be an "expert" somewhere and learning from them is almost always the most efficient.

Gathering information from diverse sources like product documentation, user feedback, and industry publications forms a solid foundation. Consulting with experienced colleagues, managers, or mentors is also invaluable. I'd like to add that actively cooperating with the R&D department can offer significant insights. Engaging in beta testing or participating in the product development stage allows for a deeper understanding of the technology before it hits the market. This proactive involvement not only enhances troubleshooting skills but also keeps us ahead in the tech curve.

A sandbox environment is a fantastic way to test new tech; unfortunately, the simple reality in many organizations is that IT is an afterthought, especially in the budget process, and so a test environment, if available at all, is unlikely to have the same systems and processes running within it, which can make a true trial difficult. Software that runs fine in a silo can have all sorts of complications when put into a shared and/or distributed environment. This is why having at least some sort of properly scaled test/demo environment is so critical.

I'd like to emphasize the value of conducting your own tests on devices, solutions, and products. Personal testing not only deepens our understanding of the product but also uncovers potential problems that users might face in real-world scenarios. It's important to remember that while documentation is helpful, it often covers only the most common issues. Our own explorations can reveal much more, offering us a comprehensive view and preparing us for a wider range of challenges.

Ideally, you should already know something about the items you're troubleshooting. Some people may balk at that, but think about how much you know about door handles. If you saw a door handle with a completely different design, how would you open it? If you're like me, you'd try to twist the handle to see if it gives any relief. No? OK, next step. Pull/push the handle and see if the door gives any indication of budging. No? OK, next step- in perpetuity. You already know something about the item you're troubleshooting, start there and then expand outward. If you truly have no idea what you're working with, it's best to defer to a senior or a team lead who can provide some insight. And, if they don't know, reevaluate supporting it.

In my experience, the best way to share your insights is to share from the perspective of the consuming party. If you want to provide troubleshooting info to an end-user, remove all the behind-the-scenes content and get straight to the heart of it. In most cases, a simple format of "When you encounter ________, do _______." works wonders.

Don’t be afraid to walk away. The new tech may not be a fit for what you need, and there’s no reason to bring online live what hasn’t worked for you in testing. You’ve already spent the time vetting it, and if it doesn’t work, don’t feel like you have to embrace it. Just because it’s a new technology doesn’t mean it’s the right fit for your organization.

As Brian Mithen said - don't be afraid to come to the conclusion that a new bit of tech may *not* be the answer; even well established companies, such as Microsoft, may not have integrated features into their platform that are essential for the business at hand. It is also worth talking to smaller vendors, as they are often far more willing, and able, to implement enhancement requests to add functionality, versus a mega-corporation that may not even entertain the idea at all.

User experience. Being the end user of the new tech is by far the best way of knowing inside out what you're supplying and can help in many ways your customers. It helps you share valuable tips, knowledge, and how-to. I believe it adds great value to your service, your customers, as well as letting shine the new tech!

All the processes and procedures will count for squat if a wild manager/C-Level uses their position of power to shoehorn in untested tech into your environment. They need to be trained as well to follow protocol, and not the rave reviews of their golf buddy.