Engineers-First, Customer-First Approach

What makes a successful product?

Is it the ability to pinpoint a market-need or maybe even create one?

Is it the ability to find a path to a better product than what the market already offers?

Or is it about establishing a good relationship with a customer then hiring the best engineers to materialize their vision?

Every entrepreneur in the market looks for answers to some of these questions regardless of where they stand in the market, or what level of experience they have.

In the enterprise world, the equation gets a bit more complex. Products become more and more complex, the processes that are set in place might make the decision-making process and responsibility somewhat atomic to the point where some engineers in some of the most popular companies don’t even know where their code is going to be deployed or which product it’s going to serve.

I was fortunate to be a part of tens of large enterprise products, had the chance to work with some startups, mid and small size businesses and even individuals who have dreams to get an idea out there and see how far it can go, and here’s what I learned from this process:

Identifying the Product

There are so many ways the most popular product ideas out there today were found.

The most common factor of them all, is that the product was able to fulfill a need, any of Maslow’s hierarchy needs whether it’s basic, social or a self-actualization need.

But good products come from strong communication and connection to reality. When humanity needed to go faster, it invented the trains. When humanity needed to go further, it invented airplanes and when it needed to be more connected, it invented the internet.

The identification of a successful product idea, and the identification of a common human unfulfilled need is what mainly drives a successful product anywhere. And that can never be achieved if one is detached from reality, from communicating and engaging with people on daily basis.

Identifying a common need can today be easily achieved by reading the news, analyzing social media, or simply looking around and visualizing something one would care about enough to make life better, to push for the survival of humanity and its evolution.

Exploring the possibilities of what can be done, then dreaming to push that even further is what drives an authentic product versus a money-grab garbage that gets forgotten in the matters of short years if not months.

But identifying a successful product also requires courage and the ability and willingness to take risks and be ready to fail then try again, and again until it happens. Because failing builds a closer sense of the forever changing rules of the market, and a more pressure to dive deeper to find something people would actually care to buy and care for.

Identifying a successful product is a lost art the needs to be taught in engineering schools today, some of the most popular materials today are more about fooling the consumers to buy something they don’t need rather than creating something that would last. Something that someone would care about, like electricity!

Identifying Key-Players

Every product out there has two types of key players: the providers, and the consumers.

The providers are the people responsible for taking in an idea and visualizing it as a reality then executing the development process to slowly but surely see it grow and materialize every single day.

The consumers are your end-users, not the ones in the middle giving out an opinion about a product they will never use. But rather the ones who are going to use your product on daily basis.

There’s a big problem in the software industry today where non-product-essential roles is starting to widen the gap between the providers and the consumers. And the wider this gap gets, the less and less the quality of the product becomes and the more the likelihood for miscommunications to occur.

Somehow, at some point in time, the communication aspect in software engineering as a profession was completely pulled out of the books, and somehow it has become totally acceptable for a software engineer to lack the social skills they need to build a relationship with other engineers and the clients.

Communication just like anything else is a skill, it requires training, reading, and practicing along with some trails and errors to develop a sense and a pattern of when to sense the other person is more engaged into the conversation, when to stop, when to go further and how to create opportunity for the best of all parties involved.

But with some of the engineers allowing this mindset to take away a very important aspect of their craft, new roles have been born to bridge the gap between the providers and the consumers. Roles like a “communicator” whom their only responsibility is to regurgitate what the client already said, and from my experiences, there are always missing pieces that requires more meetings, more time consumption, and less productivity.

Usually, communicators have little to no technical skills, they might be great at building the relationship with the consumers, often selling a client a bunch of lies about features that are impossible to develop within a given period of time or ever, but communicators are usually completely foreign from technical language perspective, sometimes to the point where what was believed to be built as a bicycle was actually meant to be a car.

When a communicator’s promises to build an impossible product fails, or their deadlines are not met, they blame the engineers, the ones actually spending the nights trying to turn an impossible vision into a reality – this goes to prove that this role and the roles like it are just a sign of potentially a disastrous project and even further a failing product with broken communication.

