Effective, Simple, Durable
I changed my job a few months ago. I interviewed with a few companies on my way to find the right place for me. In several interviews I was asked: “Would you say your stakeholders were happy with your performance? Why?”
Were my stakeholders happy? I felt very appreciated by my stakeholders, I was told several times they liked my work, and they prefered if I took care of sensitive topics. They knew I will deliver good solutions.
My new stakeholders are also happy with my work.
But why? I didn’t really have the answer.
I started paying attention to how I plan features. What do I focus on? What do I emphasis? After sometime, I realised there are three principles leading, more often than not, to good features: Effectiveness, Simplicity, and Durability.
The feature actually does the job and your users know how to use it.
Every single time you are delivering a new feature there must be a goal to accomplish or a problem to solve. Are you actually solving the issue? Are you actually accomplishing the goal? Is this obvious? It is not.
Product Managers usually have several possible solutions for the same problem. Often, when you receive a feature request, you won’t get a problem to solve but a solution to an undescribed problem. Be sure to ask once and again until you find which problem you are actually solving.
E.g. Some of my stakeholders had to go through some folders and processing some documents. Eventually, I got the following request: “Can we see the dates and times when the folders where added to the queue?”
After several round of questions, I found out the actual problem: several people were processing these folders in different shifts, they needed to know which files and folders were already processed. Until that moment, someone will write down the date of the latest processed file on a post-it, and pass it on to the next worker.
Which solution we implemented? The dates were actually irrelevant to them. We gave them a simple way to mark the folders as ‘done’. That solved the issues.
Did you already find the actual problem? Did you solve it? That is great but we are not done here.
Do your users know how to use the new solution? Your solution can be technically perfect, smart, elegant and innovative. If your users don’t know how to uset it, your solution is useless.
Make it easy for them. Show, test, and explain it as many times as you need to. Refine along the process. If after explaining it a couple of times, they still don’t know how to use it, change your approach.
Be sure your users know how to use your solution.
The most obvious solution is, very often, the best solution.
Go for the simplest effective solution. Or, put differently, find the easiest way to solve the problem. Not the most optimised nor the most elegant nor the smartest solution. The simplest.
Why? Take it as an investment. It will be easier to maintain, to understand, to explain, and to implement. Opting for a more complicated solution will exponentially make things harder for you and your team, gaining only some marginal benefit in exchange.
You can always make it more complex later. Solve the problem first. Optimise later. It will help you understand the domain before increasing the complexity.
Simple also means small. Make it easy to deliver. Avoid, as much as you possibly can, to embark in long-lasting developments. Ship to production the smallest pieces you can. Refine from there. The longer it takes you to ship, the more likely something will go wrong.
Designed and engineered to last.
Durability is often overlooked in software companies, even more in startups. However, building durable software and durable features will make you fast in the mid and long-term. You will become slower and slower if you don’t build durable enough solutions.
Not taking durability seriously will bring you a lot of problems in the future:
- Technically durable: will the new feature be stable for some time or will you have to come back and do extra work soon? If your case is the second one, you are creating technical debt. Bad news, you are compromising your future speed for a slightly quicker delivery now.
- The problem will stay solved: does the quality of the solution degrades along the time? Will new features make your solution less effective? Watch out! You might be creating product debt. Bad news, you are compromising your future capacity to revisit already-solved problems.
Not building durable softare is like using a ‘credit card’. It might provide some benefits and pleasures in the short-term but, sooner or later, you will have to pay back.
There are many more factors contributing to the right delivery of a feature. Focusing on Effectiveness, Simplicity, and Durability, provides a good framework that will uncover other possible flaws.
To summarize, this checklist will be a good starting point to deliver better features. Be sure your solution is:
- Find and solve the actual problem.
- Ensure your users know how to use it.
- Find the simplest effective solution
- Ship small pieces often.
- Make your solution technically stable
- Make your solution sustainable and resistent to external changes
This is not the solution for everyone but it made wonders for me. It simplifies what I have to pay attention to and help me become a better Product Manager.
Did you find this article useful? If you did, please clap! Do you have any personal way of working? What is your main focus when you work on delivering new features?