Pain points & Incentives

When work­ing with build­ing fea­tures in a prod­uct, I usu­ally need some emo­tional at­tach­ment to them. You can’t make them good un­less you be­lieve in them and re­ally un­der­stand the prob­lem you’re try­ing to solve. This is of course Johan-stating-the-obvious, but I ex­pe­ri­enced this the other day.

Our CEO at Lookback, Jonatan, once said that he had heard from Slack that their suc­cess largely de­pended on that every­one in their team re­ally un­der­stood the prod­uct. By un­der­stand­ing the prod­uct, I re­fer to the prob­lems it tries to solve. By problems”, I mean real pain points.

It’s easy to mind­lessly build fea­tures by tak­ing cards out of the back­log — rinse and re­peat. But they’ll only be so good — in or­der for fea­tures to achieve their fullest po­ten­tial, its cre­ators must be given the free­dom to ex­plore dif­fer­ent routes, but also they need em­pa­thy.

Two sto­ries:

Feeling the users

Me and Jonatan vis­ited some Silicon Valley com­pa­nies the other day, where we did some light­weight user test­ing and in­ter­views cen­ter­ing around Lookback’s new player. The player is the cre­ation of our awe­some de­signer Tobias and my­self. Tobias had taken part of cus­tomer meet­ings be­fore­hand, so he had wit­nessed their pain points up front with his eyes. I was sit­ting around on the west coast of Sweden, al­ways tak­ing on the newest de­sign mocks from Tobias. When I vis­ited the be­fore men­tioned cus­tomers in the val­ley, it was the first time I’d seen a cus­tomer in­ter­act­ing with our prod­uct — with the player I built. It was an en­light­en­ing ex­pe­ri­ence, since I felt: Wow, we re­ally need to fix [this]” or Shit, we should to­tally go in [this] di­rec­tion!”.

It re­minded me of what’s im­por­tant with our prod­uct, and that’s a thing a re­mote chat never can ex­press. I felt em­pa­thy when we met our con­tacts at the com­pany, when they de­scribed their work­flow and men­tioned things like Yeah, it would be cool to do [this] in the player” or de­scribed a bug. I in­stantly wanted to make it up do them some­how, since I was emo­tion­ally in­vested in their work­flow now.

Making it your fea­ture

When you’re solv­ing a thing for your­self — your own sake — it’ll prob­a­bly be a good cre­ation. You know what you want, and cre­ate it: a one-to-one re­la­tion­ship be­tween in­cen­tive and out­come.

A user ex­pe­ri­ence re­searcher from Quora — who’s an avid Lookback user – requested a way to tran­scribe com­ments from a Lookback record­ing. That is, some­how ex­port com­ments made while watch­ing a user test. When I heard about it, I thought Yeah, that’d be cool, but …” and then I put it on a men­tal to do some­where and for­got about it. When I last week ex­pe­ri­enced that very need for the fea­ture, it was an­other sce­nario: I im­me­di­ately started to think of the im­ple­men­ta­tion, in­ter­face, and us­age of ex­port­ing com­ments to Markdown or sim­i­lar. I im­me­di­ately cre­ated a card in Trello. See the dif­fer­ence? I had made it my fea­ture since it filled my need.

This is of course com­mon knowl­edge, but I nev­er­the­less think it’s some­thing that’s easy to for­get. Building prod­ucts for peo­ple in­volves ac­tu­ally in­ter­act­ing and un­der­stand­ing them and their needs, be­fore you de­cide what to build.