Figure it out before moving to a tool
Almost consistently in every company I’ve worked in, the organisation sees some challenge. The first suggestion is almost always to start looking at existing tools on the market that do X to do decide which one might solve the problem best.
In some cases, someone remembers to first collect requirements so that you both analyse the tools properly and can more easily compare them.
The problem is that we are depending too much on a tool to solve the problem for us, rather than finding the right solution for the problem.
This generally presents us with three mains issues:
- Teams are forced to adapt to the tool — Any new tool we implement in the organisation will ultimately have a learning curve for everyone, but more than that, there are steps in our processes that need to change to adapt to the new tool.
In some cases, we may even need to adapt our way of thinking or our entire process, all based on the assumption that the tool knows best. - Not really identifying/solving the fundamental problem — We have a new tool and a new approach to doing X and all seems incredible, but in if we never actually identified the fundamental problem, in most cases, that problem will come back to bite us in the butt. Although potentially in a new way.
- Potentially choosing the wrong tool — Here’s the thing, often when we define our needs for a tool, those needs are based on our current understanding of our needs. As the organisation and our products grow, our needs will change. If we’ve chosen the wrong tool for the future, we may need to go through the entire process again and this time with an even more complex migration.
The whole concept of adopting a new tool takes a lot of effort and creates discomfort, uncertainty and in the case where it goes wrong, mistrust. So you better get it right.
In recent years, through trial and error and making all the mistakes I mentioned above, I started approaching the tooling problem in a way that gives me, and the teams I work with, more confidence.
Start with the framework
I learnt this specific piece of advice while attempting to build a Research Repository back in 2018 (Read more about here), but the trick is about getting the underlying framework right before moving to a tool.
“But can’t/shouldn’t the tool help me figure out the rest?”
The only time that letting a tool define your processes and frameworks is when you’re starting with absolutely nothing and even then, it doesn’t guarantee success, because that tool will force you to work how they see things or based on industry best practices.
“Isn’t that what we should striving for? Following best practices?”
Yes and no. Following best practices is fine if your product organisation has evolved in that direction, but often your organisation isn’t at the right maturity or hasn’t developed the correct habits.
You first need to figure out what makes sense for the team and organisation for optimal results and taking into consideration the context of your industry and company.
At first? Hack it
That’s why I personally prefer to approach the challenge in a “hacky” way at first. Using spreadsheets, google docs etc. to just get a baseline of what I think should be the approach.
Yes, the team will potentially have to do more work, but ultimately they can test something out and change it if it doesn’t work. It’s not hard do edit, change or drop a spreadsheet, because the effort to put it together is easy.
Be sure to keep revisiting until you realise that you have parts of that process well enough defined that you should start looking at competitors.
It’s also an incredible way to define your specification needs for any tool, because it’s based on reality and not assumptions.
Adopting a tool at this stage will be much easier, but you can also get a clear notion of whether adopting a new tool will improve the process or whether the “hack” is after all good enough that existing tools won’t have enough of an impact to justify the investment.
Final Thoughts
I know it’s tempting to adopt a new tool to solve our problems, but often they will just add more problems and could be a blocker if done incorrectly.
Before adopting a tool, do the due diligence. Make sure you need a tool. Make sure it solves the problem effectively.
No tool has the full context of your reality and so they might not even know about your particular case. By going through the process of defining your frameworks, you also scale and experiment as needed. In some cases, you may even find alternative solutions with tools no one ever considered for your use case.
Figure things out before moving to a tool!
This Newsletter is a passion project and I will always keep the content free for my readers.
If you find it useful and would like to support the content, please donate
Originally published at https://hugofroes.substack.com.
