Thread by @pedro_galo

🧶I have been reflecting on how many product professionals today find it negative to fulfill a customer's request, even in early-stage products. The way I see this issue is illustrated in the graph below. #SaaS #ProductManagement #startup

When a product is new, we usually have a small team, with less capacity to absorb demands. But the challenge we have is to win the first customers, deliver value and get recurring revenue from it - the famous Product Market Fit.

For this, we need to be willing to accept more requests from the few prospects we have. This does not mean that we will accept any request, but it does mean that our filter is less rigorous.

This is important because at this stage the customer (usually) has much more knowledge of the business than we as entrepreneurs or product professionals.

At this stage, accepting requests can mean getting new customers as a result, and this at this time is a matter of life or death for the business or product. It's hard to do surveys with many users, you have to take risks and exercise creativity and logic.

It's important to adapt the requests that come to your vision and to what you imagine will make sense for new customers who come to adopt your tool in the future, thinking about the points of the features that need to be configurable according to the customer.

A simple example: Customer requested a workflow that has 5 different statuses for a certain process. Make it easy to change the name of these statuses and even insert or remove new steps in this workflow for future customers.

It is common that many requests one day become discontinued features. For those who only saw part of the story it seems that bad decisions were made in the past, but often that request was important to bring a key customer home, in terms of LTV everything is ok.

As time goes by, if the product gains traction, you and your company will absorb more knowledge about the business domain, also, you will have more users/customers and the filter criteria will gain robustness, you can no longer accept almost all customer requests.

This is because, by becoming a product with a solid customer base, you start to worry more about keeping current customers engaged, and how to replicate the same value proposition to new customers. Thats your new focus.

The product vision becomes clearer because along the way we become less myopic, we can see further and know where there is more chance of finding "gold" as we have more contact with customers to know the pain points of most of them.

The product team grows along with the company, and as the strategy gains more body, you become less reactive to the market and therefore more proactive, therefore, you respond proportionally less to customer requests.

Product engineering also needs to follow this cycle. The level of infrastructure sophistication and test coverage is directly proportional to the maturity that the product has in the market.

It doesn't make sense to build your infrastructure for 1 million users while you haven't even won the first user. It's better to have to solve this technical debt in the future than to lose timing and risk losing customers at the beginning of the product lifecycle.

The architecture needs to be more flexible, as the course of development tends to change overnight at the beginning. The team needs to have the stomach to deal with this.

As the customer base increases, the story changes. Scale, quality, and security need to gain strength in the development agenda. Even so, it is important to understand which features are in less mature stages and do not yet need to embrace this complexity.

Did you like the content? Give it a like and comment below what you thought.