Navigating the Disconnect in Product Development

In the initial stages, successful products (and startups) usually work closely with the end users. I have personally been a believer of the Build, Fix & Improve philosophy.

Background: Build, Fix & Improve

Build.

The idea is that we first get the solution out. This is even more important if the solution that we want to ship didn't exist at all. So here, the idea is to break the period of inactivity and get it out. Do not seek perfection and fall into the spiral (it's a trap!).

Fix.

Once the solution is out and has at least solved a problem as intended, now is the time to fix it. With our initial set of users onboard (early adopters), we can now absorb insights. We can understand how the users are interacting with the product and also address the issues that this solution will have. Now is also a good time to solve funnel drops and address the concerns our users face in the product/process/flows. Developing new features without fully understanding the ones that were shipped earlier can make things more chaotic.

Improve.

Remember the best experience you had envisioned earlier? This is when you want to work on it. The solution is built, solving problems, and has a good success rate. But the needs of our end users are ever-evolving.

Situation

The first two phases are direct, and since we stay closer to the end users there, we usually have a clear picture in front of us. The challenges surface during the third phase. The intent here is to improve, but as the application scales, we begin drifting away from the end users and rely more on product telemetry and statistics. These proxy methods are good but often miss out on the nuances.

The disconnect snowballs, and we try to cover it up by adding more product/engineering hands to the problem. This temporarily alleviates the problem, but it won't fix it.

I was working on a B2B product for the past two years, and we found ourselves stuck in a similar situation some time back. We were trying anything and everything to "optimize." Not much had changed in terms of the metrics, and any communications with the end users ended up being informative but not insightful.

After a few (about a hundred) user interviews and interactions, we realized two major things.

1. The end user was not always the decision maker (licensee). If someone was an active user of the platform, it never directly meant that they were the decision maker. So, all feedback that we gathered from a decision maker had a bias. They only wanted discounted pricing and more customer insights for the target group they were serving. The product took a back seat during such feedback meetings. But by asking the actual end users, we could see meaningful details, sometimes sharp and sometimes appreciative. So, we wanted to have a free-flowing connection with the actual users and not the licensee of the products.

2. The roadmap we had was far away from what the end users wanted. We were building add-ons and automations while they cared more about speed and operational efficiency. This problem stemmed from #1 above. So, we had to address it once and for all (it shouldn't break for the next few quarters).

Solution

The target was to gather feedback from over a hundred thousand DAU (daily active users). Since the users were not technically very aware, email was not an option. We thought of creating a voice call-based helpline, but the cost was high. Moreover, we did not want to lose out on the telemetry details we had. Nor did we want the user to input a lot of information while being on a call with us. Also, a call-based setup would not give us a firsthand insight into the suggestions/feedback we get and the issues they face.

Enter - chat.

With around 535.8 million active Indians on WhatsApp (and growing), we realized that texting/typing was more direct, and most of the users would know how to use a keyboard to convey information.

This solved the top of the funnel, but not the end of it. So we brainstormed what our teams (specifically engineering and product) are usually hooked on to.

Slack/Teams or any other org-level communication tool. Slack in our case.

Yes, that is it.

1. We created a channel in Slack.
2. Exposed a web hook to post messages in the channel via a proxy.
3. And directly pushed the feedback to this channel from our products.

Yes! These are raw, unfiltered, misspelled, at times hard to read sentences, but this has been one of our best releases with a super high impact. The channel serves as a gold mine for all our brainstorming sessions. We feel more connected to the users now.

Impact

Our NPS increased by 11 points over the next 3 months and another 7 points in the next 3. It now holds stable at around 41, and we have one of the best-performing products ever shipped by the team.

Bonus!

Yes, that is not all. The same channel also serves as a source of on ground bugs and broken releases. Way before the systems flag and alert us, the users do. Sometimes it is a hoax but has twice saved us and them from monetory losses.

One of my favourite solves, so definitely - that worked! ❤️