top of page

5 tech tools you need to be good at as a non-technical product manager

Updated: Nov 25

You can learn these product management tools on the job, but it's the 'why' mindset that will determine how well you can leverage them and become a badass product manager


A sharp knife doesn't make a great chef, but it sure turns cooking into an absolute delight.


As a product manager, having the right tools at your disposal will determine whether you operate blind as a bat or brilliant as Einstein. For non-technical product managers, just because you cannot code doesn't mean you cannot leverage technical tools that help you develop and share new insights with devs, designers and leadership.


Good news is, it is not rocket science and you do not need to be the world's no 1 expert at these. All you need to do is know what they do, why you need them and how to use them to achieve your specific goals.


Let's jump right in:


Tech tool #1 - Wireframing, Prototyping and Design tools.


This could be Figma, Balsamic or Mockflow.


It could also be a blank sheet of paper where you can map out screen flows, draw out content architecture and essentially take yourself through the journey your end user would follow if you developed the feature or product.


Knowing how to put your ideas to paper helps you communicate your ideas to the engineers and even designers. Having your designs or ideas look pretty is a nice-to-have; not completely essential. But it will give you the opportunity to think and communicate like the powerful product manager you are. A good communicator is a good leader.




Tech tool #2- Roadmapping tools



Even good, old Excel could work here.


Roadmapping helps you visualise the journey your product will take from Point A to Point B. This usually includes new features introduced, new markets you'll enter into and sometimes even what you'll be discontinuing because of a changing business or regulatory landscape.


Roadmaps are more of a communication tool than a strategy tool. They help you tell different stakeholders what to anticipate over the coming months. Ideally, roadmaps shouldn't stretch more than 4 quarters or they risk becoming redundant and less agile.

As a product manager, you'll usually create different roadmaps for different stakeholders. For instance, what investors and the management is keen to see is different from what developers want to know. Again, roadmaps are communication tools.




Tech tool #3- Analytics tools


These could be Google Analytics, Mixpanel or Hotjar.

An image showing a sample analytics interface on a mobile phone.

As a product manager, one of your key tasks will be to determine how your product is performing based on the goals you set for it. You cannot improve what you cannot measure. And knowing what to measure is 70% of the battle.


The metrics you set that would be the key growth indicators would inform what you will measure and the analytics tools you will use. Some analytics tools (such as Hotjar) only work on websites but not mobile apps. Others provide an overview of traffic sources but don't go granular.


Once you decide what metrics you are optimising for, you will then choose what tool can help you measure movement. Acquainting yourself with how to read the data is expected, the ability to draw insights from that data is good, but a real MVP Product manager knows how to perform A/B tests, question the data and adjust strategy based on the insights gained from the data.


It sounds heavy now if these terms are new to you, but the more you expose yourself to these tools and processes the more your muscles grow as a result.




Tech tool #4- Agile Project/Product Management Collaboration tools


These could be Asana, JIRA or Trello


Collaboration tools give visibility to what everyone in the team is doing which helps avoid duplication of tasks and allow you to track progress on specific outputs. Most give you the option of prioritising tasks in terms of urgency while visualising dependencies. By default, a lot of tech tools have a collaborative aspect, but these specific ones are made to empower teams to work together.


Most times, you will find that your needs as the product team evolve as your product evolves. This could mean that you could start off with the simple free version of Trello and then graduate to JIRA's premium version as your needs become more complex and all encompassing.


You will also realise that some of these tools play well with others; like Trello and JIRA are made by the same company and have adjacent use-cases (depending on what you need) so you will likely use them together. A lot of them also allow for cross-integration that enables you to embed one tool onto another so you can have all your items in one overarching tidy place.


Sometimes, you will be required to onboard onto the tool all other teams in the company are using, alongside the tools your product team uses. Again, none of these require a specialised degree to learn, but knowing their capacities and their use-cases allow you to empower your team to leverage them in ways that unlock your potential to communicate, prioritise and collaborate.



Tech tool #5 - Content repository



One thing you're guaranteed of doing a lot of as a product manager is writing, reviewing writing or editing writing. Think of documentation as the kidney of the product. When it's healthy, it filters out the junk and keeps the good stuff in. Because it's easy to take for granted, you will not notice when there's a problem until your oedematous product is full of unnecessary features no one wants.


A phenomenal product manager keeps their product documentation in order. It's easy for whichever stakeholder to trace what they're looking for, the information is easy to read and up to date, and the language is reflective of the audience the writing was intended for.


Tools that help you house your documentation ideally allow you to easily link pages, create sub-pages, add files of different formats and share the repository with different relevant folks. Again, different organisations will use different tools depending on the pre-existing or evolving needs.


If you'd like to learn how to create your repository as a new PM, you can read about it here.



It's not the 'what', it's the 'why' that matters


As a new PM, you may not always have a choice on what tools will be used in your role; that's okay. However, it's on you to figure out why the tool is being used and if you encounter limitations that exist with the current tool stack, you'll have to present a case as to 'why' a different tool will be a better fit.


But first, learn your tools.

bottom of page