It’s important to understand that communication to a software engineers is just as important as learning object-oriented programming or the latest pattern, architecture, or API.

Once that is established, a much efficient relationship, communication and less meetings would be required to get from point A to point B in developing any product, regardless how complicated it is.

Identifying the engineers on any given project, and getting them together with the consumers is the responsibility of any tech lead to ensure multiple engineers are observing the client needs and asking the right questions to implement the desired functionality.

In fact, from years of experience being both a founder and a tech lead on most of my projects I was able to observe how the engineers were able to reconceptualize a given business process or flow and turn it into something more efficient and more productive while engaging the consumers as part of the development process.

This direct engagement between the providers and the consumers has an even further positive market-impact – it makes the end-users more confident in the product being built and creates an even more loyal base of clients who are willing to engage further to adjust and mold the product they already use into something that is even more effective and useful to a wider base of consumers.

One of the most common symptoms of a lack of communications between the key-players in the development of any products is that you will find that engineers are busy doing more meetings and less engineering, more PowerPoint slides than code and more designing and arguing than developing.

Status meeting, retro meetings, grooming, refining, and planning meetings, sometimes even meetings about having meetings (that one is sadly real) and further time wasted on reporting and status updates where it eventually leads to some middle-management tier personnel to say: “Hm, good!”.

I’ve seen in so many places engineers being told what to work on, instead of allowing them to explore and find something they feel passionate about so the best results can be achieved.

You can tell very easily how engaged any given engineer is by simply measuring their pulse about the purpose of what they are building, why they are building it, and why it’s important to develop the best experience possible to serve a particular need.

Identifying the Process

You may find a great idea, and you may also find the right key-players that would turn that idea into a massive success, but without a process, there will be no product.

Standardization, commitment, and execution – these are they keywords you need to focus on when trying to identify a successful product development process.

A non-standardized development process might cause a great idea to go completely off the rails, especially with software engineering as the product becomes more and more complex, a stricter engineering process should drive the requirement gathers, design, development, deployment, testing and marketing process.

Each and every step in the development lifecycle shall follow a particular protocol to ensure the efficiency and success of the product development.

In order for you to be able to identify a successful product development process, you have to understand the different aspects a development process is required to tackle, which are as follows:

Innovation aspect

Every single development process must consider the innovation aspect of it – in other words, being always on the search for smaller incremental changes that improves the process mid-air while actually developing the product.

Communication aspect

The team working on the product must establish a code of conduct for communication, for instance, when communicating with customers it’s important to listen more than talk. Help them understand what can and can’t be done within their budget or technology limits so they can make an informed decision of how to go forward with their sponsorship.

But engineers within themselves must also establish some ground rules, such as open pull requests for instance must be looked at immediately and everything else must be put on-hold to unblock the engineers waiting for the merge.

Engineers must assign the role of a lead amongst themselves to settle disagreements once they occur when no party is willing to concede or change their opinions.

The communication aspect guarantees a flawless development process, and it ensures that every individual on the team is treated as an individual, not a cog in a machine or a “resource” like some folks like to call them.

Development aspect

Standardizing the development process itself, such as coding guidelines, architecture guidelines and many others help the engineers evolve and progress in their craft, it gives them a sense of responsibility and ownership, but also ensures their development experience is the best it can be.

It’s the responsibility of the tech leads along with every other team member to work together on standardizing their development process, agree on their coding standard and guidelines and make sure all their work religiously follows these standards and enforce it through their code reviews and testing.

At the end, it’s important to understand that a development process that doesn’t allow engineers to get in direct contact with the consumers, gather their own requirements and conceptualize how the business flow is going to be developed, a process like that shall inevitably fail, crash and burn.

An engineers-first, customers-first approach is what drives a successful product. Because a product is nothing, but the materialization of a successful relationship built and thoughtfully established between the engineers and the customers.

Anything that clouds that process is very likely to be the reason why a lot of products fail today. But there is always time to adjust an existing process and steer the ship no matter how big it is into the right direction to ensure a meaningful effort can be rewarded with a truly useful product that shall benefit the world.