I think the engineering and maker communities sometimes have our heads so far up our own butts inventing the future, we forget we’re supposed to be building useful tools. There’s a popular product framework called Jobs to be Done that says, in essence, that people don’t care about your feature set, they care about the thing they’re doing. And that’s exactly my point – reaching for a framework like JTBD t…
I think the engineering and maker communities sometimes have our heads so far up our own butts inventing the future, we forget we’re supposed to be building useful tools. There’s a popular product framework called Jobs to be Done that says, in essence, that people don’t care about your feature set, they care about the thing they’re doing. And that’s exactly my point – reaching for a framework like JTBD to understand user needs is like taking a child psychology class when your nephew wants to play tag. Go chase him, Einstein!
Patrick McKenzie, famously patio11 on the internet, put it simply in a brilliant post titled Don’t Call Yourself a Programmer:
Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity.
It's easy to get caught up in the process, hoping it'll help us get it right. I'm certainly guilty of this! Just earlier this year, I wasted three weeks on neat, well-structured user interviews to avoid a dead simple question: why do people want to get better at typing? (More on this soon.)The fact is, most people out there don’t give two hoots about what technology we’re using to build, or the craft of code at all, any more than you care about plumbing in public spaces. You want a bathroom on every floor, ideally with hot water and soap.
Amazing things happen when we get it right. A friend’s mom can make art because her $100/year design software lets her easily create custom paper cutouts. An online quiz shows you what city benefits you should apply for. A tool lets the team interview fairly and agree on who to hire. An app lets you split the check, or choose who goes first in a board game, or raise money from their friends, or get an alert from your doctor that your test results are okay, or find a day for everyone to hang out, or pick the drive with least traffic.
But we’re so fixated on CI/CD, password resets, validating quickly, caching, scrum, sprints, spikes, churn, KPIs, MVPs, NPS, observability, etc… that I think we forget that what we’re doing, pardon the naiveté, is trying to make peoples’ real lives a little easier.¹
All sorts of things start to make sense when you realize this. People will use broken software when it’s better than the alternative, which is usually doing it by hand. They’ll use stupid workarounds to get it to work, because it’s still worth it. But people won’t use stupid shiny crap when it doesn’t actually solve a problem.
And yes, sometimes you have to imagine the thing that doesn’t exist, and people will ask for a faster horse and all that. But while people think Steve Jobs didn’t rely on market research, they forget that he had a once-in-a-generation instinct for user needs. Most of us don’t have that, and “building a cool thing” is not a viable business strategy.
I think we’d all do well to remember that the next time we sit down to invent the future, impress investors, or get into an argument about whether Rails scales sufficiently (it does.) There’s a tired lady switching windows back and forth on her laggy computer, entering line items into a spreadsheet one at a time at 6:30PM. And if we build her an integration that pulls these items in from the company’s sales tracker, she can go home earlier and knit socks while watching her favorite show. She doesn’t care whether we use functions or objects.
¹ These all important tools and mechanisms for delivering dependable services and effectively collaborating to build new ones. But measuring our success with these mechanisms is a little like judging whether we'll stay warm tonight by looking at how many teeth per inch our saws have: it's missing the forest for the (uncut) trees.
This post was originally published here and you are reading it in the Blaggregator feed. Join the discussion on Zulip!.