Pain points & Incentives

About 2 min reading time

When working with building features in a product, I usually need some emotional attachment to them. You can’t make them good unless you believe in them and really understand the problem you’re trying to solve. This is of course Johan-stating-the-obvious, but I experienced this the other day.

Our CEO at Lookback, Jonatan, once said that he had heard from Slack that their success largely depended on that everyone in their team really understood the product. By understanding the product, I refer to the problems it tries to solve. By problems”, I mean real pain points.

It’s easy to mindlessly build features by taking cards out of the backlog — rinse and repeat. But they’ll only be so good — in order for features to achieve their fullest potential, its creators must be given the freedom to explore different routes, but also they need empathy.

Two stories:

Feeling the users

Me and Jonatan visited some Silicon Valley companies the other day, where we did some lightweight user testing and interviews centering around Lookback’s new player. The player is the creation of our awesome designer Tobias and myself. Tobias had taken part of customer meetings beforehand, so he had witnessed their pain points up front with his eyes. I was sitting around on the west coast of Sweden, always taking on the newest design mocks from Tobias. When I visited the before mentioned customers in the valley, it was the first time I’d seen a customer interacting with our product — with the player I built. It was an enlightening experience, since I felt: Wow, we really need to fix [this]” or Shit, we should totally go in [this] direction!”.

It reminded me of what’s important with our product, and that’s a thing a remote chat never can express. I felt empathy when we met our contacts at the company, when they described their workflow and mentioned things like Yeah, it would be cool to do [this] in the player” or described a bug. I instantly wanted to make it up do them somehow, since I was emotionally invested in their workflow now.

Making it your feature

When you’re solving a thing for yourself — your own sake — it’ll probably be a good creation. You know what you want, and create it: a one-to-one relationship between incentive and outcome.

A user experience researcher from Quora — who’s an avid Lookback user – requested a way to transcribe comments from a Lookback recording. That is, somehow export comments made while watching a user test. When I heard about it, I thought Yeah, that’d be cool, but …” and then I put it on a mental to do somewhere and forgot about it. When I last week experienced that very need for the feature, it was another scenario: I immediately started to think of the implementation, interface, and usage of exporting comments to Markdown or similar. I immediately created a card in Trello. See the difference? I had made it my feature since it filled my need.


This is of course common knowledge, but I nevertheless think it’s something that’s easy to forget. Building products for people involves actually interacting and understanding them and their needs, before you decide what to build.