Gabriel Garcia Márquez (Gabo), the great Colombian writer, wrote wonderful books in his life. I started reading Gabo with "Chronicle of a Death Foretold" (https://amzn.to/3WZK7f6), one of those books that grabs you from the beginning and you can't stop reading until the end.

The interesting thing about Gabo is getting to know his story and understanding that the writer was always there. Gabo starts as a journalist in a small newspaper, during a dictatorship in Colombia, where reporters have the difficult task of writing something that doesn't create any problems with the government.

Young Gabo comes across the real story of a shipwreck survivor, who survives 10 days adrift and tells the story in detail, recorded in 20 sessions of 6 hours each, which were later published in chapters in the newspaper and later became one of Gabo's first books - "The Story of a Shipwrecked Sailor" (https://amzn.to/3NkA7K6). The end of the story is interesting because it leads to a series of accusations against the government that culminate in the closure of the newspaper. The writer was already there. How to reach the book? It wasn't a clear method yet.

Gabo became famous later by writing "One Hundred Years of Solitude" (https://amzn.to/3NmxtDz), for which he won the Nobel Prize in Literature in 1982. Gabo was in a very complicated economic situation when he wrote the book. His wife, Mercedes Barcha, takes care of everyday life's practicalities while Gabo locks himself in a room for 18 months to write the masterpiece that brought him fame.

In an interview (https://www.youtube.com/watch?v=hB3OIMGOBR4), Gabo says that at a certain point, the situation was so difficult that they couldn't afford to pay the rent anymore. One day, the phone rang. The landlord demanded the overdue rent - "Ma'am, you owe three months' rent." Mercedes covers the phone and asks, "How much longer until the book is finished?" And he says, "Six months." Mercedes then tells the landlord, "We owe three months, and we'll owe six months more, but we will pay everything we owe." He asks, "Do you give me your word?" And she replies, "Yes, I give you my word."

After finishing the call, Mercedes looks at Gabo and says, "I gave my word of honor..." Gabo finishes the book months later, and the rest is history.

I write this as a curiosity about what it's like to write a book/produce work/create a product. Gabo, besides focus and inspiration and all his creative ability, certainly had a method. This method was much more than just locking himself in a room for hours for 18 months to produce a work of art or the pressure of the word of honor given by Mercedes... I also write this because I identify with several moments of creating products where time constraints, deadlines, and word commitments were strong and ended up motivating us to create ingenious solutions.

This leads me to think, what is the method for creating software products? I did it empirically for many years, without realizing exactly what steps I followed or how structured (or completely random) the process was.

While we had a small and cohesive team, the process happened through discussions (or many discussions) around a table. Trying to ask more questions than giving ready-made answers, we reached a consensus on what needed to be built - and we built it!

When I faced the need to scale the team (more people) and the process (more companies and different products), I started to pause and think about the method, if there was any.

I ended up arriving at a set of steps that I try to follow and convey to product teams. They are simple steps, but they greatly help the process, especially in the initial phase of product inception.

So, let's go through the steps!

1 - Problem Definition

Clear problem definition is something difficult to do. Many teams start by trying to write the product without knowing what they are actually solving. I divide this phase into three questions:

1 - What is the problem you are solving?
2 - Who is the user of your product?
3 - What is the product you are going to build?

These questions may seem simple, but they help you identify very important points in product development.

What exactly are you trying to solve? What is the problem? How does it affect your customer's life?

Not necessarily this pain is something that the customer knows. Sometimes, the "status quo" makes the problem go unnoticed or the user simply doesn't understand that there could be a tool that solves it or makes them more productive. It is up to you to make this discovery. How do you do it? By going to the field! I have a list on my iPhone that I call "Things that bother me in the world" that helps me think about everything around me that could potentially be improved. Feel the experience from the user's point of view, live their pain, and that way you can define the first point on my list.

Who is the user of the product? This is a question that can have multiple answers. In one of my businesses, GreenMile (www.greenmile.com), we built software to optimize driver routes. Who was the user we solved the pain for? Several - the driver we worked with to make them more productive, which was a key piece for the system to work, the managers who needed indicators and increased productivity, and ensuring the level of service in product delivery. But the main focus was on the driver. The user we needed to win over, and without whom, the rest of the application would not work. Prioritizing his experience was crucial in the initial stage.

From there, making it clear to the entire team, what is the problem and user, you will work on what product you will actually build. Tests, validations, and rapid iterations are important here because you often don't have a clear vision how to solve the problem. The statement that you are ready to develop the software correctly when you have just finished writing it is very true. Write small parts, and validate. Iterate. Validate...

2 - Why

I really like the work of Simon Sinek - Start with Why (https://amzn.to/45YjNGs). If you don't want to read his book, watch this video, it's gold (https://www.youtube.com/watch?v=u4ZoJKF_VuA).

It's important to define why you're doing this. The "why" goes beyond the problem. It's the motivation, the purpose. It helps clearly communicate to the team what the vision of what needs to be built is, even in moments when we don't yet know what we're going to build. In Sinek's framework, he divides it into three stages - "Why," "How," "What."

I'm going to tell a story here that I experienced firsthand. At the beginning of the century, I co-founded a company that provided vehicle tracking services (www.trixlog.com). We aimed to offer a simple and affordable tracker that, when installed in vehicles, provided basic information such as the vehicle's location, the route it had taken over a certain period of time, etc.

Red Ocean (https://amzn.to/45XRGXJ)! Hundreds of competitors doing the same thing, often better than we did, and at prices we couldn't compete with. In short, a terrible business!

We discovered the obvious - we needed to differentiate ourselves. We decided to focus on telematics - which basically meant extracting all the data from a vehicle, such as acceleration, braking, idle time, fuel consumption, etc. There you go! We were going to solve a user's problem - fleet visibility, which often involved hundreds of vehicles! We had defined the problem, the user, and the product - a series of KPIs, dashboards, graphs that would impress any director interested in managing their vehicles!

Right? Wrong! Our customers had a problem, but they weren't exactly users who would analyze KPIs on a dashboard to make decisions about their fleet. The dashboards were certainly valuable, but they weren't the main value of the software.

One day, while visiting a client's operation, I attended a defensive driving training session with the drivers. I saw 100 drivers in a classroom with a suited instructor talking about how to drive a vehicle well. I looked around and realized that no one was really paying attention to the lecture. The classroom was not the natural environment for many of the drivers, and the generic content taught by someone who was not seen as an authority on the subject generated the "what am I doing here" effect in the drivers within 5 minutes.

The topic was serious. This particular client caused, on average, 13 deaths per year due to traffic accidents. We restructured the entire software to teach drivers how to drive better, not in a generic way, but by using all the data we collected with our equipment and pointing out exactly what the main areas of improvement were for each driver. We ended up creating a mentor (through software) that understood each driver's behavior and showed them exactly what they needed to improve!

We rewrote our Why/How/What - "We change the way people drive vehicles" - To solve this, we created a suite of products, hardware, and software, making driving safer, more efficient, and measurable.

We started sailing in a Blue Ocean, and what's better, we reduced the number of fatal accidents for this client from 13 to zero. We began saving lives with every line of code we wrote!

3 - Pre Mortem

Many people are familiar with the concept of a post-mortem in software. When a system fails, a document is written to explain (and address) the cause of the problem.

I met Professor Huggy Rao (https://www.linkedin.com/in/hayagreevarao/) at Stanford during a course on scaling teams. Professor Rao wrote a book called "Scaling up Excellence" (https://amzn.to/43vN8Gl), in which he introduces an intriguing concept - writing the "pre-mortem" of your product. It involves writing, on a piece of paper, like an obituary, the reasons why your product failed.

This exercise forces you to consider the possible mistakes that could lead your product to ruin and makes you think twice before embarking on that path. It's pure gold!

4 - 5x5

The concept of 5x5 is simple - 5 seconds for the user to be inside your platform and 5 minutes for the Wow!

Obviously, not all software will allow onboarding in 5 seconds, but the concept of 5x5 helps you build mechanisms to speed up the entire process. How to achieve the "wow" in 5 minutes? That's a good exercise!

5 - 10x

How to make your user ten times more productive using your software. In the era of artificial intelligence, increasing your user's productivity has to be an obligation for your software. How do you think productivity on your solution?

If your software is purely transactional, it is easily replaceable. If your software changes your user's life, it becomes an object of desire.

6 - Stickness

How to make your software indispensable for your user? How to make the barrier of entry for your competitor high, combining the differentiators of your product with all the adhesion you have created around it?

Final words

There are many other steps in product creation. The size of the market, and how willing it is to pay for the product are some of the additional questions that you will certainly need to address, but the six steps listed here are certainly important steps in the "inception" phase.

And to conclude, my favorite novel by Gabo is "Love in the Time of Cholera" (https://amzn.to/3oWfLxA)...

...had kept his answer ready for fifty-three years, seven months and eleven days and nights. 'Forever,' he said.

Read it!