The many benefits of learning about product design principles
Listen to the audio version!
I’ve been learning a little bit of product design in my career as a software engineer, like the role and importance of the Product Owner.
There’s a stereotype where programmers don’t care very much about the value of the product. They care about building things. They get the problem they are supposed to solve and then come up with a solution for it.
As a software engineer, you need a Product Owner as somebody that can listen to your right questions in order for you to come up with the better out of the many existing answers
One of the core tasks of a Product Owner is prioritization. If you start learning the basics about product design it can also help your career as a software engineer. It will empower you to improve your engineering work and your personal life.
Pareto tells us there's a high chance 80% of the effects come from 20% of the causes. Experienced Product Owners know this and apply it naturally. They tend to prioritize stories that yield most value to the end user (the 20%).
As a software engineer, you make daily decisions about the tradeoffs of code improvement (like paying Technical Debt) versus feature delivery. While the improvements do not impact the user directly, they can impact the software development process.
The same way 20% of the features can yield 80% of the value to the user, 20% of the improvements can yield 80% of the value to the software development process.
Let’s say there’s a part of the system that is old and constantly being touched by the developers. Every time someone works on it, it takes a long time to finish whatever they need to do at that moment. Besides, it ends up creating more bugs than when they touch other parts of the system.
The problem can keep happening if nothing is done. If the cost of fixing that part of the system is lower than the potential problems it can cause in the future, then improving it can be inside the 20% spectrum that yields 80% of the benefits to the system. In that case, it might be worth prioritizing that improvement over others which are not that critical to the software development process.
A good practical example of this is the use of entity based objects to model one of the core purposes of the business, like a “User” object for an authenticated user, or a "Transaction" object for the transaction of a banking system. Entity based objects built like that tend to grow a lot over time because of their many purposes, ending up to become a God Class. Improving them even a little can be hard. But they can also have a good Return On Investment (ROI).
If the cost of fixing a certain part of the system is lower than the potential problems it can cause in the future, then it can have a good ROI
Prioritizing Technical Debt is very similar to prioritizing projects of a company. And also projects of your own life.
You can have the goal to change to a better job in say 6 months, just like a public company has the goal to increase in value until the next financial year.
For your personal goal, you can have a backlog as if it's a standalone project.
For that backlog, you prioritize using different variables that are context sensitive. For example, if changing jobs, you can prioritize up:
- If some interview you have scheduled is in a closer date, that bumps in priority because you don't want to miss it.
- If a recruiter answered you with a code challenge and you haven't responded for a while, the more you keep somebody waiting the less likely it is for them to get back to you later.
This exercise of prioritization will allow you to find the 20% of the actions with the potential to yield 80% of the result you want.
You are the product owner of your life
Managing product is also a fundamental skill.
You don't need to be a product designer to understand the benefits these skills can have in your life or your career.
They can be applied anywhere.
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.