Customer needs first, business needs second

When building a new product, first find the burning customer problem, then tie it back to a business objective. Too often teams focus primarily on the business needs – e.g. “we want to convert MAUs to DAUs” or “we want to sell into larger enterprises” – rather than the customer needs, resulting in motivated reasoning and mediocre products.

Startup incubator YCombinator has a famous edict: “Make something people want.” As written in the original blog post, they advise founders to not worry too much about the business model early on “not because making money is unimportant, but because it's so much easier than building something great.” While this is commonly accepted wisdom amongst early-stage startups, companies that start new product initiatives often do the opposite.

Customer needs first

Here is a typical scenario: a company has found product-market fit with their first product, and executives start looking to branch out into new markets or problem-spaces to increase growth. They do a market opportunity analysis, identify a promising area, and create a team to go over the opportunity with a mandate like “figure out how to take our product up-market” or “expand our offering to appeal to sales leaders.” People at the company have been thinking about this area for a while, so when the team sets off to do customer discovery, they have both a clear business need and a handful of early product ideas percolating through their minds.

This is a very dangerous combination. With the business need top-of-mind, teams often fall into the trap of motivated reasoning: as they start talking to customers new information is processed as “can I make the case that what this person wants matches our business need” rather than “what is this person’s real, hair-on-fire problem?” After hearing a few close-enough pieces of customer validation, confirmation bias kicks in and the team runs off to build the product. This is especially common if there is executive pressure on the team to find a solution quickly. The result is a nice-to-have product that doesn’t really address any core customer needs, and so produces middling results that don’t end up addressing the company needs either.

I have personally committed this mistake multiple times, and have seen it happen many more. With filepicker.io I wanted to grow our company from a developer tools product to a prosumer brand, ended up trying to force-fit a user need towards this goal, blew through nearly all of our remaining runway, and almost had to shut down the company as a result. In my first month at IFTTT, I was given the mandate “go find a way to make IFTTT a daily-use product;” despite multiple indications that we weren’t addressing a true customer problem, we convinced ourselves we were onto something and launched the “Do” suite of apps, only to shutter them a year later after mediocre adoption.

To avoid this, when building new products try as hard as possible to push the business needs out of your head and focus exclusively on solving a real customer pain. This is the same advice YC gives to brand new startups: “make something people want” and the rest will follow. Instead of talking to customers through the lens of “do they want something that could help us hit our company goals,” start from a place of “what are their biggest pain points right now, and how might we solve them?” The more you can shift the team mandate away from helping the company and point it instead towards solving a hair-on-fire problem for your customers, the more you’ll be able to avoid motivated reasoning and find a product that is truly worth building.

Business needs second

Once you have confidence that you’ve truly identified a strong customer need and have some idea as to how you could solve it, then you can start incorporating the business needs and see how they fit in. For a brand new startup, this means creating the initial business model, but for a new product within an existing company it can be more complicated. Most of the time, in solving the customer’s need you’ll also solve the desired business need, and everything will be great. Occasionally, the two won’t line up quite as neatly: perhaps the product you’ve identified would be a great self-service prosumer SaaS business, but your company is built around large enterprise sales. Google Wave might have been a massively successful business collaboration tool predating Slack, but apparently at the time the Google executive team wanted a consumer success to compete with Facebook. At Clever, we’ve uncovered ideas that districts were excited to pay for, but we weren’t ready to take the step of building a school-focused sales team.

Again, these instances where the customer need doesn’t align with the original business need are rare, but they do happen. In these cases, there are only two good options: solve the customer need and end up growing the business in a different way than initially intended, or shelve the idea for later and go searching for a different customer need. While it’s tempting to try to “tweak” the identified customer need or solution to try to solve the business needs as well, it is all too easy to fall prey to motivated reasoning and end up with a product that solves neither the customer needs nor the business needs (Google Wave, for example).

Despite all their advantages, established companies often struggle with new product development because of their bias towards thinking about business needs before customer needs. As a result, teams often fall prey to motivated reasoning and build a product that doesn’t solve a true customer need, and as a result end up also failing to solve the business need. Instead, new product teams – like startups – should focus first and foremost on building something people want.