You don’t have to hang out in a product forum or Facebook Group for long to find someone asking a question that has an answer. Not just any answer – a really easy answer. How might one find this seemingly easy but clearly elusive answer?
Simple. Make a test.
This could be seen as broad, general advice, especially in the development world. All modern coding languages teach you to build a test first – “Hello World” is the successful first step of completing a test in a new language. While the no-code world has no such similarity, I’d argue that it should. And while we’re at it, why not make it the answer to your most basic question? Instead of “Hello World”, I’m talking “Here’s Your Answer”.
The no-code world is constrained because it uses products, instead of raw code, to build and connect things. And while you can get a long way with these sorts of solutions, there’s always a moment where you question the capability of a system or two systems, to interact in a certain way. The question you’re really asking is “does capability x exist in this system or between these two systems?”
A great example of this is in native integrations between two platforms – if you ‘read the outside of the box’ it might tell you that ‘invoices are automatically sync’ed’ but if you’ve had your heart broken a few times by these sorts of integrations, you might ask ‘what kinds of invoice information are actually sync’ed?’ ‘Do quantity, item description, individual line-item prices come in as well?’
While it may seem natural to head to the nearest forum and ask this question, I’d argue that the faster way to understand the answer is to integrate the two products and transfer over some data. Difficult? Possibly. Worth it? Totally.
Let’s say you post this question and someone answers you. You know the kind of folks who like to help, but not too much. “Yes.” is the answer to your question. Okay, that’s helpful, but not too helpful, right?
We could still argue – how is the data supplied? Can I use it in certain ways? What does it look like? In other words, you have a conceptual answer – this is possible – but you’re still lacking a lot of information.
Testing is the fastest way to learn a lot about products. When you’re testing, you’re creating your own information. You’re developing a sense of how a product behaves, what’s possible, what’s not possible, and when the time comes, the exact steps you’ll need to take to achieve a certain goal. Testing is so good, sometimes it feels like you’re cheating on the question “can I do this” with a particular product.
You might protest – rightly so – that you don’t know how to do something. Here, I would argue more strongly that testing is your friend. Want to learn all the functions of a Swiss Army Knife? Pull it out of your pocket and go through the options. Of course, you’ll be slow and uncertain at the beginning, but assuming you own or are going to own or even worse, need to work on a system for a client, why on earth wouldn’t you want to be as fluent as possible? Frustration, delay, and uncertainty are hallmarks of unexplored territory, learning opportunities, and personal development. You should seek these feeling out – bask in them and let them ‘learn’ you.
What you’ll receive in return might surprise you. Watching someone perform a task with skill testifies to the sheer number of repetitions they’ve logged. Want to be that lady? Stop asking easy questions and start testing your assumptions personally. Before you know it, you’ll be the smart-ass answering “Yes” to the easy questions AND when the time comes to perform the task for real, the knowledge you’ve gained in testing will prevent you from having to mutter under your breath as you search through the Settings “but they said this would work on the forum.” Nobody wants (you to) be that guy!
Photo by Emily Morter on Unsplash
