Product visions: From an engineering perspective
An opinionated letter to product engineering
This blog post is quite different from everything I have ever published, this is an open letter for all the developers and all the people in Product, that are building consumer-facing features, including non-only UI experiences, but also the ones that are creating APIs, security, and Architectural layers. This is gonna be a couple of opinionated comments and visions of how we should address some ideas, feedback, and mostly dilemmas around our profession.
I have been a mobile engineer for many years, around my time as a professional I had the pleasure to grow in many different positions, from platform, architecture, and product — all these different areas, are involved with the users, some have a closer interaction than the others and today I’m gonna tell you a story about some lessons that were learned in a hard way over multiple years.
The feature is not only a problem to solve
I used to think of features as a problem we need to address, we made rationals about architecture, task, and actions to tackle, we go over ideas from using X over Y and how long it would us to build that new functionality, everything ends up revolving around Jira tickets and sprints.
In my first years I learned that asking “why” was as important as asking “how”, ‘cause engineering is about being resourceful to our counterparts in different areas, we need to create a retroactive chain of creativity with multiple stages that makes us aware of solutions, proposals, and process; that’s why I believe that a good product engineer should be strongly tied to the proposals from UX/UI, research, and growth.
As engineers sometimes we ended up thinking that we don’t need to be involved in this chain at all, hiding us behind the excuse that if we are not experts other than our areas, we should stay behind — A couple of months ago one developer told me that he was not involved in this kind of process and prefers to non-being a point of intervention, he believes that having this kind of affairs were tiresome and must of the times boring — Probably many engineers think of Product or Growth areas in the same way, but the factual reason of thinking this way is that we don’t have a culture revolving around the product (which is one of hardest to cultivate); whatsoever zero-intervention will create mediocre developers, but also mediocre products. One may wonder, why? the answer is quite simple, imagine this a chessboard knowing where all the pieces are placed give you the capacity of planning your next step, so having the understanding of decisions give you improvements on future areas of your codebase and operations, maintainability, and opportunities for growth, you became a player and not an observer.
Asking the correct questions
Creating a good relationship of Product with Tech is a maze, but everybody can solve it even when is not for everyone; a good starting point is asking the correct questions to the right people, also is start seeing us [engineers] as more than executors.
I’ve been thinking very deeply and profoundly about where do we stand as engineers if what we are gonna build in with tons of lines of code is gonna be in the hands of tons of users, are we a huge broadcast? where do we stand today inside the process? Are we executors or are we part of the procedure? I think I don’t have an answer, I believe we need to be in the middle of the whole process.
In the light of being resourceful, we need to deliver criticism and be honest about processes that may not be correct, secure, or straightforward for our users, we need to be really heart-spoken and opinionated when we get to deliver feedback with our users in mind — A year ago, I was building a new chart for our users, I didn’t understand what I was doing, the logic was tricky in the good light and horrible in the bad one, it was a failure in production — I forgot the user that day, that feature was not good enough, it was noisy and the UX/UI just make it worse.
I should have asked the correct question to get my concerns addressed, but I was playing the “only a developer” role that day, I remember hearing “this was a normal mistake” and thinking, “No, it’s not, we spend weeks building a feature that was poorly checked that could be way simpler”, there are always ways to simplify the noise around features and is our job to make it simpler.
There’s a design law for simplicity and limitations called Tesler’s law:
Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction.
Every feature we build should land in the limits of Tesler’s law, we need to safeguard our users and our teams from experiences that are nonventilated to the law, we may not be a group of experts, but we can ask tons of questions to help our teams and our products to grow. Asking the correct question will eventually lead us to start a dialogue, a dialogue will start a feedback session and this is where we can stop being only executors to be part of this constructive chain.
Ideas, Thoughts, and Comments
Asking this amount of questions will definitely lead us to something I call — a space of creativity — which is where we can grow a culture of dialogue and product.
As an engineer, we need to work on our communications skills to deliver dialogues that are beneficial for creativity and invention, without adding the common “tech fog” in the process that will lead us to go too technical, especially because this creates a dome that pushes the conversation to the boundaries of "tech square" and creates a mental box for solving a problem; so we end up with a halfway solution proposed by tech that only addresses half the problem, having good communication skills and trying to improve them is key to go to the next step; In the last couple of months, I have been trying to walk out of the woods and the fog and one of the things that have helped me the most is understanding what an idea, a thought, and a comment are.
An idea and thought are two words that are often confused when it comes to their meanings and connotations. The idea refers to a plan or a process that occurs in the mind in relation to the completion of work or duty, on the other hand, a thought is a mental process that keeps on going in the mind unabated. A comment is an adjacent and overview part to a principal concept, the first one can not live without the second one but the second one can live without the first one.
Having this concept clear will helps us to talk about any topic, from delivering feedback to developing a strategy, and making decisions, it also opens the door to complex and difficult problems.
Some teams especially in Growth and Product will choose practices and theoretical processes that can hurt more than the benefit that brings to the users, as Developers we are the last straw to stop a dangerous process, when it may work for the other teams it may compromise the integrity of the product we are building, for example, privacy.
Complex topic and moral dilemmas
After being able to handle communications and thoughts, we can talk about dilemmas that may not be the easiest topics to address without having some kind of confrontation with the team that is using some tool or method. Privacy has always been a moral dilemma, especially inside technology companies — It shouldn’t be — as engineers we end up planning how we address this dilemma, is our responsibility to keep our users safe and keep it away from prying eyes we take hard considerations about stored data in phones and databases, we think of methods of encryption from ciphers to certificates, going from Keystore to Keychain, but we may forget that this also includes Product, from analytics to multiple tools to do user research.
Almost a year ago I published this tweet asking about the implications of Session Replay software (a tool that recreates the clicks and views of a User)[No boundaries: Exfiltration of personal data by session-replay scripts] and crossing the boundaries of privacy and personal data.
The “Neutral” option is not a position we can take, the implications and normativity of these tools should be taken into consideration by developers — that are putting the SDK on the user phones — and by the Product persons — that are consuming this data — building team integrity will create integrity for the products.
At the end of the day, we are responsible for the decisions we take and make, we have a voice that needs to be heard around all the areas we can reach, make ourselves opinionated, and ask questions, especially this one, not only makes us better professionals but also better human beings.
Black boxes are like half-empty glasses
I use to think that Tech and Product were areas full of black boxes, I don’t let myself think as an executor in a black box fulfilling the wishes of other boxes, thinking this way gives us only half of the solution and probably the poorest one, it puts us inside a block that only knows half the answers to half of the questions. A good product solves a problem in the finest possible way, and this involves security, architecture, UX/UI, and performance. Thinking in a holistic way will bring us stronger ideas and solutions, but especially a culture that can be a harvest for years to come.
So, if you are at the end of this post, the only advice I can securely give you is that being a passive Software Engineer will lead you to become an executor, you won’t be creating products, you will only produce code; and friend, that’s two completely different things, so remember that, you are here to build products, not only code.
Disclaimer
I am not in the product area, these are opinions of how I conduct myself every day. I hate the word user, I think it cuts down the person that is consuming your app to a number, we tend to minimize this and we end up caring less about some parts. And finally, I’m always open for comments on my Twitter account or here.
If you need help, I’m always happy to help, you can find me here:
Medium as Dinorah Tovar
Twitter as @ddinorahtovar
StackOverflow as Dinorah Tovar
Happy Coding! 👩🏻💻
