Avoid falling into the building trap

As a developer, if you only look at a list of requirements to follow, building software products can look simple.

It's when we start looking at what's behind that list of requirements that things get more complicated.

In most of my experience, as a frontend developer, I was mainly concerned about the technicalities of the feature I was building, and not necessarily concerned about the reasons why we were actually doing that and the problem we were trying to solve.

From consultancy to product

Whether you like it or not, consultancy and product companies are different worlds, there are the ones that prefer to work on projects and the ones that like to focus on products.

Skipping the details, and generalizing it a lot, when I first started to work for what I called product companies, I realized behind the scenes of capturing requirements, there are other important aspects like making an impact and delivering value.

These new areas of interest that I knew will help me to become a better engineer, definitely clicked at the time we decided to build our own product with friends, called ServiteOnline.

A lightweight e-commerce solution for stores to go digital in regard to the management of orders.

We have been in the market for more than 4 years, but in the beginning, as we were just building new features from scratch, coming all from a technical background, we fell into the so-called “Building Trap”

The building trap

At the time we started building a prototype, we were just focusing on delivering and producing things, just for the sake of making new releases.

So we developed some pretty cool features and put them as part of our nice shiny catalog on our marketing page.

Features that were only making our product more complex rather than more relevant to our customers.

Back then our main drivers were, making assumptions about something that can be potentially useful for customers, looking at competitors, and just random cool-looking features.

In other words, our mistakes were:

• Assuming before asking and validating problems with customers.

• Overplanning the perfect feature, covering every possible scenario instead of learning by doing and validating ideas before making them part of the core.

• Iterate solutions instead of committing to big projects.

• Getting into deep and endless discussions of meaningless features.

We once spent months developing a feature that nobody ended up using. And this, especially in small teams where capacity is low, must be avoided.

As soon as we started getting feedback from clients, plus our own discovery of the areas that I mentioned before, we switched the focus a bit and started to look at things to build from a different angle.

The first change we did was to be customer-oriented, identify problems and turn them into solutions. Using this as a starting point to bring new ideas to the table, whether they were brand new or just improvements and simplification of existing functionality.

Questioning ideas became part of our nature, what kind of value are we bringing? What are we trying to solve? Are we even focused on the right thing? In which way does this impact our main goal as a product? Is now the right time to invest effort into this?

By looking for answers to those questions I realized how important the role of a product manager can be. Some sort of mindset that in some cases is embedded in other roles. I have recently heard of the term Product Developers, referring to those devs committed to the idea of a product.

We ended up prioritizing ideas based on effort vs customer value, which led to better adoption of the features and improvements we have made over the years.

Don't focus on velocity

Something that is worth mentioning is that we also try to prevent ourselves to focus on velocity, customer value should be our main driver.

Being agile by delivering faster doesn't mean we are delivering meaningful decisions. Maximizing customer value, and outcomes over outputs.

We shouldn't be looking at the amount features we launch into the product; or the number of tasks we have closed, but the goals, strategically speaking, we have achieved as a product.

Sorry if this sounds repetitive, as I have shared my opinion on this particular topic before. But iterations and prototyping become crucial in the sense that we can validate ideas, and remove assumptions from the table more quicker.

Dividing releases into smaller chunks and measuring the impact, give us the opportunity to react faster if the impact we were expecting didn't happen.

And if we can encourage and convince the rest of the team to think this way, it will help us to have more autonomy aligned with the main problems we are tackling as a product.