Many product meetings follow a similar pattern: from what we want and quantitative data, we come up with potential solutions that get us further to our goals.

In those meetings, what we want is usually to achieve a business or product outcome or, if the outcome’s not clear, by default we’ll move some metrics up or down. Increase activation by X%, reduce churn by Y% are typical examples. This is an oversimplification, but it’s not that far off from the truth.

As an example, we’re trying to increase something around activation, we want to see people being onboarded into the product and taking the desired actions, like wishlisting items or asking a seller for a quote. Suppose that we have data that shows clicks, page visits and the like. We sit down and start to come up with solutions: add a button, reorder the UI, create a new onboarding flow, etc. Eventually, we’ll take some of those solutions and implement them.

Where does the person who experiences the product fit into the process? Nowhere. People using the product exist in the ethereal concept known as “the user”, and when they pass through the product they leave clues behind in the form of clicks, page visits, actions… Then we analyse these clues in an attempt to understand their behaviour so that—hopefully—we can get them to do what we want. It’s as if we treated product development as a puzzle, in which the only inputs are the analytics and the financial state of the company, and we win if our metrics improve and, above all, money goes up.

Changing customer behaviour is not as easy as it looks, specially when all you have is quantitative data and can only infer their behaviours and do trial and error by building features.

That the customer is not part of the process or constantly in our minds during the process, means that we create for them, not with them, there’s no co-creation. It’s also one of the reasons why products don’t satisfy, help, or even consider people. We assume we know better and ignore we’re biased. See if you can answer a few questions about the people using the product and the product itself:

• Who are they, what’s their story, goals, values, motivations, pain points?

• What’s the context in which they use the software, when do they use it, do they sit at their desktop or travel all the time?

• What do they want to get from the product, why do they use it, how does the product help them?

• Are they like you or different than you, would the way they see the world, their lived experiences, their skin colour, gender, culture, etc. change the way you think about designing and building the product?

• Are you making a positive impact on their lives and the world, or deceiving them into doing things or stealing their time?

When creating a product, if we only think about business outcomes without considering the people and their outcomes, not only we’ll spend more time in trial and error or fail altogether, we can veer onto unethical territory.

Regarding quantitative data, I’m not saying it’s bad, it’s actually great to have numbers and measurable things. There will always be some kind of induction and place for intuition, but we desperately need qualitative data. Without the latter, we can’t understand the “why”, the customers’ world, perspectives, motivations, meaning. The issue is that we end up relying on analytics without ever talking to anybody, or we use the analytics as an excuse to not talk to people. We refuse to be curious about the people impacted by the product, we refuse to admit that we don’t have all the answers, that we’re full of assumptions and biases.

Business and customer outcomes should go hand in hand. It seems plainly obvious, but it isn’t. As an interesting example, if you look at Opportunity Solution Trees, you’ll see that, at the top, there’s a desired outcome, connected to opportunities, which are connected to solutions, and those to assumption tests. The opportunities are unmet customers’ pain points, desires, and needs. It follows that solutions solve opportunities, that addressing opportunities gets us closer to our desired outcome, and that normally, there’s no single solution to an opportunity.

If we remove the opportunities and assumption tests from the tree, and only have solutions connected to outcomes, then we get the typical situation. There’s always an opportunity that we’re trying to address, but by thinking exclusively in terms of solutions, we’re blind.

Interesting links

• People with commonly autocorrected names call for tech firms to fix problem (Robert Booth).

• She Built a Microcomputer Empire From Her Suburban Home. The untold story of Lore Harp McGovern (Gareth Edwards).

• We Need To Rewild The Internet (Maria Farrell and Robin Berjon). ”For tech giants, the long period of open internet evolution is over. Their internet is not an ecosystem. It’s a zoo.”