Why You Need To Code
While coding a small software to help in my team’s work, I learned important lessons as a Product Manager
While coding a small software to help in my team’s work, I learned important lessons as a Product Manager
Key Takeaways
Products we use are mostly meant to automate and simplify the jobs we need to do.
Low-code tools give power, but building your own software is more powerful.
While working on a side-project I developed, I learned great lessons that helped me become a better Product Manager.
The Power Of Automation
Throughout our life, we have many tedious tasks. Some of them are recurring (even multiple times a day), and others just occur from time to time. these kinds of tasks consume time and effort and prevent us from reaching our creative zone.
As a result of this pain, many frameworks came up trying to tackle it. My favorite is Alan Klement’s Jobs-To-Be-Done. In short, JTBD (Job-To-Be-Done) is the struggle of trying and make our life better without the proper tool.
Enter automation. Automation brings up the power to reduce time spent on low-effort tasks and thus gain more time (which is by far the most expensive resource these days). Gartner claimed hyper-automation as the 7th trend for 2022 to act as a force multiplier of businesses and innovations.
Each of us experiences automation in various areas. Scheduling messages, building workflows, and integrating different apps together — all are an example of automation. It also comes with a hardware product, such as iRobot, that can be scheduled to clean my house without me worrying about it again (assuming it didn’t get stuck…)
No-Code Tools
No-code tools give the power to create automation for business people with a minimum understanding of technology. A simple example I can think of is building a vacation request workflow in a tool like Zapier or Microsoft Flow that simplify the communication around it.
As a Product Manager, using a no-code tool gives a lot of power as many tasks (JTBD) could be achieved without burdening your developers. For example, reaching out to customers with a survey to fill can be done in 5 minutes with a tool like Intercom.
Following that, there are entire products that were built with a no-code (or low-code). One example is My Story Club, a writing app for kids written in Bubble and without any line of code. It can be super helpful to validate ideas in an early-stage startup.
4 Lessons I’ve Learned From Coding
Other than no-code tools, I see a lot of value for product managers to at least try coding. Some come from an engineering background, while others didn’t experience it first-hand. To support my claim, I want to share my lessons.
A few years ago I worked in a product team where we managed our projects in TFS. We had a lot of manual work around it as it offered minimum automation and awkward flows. For that reason, I’ve learned Python and built a command-line-based program to help my team overcome our struggles. Here is what I learned in the process.
Empty Canvas Get Your Creative Juices Flowing
Each coding project starts with an empty canvas, literally. It’s like reaching a junction with hundreds of possibilities, where there is more than one correct road.
This state could paralyze you, but it also kicks your creativity. Learning online, drawing on a board, trying out and failing, asking for help — all are great options to start with.
While in some cases you might work on an existing code, there are still endless ways to solve the problem and I see each task as a new empty canvas.
Start With Something, Iterate To Improve
Agile is a well-known agenda, especially for Product Managers. Nevertheless, you have to be agile when writing code. The feeling of coding for three hours and finding out you got the base wrong is frustrating. Quickly enough you find ways to always validate your learning and make sure you’re on the right direction.
To demonstrate this point, until I got the confidence I tested my program every few minutes. I ran unit tests and acceptance tests before and after each commit. My goal was to get it to work, not to be perfect. Once I got the core of the program to work, I got some feedback and iterated to improve it.
However, in published software used by customers, the standards are high. Yet, you never start from the end. First, you reduce the feasibility risk and make sure you can address the problem. Only then you can iterate to improve the results.
Use The Power Of The Community
You might have heard of the almighty tool for developers — Stack Overflow. In other words, the community. Almost any problem you will try to solve, or error you might get from the console, was experienced by someone else.
The Dev community is resourceful, open, sharing, and everyone can benefit from it. When friends of mine heard I know about Stack Overflow and found some answers there, they said with a laugh “you’re already 50% developer.”
Going back to my original program, after less than an hour of research I found an open-source library that handles the API communication with TFS. It probably cost me 35% of the development time and the overhead of building the API calls. I couldn’t do it without the community.
Coding Is Just Part Of The Picture
Developing software is not just about code. Actually, it is mostly not about it. Some studies suggest less than 30% of the developer’s time is invested in coding. The other, not taking meetings into account, revolves around maintenance, testing, security, deployment, monitoring, researching, optimizing, and more.
Once I got my program to work, I wanted to share it with my colleagues. To do that, I needed to find a way for them to authenticate themselves without exposing their passwords. I also needed to build an executable file that doesn’t need access to my codebase. These are only two small problems I had that weren’t around coding at all.
So Why Should You Code?
As a Product Manager, my project of building a small software thought me a few important lessons. For a few days, I got to wear the developer’s shoes and it helped me become better at what I do.
The power you feel when you build something out of an empty canvas, improve it, enjoy the discovery of a community, and deal with some complex problems — cannot be explained and made me appreciate my team even more.
I strongly suggest this experience to everyone, and if you don’t know where to start — you just found yourself with an empty canvas.