One of the biggest struggles for any product-based company is to know exactly what to build. What to build is really important because that’s what ends up driving your business forward and it’s also the only way to attract, and eventually retain customers. Then, word of mouth, will do a lot of the “marketing” in spreading the word and expand the influence of your product to prospective new customers and that’s how part of the initial growth can happen.

However, almost paradoxically, after having the first solid customer base in place, something weird happens to most product based companies, especially as they scale up:

essentially, they stop talking to clients. Why is this happening?

Instead of having direct conversations with the customer, which is the most relevant stakeholder of all, we start introducing several proxies between the development team and the customer, which, just like the broken telephone game, will twist the concerns and expectations from both sides, and it usually ends up on having developers building the wrong thing, working in isolation from the customer, taking longer to deliver… just to learn after the fact that it was not really what was intended at all.

The problem with introducing these proxy stakeholders like Product Owners, Managers, Customer Relations, etc, is that the people in the middle are not tied directly to the product development directly, so, when translating the needs of the customer back to the development team, an obvious disconnect happens because the interface between both ends only knows about one side (the business and/ore requirements), but, is somewhat in the dark about the other side (the development team and its efforts) which makes interfacing literally impossible.

I think it would be very valuable if product based companies would bring back the practice that most likely they used originally of keeping in touch with customers directly, making them part of the feedback loop of the product development, because this is the most straightforward way of ensuring that what is being built is exactly what the customer will need, and, simultaneously, this can help shaping future efforts, so, a roadmap where the development team talks to the customers directly, will look very different of a roadmap that is developed in isolation by a product team where the only traces of customer communication come in the form of emails or messages exchanged between a product owner or a consultant and the customer themselves.

By involving developers to chat with clients directly, taking an exploratory approach and being open about flaws in the product, what’s achievable on a 3-6 months horizon and by agreeing with customers on what is the best thing to build right now that adds the most value to the product, that’s how you can ensure that you are delivering maximum value as a team, independently of how you work and whatever methodology you follow.

One of the best recollections I have of this is of the work done at my previous job, where I witnessed the value of this approach firsthand. We had an old product being used by a handful of clients that were brinnging in several return to the company, and, essentially, the clients wanted a re-work of the whole thing, a complete overhaul to make it better fit their own data ingestion pipelines and to improve the insights they got out of the data. Now, this was a relatively small company where the hierarchy was very, very flat, essentially, there were developers and a couple of managers who had been responsible for the creation of the product and the direction on which we wanted to take it as a company. But, one thing they never, ever lost sight of was the goal: we want to do this to make sure that we are delivering the best possible value to our clients.

So at the time of this large rewrite effort, one of our managers jumped on a call with a few people from the customer side who were actively using the product on a very frequent basis. These calls would usually take place in a separate office area within the company so nobody would disturb the call. And, the first thing my manager did was, literally to get me and a QA colleague together with him in the same room, we brought a notebook, and then we just had an almost informal chat with the client with the purpose of bringing into light their pain points with the existing product, how their changing requirements drove them to ask us for a re-write and essentially framing their new business concerns to us.

It was a truly engaging experience and one that was a real eye opener:

• things that we thought worked great, apparently were even overlooked by them or not well understood;
• small things usually have a big impact: sometimes, taking 5 minutes to add some feedback notification after an action brings more value to them that completely new features;
• giving them the absolute freedom to speak their minds also revealed the angle from which they looked at the product: “Look guys, this is great, but this button here is very confusing, can we rethink this whole user flow?”. Again, more often than not, this revealed things that we would not have expected and we could gain a much broader understanding of how they used the product;

After this meeting, the first of its kind, there were several other instances where this value discovering activity manifested itself again, and its main point is extremely important: you don’t know what the client is doing until you hear it from their mouths or see them using the product. Every other activity done in order to try and grasp client value, priority of work or feature discovery is essentially time (partially) wasted, because, why should we use proxies when we can hear it directly from the only stakeholders that matter?

I think a huge part of the problem here is that there can be certain business which are more prone to have products that rely on sensitive and/or customer-specific data that can’t simply be shared in informal meetings with other stakeholders due to NDAs, etc. But, I vouch that this shouldn’t deter you, as a company and/or team to search for solutions in this space in order to make it possible and easy, aka, the path of least resistance to truly include customers in your feedback loops. The way we handled this in my previous job when we would go into these meetings was by relying on something analogous to feature flags, specifically, what I would call today an anonimization flag. When the code to be deployed was rebuilt with this flag set to true, all the sensitive schema names were replaced with generic names under the hood, but, the entire app functionality was preserved: “USA” would be replaced with “Country A”, a specific customer name would become “Customer 1” and so on and so forth in such a way that the customers in the meeting could have all the freedom to focus on discussing functionality and the company was at no liability to break any NDAs.

I believe that if more companies and more teams start to bring back the customer-centric feedback loop approach, we will all be able to design better products, increase productivity, velocity and happiness for both developers and customers.