Every tech company has an app. Few have a product.
The app is the artifact: screens, buttons, a signup flow, the version sitting in the store. The product is the progress someone makes in their life after deciding to trust all of that, and that progress doesn't live in any repository.
What people actually hire
I've used Jobs to be Done since 2016. The core idea fits in one line: people don't buy products, they hire progress. Someone who downloads a Bitcoin app wants to feel in control of their own money, or look sophisticated in front of the family, or sleep well knowing part of their savings sits outside the bank.
The app is just who they hired for that. If something better shows up tomorrow, they switch without guilt. Loyalty belongs to the result.
That changes where a team pays attention. The question stops being "which screen is missing" and becomes "which part of the journey still hurts".
Three times I saw it in practice
At Remessa Online, the problem was never the transfer interface. Sending money abroad was bureaucratic and scary, people didn't know if it would arrive. The screens helped, but what made the company grow was understanding that customers were hiring trust. The form was the least of it.
At Xerpay, the product was earned wage access, and the design challenge was emotional: for a lot of people, asking for an advance on their salary feels shameful. We answered with financial education content, language that didn't embarrass anyone and a flow that felt like help, not charity. None of those decisions shows up in a feature inventory.
At Bipa, I joined to evolve a website that had pages and no funnel. Before designing anything, I ran 40 JTBD interviews with real users. One of the findings: sending organic leads to the app, the decision that looked obvious and that the team took for granted, converted much worse than letting people finish signing up in the browser. That only shows up in the behavior of someone trying to solve a problem, never on the app's screens.
What app metrics don't show
You can measure whether the app works: crash rate, load time, uptime. That's operations, and it has to be flawless. None of those numbers tells you whether the product is working.
A product works when business metrics move because the experience got better: faster activation, fewer support tickets, more repeat use, more referrals. With a perfect app and a business standing still, someone mistook polish for impact.
Pretty design with no decision behind it is decoration, and decoration doesn't move metrics.
Where design comes in
If the product is the user's progress and the app is the artifact, design sits between the two. Its job is to reduce uncertainty, align the team and improve the decision that comes before the first line of code. Used that way, it's the difference between shipping the wrong feature with perfect finish and shipping the right one.
That's why the work starts before the wireframe: asking which job is at stake, crossing research with data, questioning the hypothesis the team had already taken for granted. That's how Bipa found out the obvious route to the app converted worse than the browser. A designer who only draws what was asked delivers screens. Taking part in the decision is what delivers a product.
Research that doesn't turn into a decision is an archive. Interviews, journey maps and benchmarks only matter when they change what the company does the following week, like a user quote that becomes a roadmap priority instead of a nice card on a research slide.
What changes in practice
The app still matters. What changes is the unit of value. Before opening Figma, it's worth asking which job this person is trying to get done and how they feel when they can't.
At Remessa Online, the answer was fear that the money wouldn't arrive. At Xerpay, shame about asking. Neither fit in a backlog of screens.
For you, founder: app metrics (crash rate, uptime) show the product works, not that it matters. It's worth tracking, alongside them, the number that shows whether the job got done: activation, repeat use, referrals.
For you, designer: the work starts before the wireframe, with the question of which job is at stake. Being part of that conversation is what turns delivering screens into delivering product.
For you, PM: a roadmap that only lists screen features tends to become an app inventory. Asking which job each feature solves in someone's life usually changes what makes the cut.
For you, tech: uptime and crash rate are the foundation everything else stands on. Knowing which job each flow solves helps decide where to invest in performance first.
