The Business Model Blindspot: Why Your Engineers Don’t Know How Your Company Makes Money
Or: We Shipped It, But We Can’t Explain Why It Matters
It was 2:47 on a Wednesday, and the air in the meeting room had that stale warmth of too many bodies and not enough ventilation. The sprint review was winding down — velocity chart projected on the wall, green bars climbing like a stock ticker in a bull market. The team lead was beaming. Forty-two points delivered. A personal best. Then someone from the business side, coffee cup halfway to his lips, asked the question that landed like a dinner plate on a tile floor: “So what moved?” Silence. The hum of the projector fan filled the room. Forty-two points of work, and not a single person could connect it to a number that mattered.
That silence is the sound of an engineering team disconnected from the business they’re building.
As Milton Friedman famously said, “The business of business is business.” It sounds redundant until you realise how many engineering teams operate as if the business of engineering is engineering. It’s not. The business of engineering is solving problems that create value. And if your engineers can’t articulate what value looks like for your company, you’ve got a workforce converting caffeine into code with no idea whether the output matters.
The Story Point Trap
I once had a team that got completely obsessed with story points. It was their goal, their north star, their reason for getting out of bed and opening Jira. Sprint after sprint, they’d celebrate hitting their target. High-fives all around. The velocity chart was a thing of beauty.
The odd thing was, they were totally failing at delivering value. And they didn’t notice. Worse, they didn’t care. They had a bad Product Owner, but they’d accepted that it was their duty to deliver the PO’s wishes, regardless of outcome. Quarter after quarter, the PO’s goals would fail, and the team was perfectly comfortable saying, “I delivered my points — it’s not my problem.”
That’s it. Right there. That’s the problem.
The disconnection from business impact wasn’t just unfortunate — it was structural. The team had been trained, implicitly, to optimise for throughput rather than outcomes. They were measured on output, so they produced output. The fact that the output didn’t move any needle that mattered was someone else’s problem.
Here’s what I wanted to tell them, and what I’ll tell you now: you are not here to convert caffeine into code. I could get an LLM to do that without paying for the coffee. You are here to deliver real business value. And if your work doesn’t, ask why. Iterate together as a team. Push back. Challenge. Because the moment you accept that your job ends at the pull request, you’ve become the most expensive typing service in the building.
How the Blindspot Forms
Let’s be fair — this isn’t entirely the engineers’ fault. The blindspot forms through a series of well-intentioned decisions that compound into organisational dysfunction.
It starts with the Product Owner. In many teams I’ve seen, the PO acts as an abstraction layer between the business and engineering. They attend the strategy meetings, digest the data, and translate it into tickets. By the time a feature reaches the engineering team, it’s been stripped of context like a fish that arrives at your plate without any trace of the ocean.
Engineers see “Add filtering to search results” on a card. What they don’t see is that 34% of users abandon the property page within three seconds when they can’t find what they’re looking for, that this abandonment costs the company roughly X million in annual revenue, and that competitive analysis shows every major player in the space already has this feature.
The economist Ha-Joon Chang once observed, “People ‘over-produce’ things that are measured and ‘under-produce’ things that are not.” When engineers are measured on velocity and ticket completion, they over-produce completed tickets. When they’re not measured on — or even exposed to — business outcomes, they under-produce solutions that actually matter.
The PO isn’t trying to hide this context. Usually, they’re just overwhelmed, and it feels faster to write a spec than to explain the entire business case behind it. But faster isn’t better. Every time a PO abstracts the team away from the data, they’re making a withdrawal from the team’s understanding of the business. Do that long enough, and you’ve got a team that can build anything but can’t explain why anything matters.
What It Looks Like When It Works
I was in a meeting with Adam and his team. They were going through ideas that engineers had submitted — a regular ideation session where anyone on the team could propose improvements, backed by a structured framework for evaluating them.
One idea was a change to the review section on the property page. Adam asked about coverage — how many users would this actually affect? Specifically, how many people scroll down far enough to see the review section?
The QA on the team, without hesitating, blurted out: “Seventeen percent.”
Short. Quick. Like she didn’t even think about it. It was just common knowledge. Every basic aspect of experimentation on the funnel — traffic splits, scroll depths, conversion rates — these engineers knew cold. They could not have replaced their PO, but, they could have a damn good conversation with him over lunch about the feasibility of a proposed experiment.
That’s what you want in a high-performing team. That’s the T in T-shaped professionals. You want people who can openly challenge and critique each other’s ideas — the engineer who questions the PO’s hypothesis because she knows the scroll data, the PO who pushes back on a technical solution because he understands the customer segment it won’t serve. This cross-pollination of business and technical knowledge doesn’t just make for better meetings. It leads to better outcomes.
The CUPE Framework: Giving Engineers a Business Language
One of our POs came up with a framework for these ideation sessions that I think is worth sharing, because it solves a fundamental problem: how do you give engineers a structured way to think about business value without requiring an MBA?
It’s called CUPE, and it answers one question: “If we had to pick between these ideas, which one creates the most value?”
Coverage — What percentage of users, traffic, or transactions does this affect? A feature touching all logged-in users might score 80–100. An optimisation for a payment method used by 15% of customers scores 15. This forces engineers to think about reach before they think about implementation.
Uplift — How much better will things get for those users? Expressed as a decimal — a 5% conversion improvement is 0.05. This is where data literacy matters. Engineers who understand their funnel can estimate this with surprising accuracy, and they often have intuitions about performance improvements that POs miss entirely.
Prior — How confident are we this will work? This one’s scored by the PO, because they typically have context on past experiments and strategic direction. A score of 1 means pure gut feeling. A 5 means strong evidence from A/B tests or proven ROI elsewhere. But here’s the key: engineers can influence this score by bringing evidence. Link to a competitor doing it. Reference a past experiment. Surface user feedback from support tickets. The more evidence you bring, the higher the confidence.
Ease — How hard is it to build? This is the engineer’s domain exclusively. A config change scores 5. A quarter-long cross-team project scores 1. Be honest here — if “just add a button” actually requires backend API changes, a database migration, and new error handling, score it low.
The formula is simple: Priority Score = Coverage × Uplift × Prior × Ease.
Take that review section idea from Adam’s team. Coverage: 17% of users see the review section, so roughly 17. Uplift: based on similar experiments, maybe a 3% improvement in engagement — 0.03. Prior: moderate evidence from competitor analysis, score 3. Ease: a couple of weeks of work, score 3. That gives you 17 × 0.03 × 3 × 3 = 4.59. Now compare that objectively against every other idea in the backlog.
The beauty of this isn’t the math — it’s the conversation the math forces. Engineers start thinking in terms of coverage and uplift. They start checking analytics. They start asking “how many users actually see this?” before they propose building it. That QA who knew the scroll depth without blinking? She didn’t learn that from a training course. She learned it because the team’s process demanded that everyone engage with the data.
Some of the biggest innovations in tech started exactly this way — engineers who understood the problem space deeply enough to see opportunities that product teams missed. Gmail was Paul Buchheit’s side project. Google News came from Krishna Bharat automating news aggregation after 9/11. React emerged because Jordan Walke needed better UI performance at Facebook. Slack started as an internal tool engineers built for their own game company. Even Post-it Notes came from a 3M engineer’s “failed” adhesive experiment. None of these were on anyone’s roadmap. They were ideas from people closest to the problem who understood both the technical possibilities and the human needs.
Closing the Gap: Practical Steps
The fix isn’t sending your engineers to business school. It’s creating an environment where business understanding is woven into the daily work.
Coach your POs to share, not shield. Many POs instinctively abstract the team from data, thinking they’re being helpful by simplifying. Push them the other way. Get POs to delegate research to engineers — have them dig into the analytics, pull the funnel data, review the experiment results. When engineers do the research themselves, they don’t just get the answer; they get the context. And sometimes they come back with ideas the PO never considered, because they’re looking at the same data through a different lens.
Make business metrics visible. Put the conversion funnel on a dashboard the team sees daily. Share experiment results — wins and losses — in team channels. When a feature ships, follow up with what actually happened to the metrics. Did it move the needle? By how much? If not, why not? This closes the feedback loop that most teams leave permanently open.
I saw what happens when you get this right early in my time at Agoda. Back then, we A/B tested everything on bookings — pure and simple. Variant A: how many people booked a hotel. Variant B: how many people booked a hotel. That was it. No complex composite metrics, no multi-layered statistical models. Just bookings. And because it was so simple, engineers understood their business impact instantly: my change added this many bookings per day to the business.
One engineer got so hooked on this feedback loop that he cracked open Chrome DevTools, reverse-engineered the API behind our experiment platform’s UI, and built what I believe was the first Slack bot at Agoda — a bot he could ask for the current results of his A/B test, right there in Slack. He told me he built it because he wanted to check his results over dinner. Not from a laptop. Not from the office. From his phone, mid-meal, because he couldn’t stop thinking about whether his change was winning.
And here’s what matters: nobody asked him to build that bot. Nobody put it on the backlog. He built it because the data was exciting. When you can see, in near-real-time, that your code is generating actual bookings for actual people, the work becomes gamified in the best possible way. That connection between “I shipped this” and “it created this much value” is addictive. It’s also exactly the connection that most teams have lost — buried under layers of abstraction, delayed reporting, and metrics so complex that nobody on the team can explain what winning looks like.
Run ideation sessions. Use something like CUPE or build your own framework, but give engineers a structured opportunity to propose ideas and evaluate them against business criteria. The act of scoring coverage and uplift changes how people think about their work. It shifts the mindset from “what can I build?” to “what should I build?”
Celebrate outcomes, not outputs. Stop high-fiving velocity charts. Start celebrating the experiment that moved conversion by half a percent. Start recognising the engineer who deleted a feature that wasn’t performing. Start talking about what worked and what didn’t in terms that connect to the business, not the backlog.
As Lewis Carroll wrote — or at least, as it’s often attributed to him — “If you don’t know where you’re going, any road will get you there.” Your engineers are on a road. The question is whether they know where it leads. If the only destination they can articulate is “the end of the sprint,” you’ve got a navigation problem.
The Bottom Line
The business model blindspot isn’t a character flaw in your engineering team. It’s an organisational design failure. We’ve built systems — Scrum, Jira, velocity tracking, PO-mediated backlogs — that actively insulate engineers from the business context that would make them more effective. Then we wonder why they optimise for story points instead of outcomes.
The teams that build the right things aren’t the ones with the best POs acting as translators. They’re the ones where engineers understand the business well enough to have informed opinions about what to build next. Where a QA can tell you the scroll depth off the top of her head. Where an engineer’s idea gets evaluated with the same rigour as a PM’s hypothesis. Where the sprint review doesn’t just show what was built, but what it meant.
You don’t need engineers who can write a business plan. You need engineers who can answer one question: “How does my work create value for the people who use this product?” If they can’t answer that, it’s not their failure. It’s yours. Fix the system, not the people.
Now, if you’ll excuse me, I need to go check the experiment results on that feature we shipped last sprint. Forty-two story points of work, and I still don’t know if it mattered. But at least now I know to ask.