Not everything has to be perfect the first time
It’s strange, but it often happens to many senior people: the more you move towards your career, the more it’s hard to love imperfection.
Each new project starts with constraints: some of them are related to time-to-market bounds, some others instead came from the necessity to optimize and delay the necessary resources (mostly development time) while evaluating user feedback.
Constraints mean that we have to pick things that will get as much attention as we would ideally like. The results are removed features, less-than-ideal technical approaches, troubles for some teams, and so on.
Engineers and the idea of perfection
It’s hard not to want everything to be perfect, and it’s harder to convince people about what’s behind these constraints.
This is where I’ve often encountered great engineers, product managers, and designers getting lost.
But at this point, I must confess: I damn hate the MVP term. MVP is the acronym for “Minimum Viable Product”. Even with all the best intentions, it’s just a game of diminishing returns: “minimum” stands for “the least effort“; “viable” is another low bar meaning something isn’t often desirable.
Definitely, it’s far from being something someone can be excited or nevertheless proud of.
Communication is essential: words matter.
(Especially when you’re talking to a tech team)
MVP is often considered a slap in any tech people’s face; less than ideal, the symbol of “imperfection”.
Most engineers refuse the idea of imperfection.
The first message you should pass is to get the team comfortable with the uncertainty of software development.
Time delays, requirements, and goals changes; depending on the area, everyone can feel the volatility of the development process of a new feature on their skin.
Not everything has to be perfect the first time
Explaining the reasons behind choices is fundamental to align the product and tech team better. It’s not about high-fidelity mockups; it’s more about sharing measurable goals behind the idea.
Knowing what truly has to be perfect can help focus limited resources on the right spot.
Then: not everything has to be perfect the first time.
Communicating your goals with a detailed long-term roadmap is a typical error.
The far future is unknown, at best.
It will constantly change as you move forward: reduce the detail in your plans as they get farther ahead avoid overthinking.
As I said at the beginning of this post, it’s hard to love imperfection.
Most of the time, the response to “we can fix it later” is something in between melancholy and sad: “we probably won’t”.
Teams are asked to compromise daily; promises of “we’ll fix it later” sound really hollow if you, as manager, don’t create a structured workflow with enough space to fix and optimize things.
Conclusion
Developing any digital product is stressful for both product and tech teams. Both will experience the pain of removing features, changing priorities, and reducing/expanding time daily.
As a manager is critical to focus on better goal settings & communication: what’s important, what’s not, what’s the reason behind a choice.
As an engineer is essential to feel comfortable with the ever-present uncertainty of making digital products. Resources are limited: reduce the scope, be crafty, focused, and precise.
You will never get perfection in a constantly changing world, and no one needs them.