If I had a dollar for every time a founder has told me ‘if I’d trusted my instinct, I’d have done it this other way and not screwed things up” I would be rich by now. This becomes even more confusing when it’s product decisions. Especially when, after all your customer discovery conversations, the product the customer is asking for does not satisfy the need your gut tells you that the user has. What I suggest to the founders in these instances is that they trust their gut and build a product that serves the user as the product team believes it should. I know ‘lean startup folk’ will hate my guts for this but I don’t just offer this idea lightly, I practice what I preach.
Two Situations where the Customer Got The Need Wrong
This past year, at Asha Labs, we’ve spun out two chatbot products and, in both cases, if we’d listened to the customer during product development we would have built the absolute wrong product. We chose to ignore the customer, trust our guts and base the product on the user insights we had. The insights that drew us to these opportunities in the first place.
Powerbot.co.
With our background in building customer facing products for utility industry consumers, we’ve learned that customers generally do not want to engage with their electricity/water provider. The customers’ engagement with their providers tend to be negative — bill paying, outage rectification etc- while the utility providers (bless their hearts) forever yearn to improve their customer engagement metrics.
The requests we got tended to be “We want consumer engagement! We want engagement with our consumers so that we can increase our Net Promoter Score or JD Power scores!”. While all the user wants is to spend as little time as possible on their interaction with the utility. Consumers want ‘Attention-Saving’ interactions not engagement, especially from their utilities. As Trendwatching points out the goal of attention saving products and consumer experiences, which is what a chatbot is, in this instance is to ensure that the interaction with the consumer saves the consumer time on actions that can be achieved automatically while seamlessly using the data that the utility already has about these consumers. Data that allows the utility treat the consumer within the proper context.
Counter to the Utility’s request, we decided to build an attention saving context aware chatbot. It solved for either bill issues or provided information on future expenses, pathing the user in the direction we gleaned would best serve their needs through context developed from looking at their social media behavior. The experiment is still ongoing but results so far show we did the right thing by ignoring the customers’ request and let our gut understanding of the consumer lead product development.
RealAssist.
The second example of going against the customers request can be considered the opposite of the powerbot example; in this case, the longer the user (prospective homebuyer) stays engaging with our bot, the more information we can gather which helps us serve the customer (real estate agent) better. RealAssist is a chatbot to help real estate agents get a better sense for who is genuinely interested and able to buy the home the agent has available for viewing. We were solving for the problem of real estate agents providing details on a home to a prospective buyer who sees a house for sale, cannot view immediately but wants to learn more.
If we’d listened to real estate agents, all they wanted was more views on a home. More people coming through the door. Especially in not-so-hot real estate markets. The agents think that it’s a numbers game and the key to selling a place is getting as many people through the viewing doors as possible. But we disagreed with that premise, our gut told us different (having been homebuyers ourselves); our belief is that an agent can better engage with prospective homebuyers if they have a little more context on who the prospect is. So we built functionality into the mobile/SMS chatbot that enabled us show the agent who the prospect is (wireframe below). We provide an anonymized view of who sent the text and we augment the agents interaction with the customer through customized messages. This additional functionality is the real value here and not the initial request the agents had to just ‘get more people through the doors of the home to increase my chances of selling the home’. Again, tests ongoing but we already know we were right to ignore the customers request.
Following Your Gut Instinct In Developing Products
When is it OK to build a different product from the one your customer says they want? What the two instances above highlight is that the customer (the utility in example 1 and real estate agencies in example 2 who actually pay us) does not truly understand the users needs. But when you/your team understand the user, because for example you are (truly) the user, it makes sense to go with gut and build what you think is the right product. There’s also another point when it’s OK to go with your gut.
When founders ask me what to do when they are faced with these sort of decisions what I suggest to them is that they should trust their instincts but only when the decision is time constrained and they have to get something out quickly. See, instinct tends to be biased and overconfident if it is the only data point we use to make decisions. Research suggests that there are two instances when gut based decision-making is the best path. There are in
- situations of low turbulence and high structure (i.e not for stock picking) or
- when the situation allows you to get feedback and use that feedback to improve your decision making so that, should there come a similar situation in the future, you’ve improved your chances of making an instinct-based decision in the future.
One of the other points, as suggested by Daniel Kahneman in ‘Thinking Fast & Slow’ is that instinct/gut is partly honed by data and information you’ve received and stored away over time. It’s a reserve of data that nudges you in a certain way when a decision is to be made. Use it as part of a set of tools for making decisions. But never as the sole tool.
Sometimes you just have to override the customer (the person who pays) because you understand the product user more than your customer does. When your product succeeds, the customer succeeds. Your goals are to nail the user's pain and communicate your solution in terms that your customer can convey as success to stakeholders. Just don’t make the customer feel they were wrong!
Please share, like, and tweet and sign up for the Polymathic Monthly Newsletter — if you’ve read this far, I’m betting you’ll love it.