One thing I have found particularly tricky in my work as a product owner is getting the right balance between the MVP (Minimum Viable Product) and the logically perfect solution.
While of course I would always like to build the perfect system it is usually not advisable to aim for perfection, but to aim for functionally sounds while technically simple instead. This is not just to save on time and resources but also to allow for the finer details and possibly exception to be fully worked through and solutions developed around them. Building the “perfect” more complex solution may turn out to have some underlying weaknesses I simply didn’t think of or have time to look into, because the technical complexity took up all of our time and focus.
In theory, this makes perfect sense, but in my head, I still resent the fact that I have to build something that is not the perfect solution.
Then again, I am beginning to think that the perfect solution is really just a myth anyway – if working in software development has taught me anything, it’s that there is no such thing as a one-fits-all solution that will be just perfect for everyone; for the user, for the development team, for the stakeholders and bank rollers. At least one of the parties will always be slightly disappointed.
And this is where striking the right balance is getting tricky. When I know that the user or the customer is hell bent on getting the perfect solution, when the development team is screaming that it simply cannot be done with the time and resources available and my boss is telling me that increasing the budget is not an option. What to do now? How do I steer all the stakeholders in the direction that I think will be the best option for all of them? It sometimes feels like i’m a diplomat in the UN trying to foster a peace, just to get the various parties to agree on where to start and where to finish – all the while realizing that what I thought was the best solution in the beginning, might not actually be the best approach. And admitting that I was wrong can be even more difficult than trying to convince others that I am right…
In the end though, I believe that simplicity is key. As a team, we have built the best solutions when we have tried to purely focus on the basics, go with the simplest, easiest and fastest to implement approach that only fixed the one main problem – not the other five that are somewhat related that I really wanted to fix because I believed it would really wow the users. Those simple solutions have been the ones that were easiest to train, adopted the fastest and ultimately made the most difference to our users’ experience.
As much I am a perfectionist and would love to built the most comprehensive and perfect solution, I keep learning to try to find the right balance and to accept that the perfect solution may be perfect, but may not be the best.