Build the Right Thing

And the money will follow

At the turn of the twentieth century, the United States government placed its bet on Samuel Langley, the Secretary of the Smithsonian Institution. Langley was brilliant, well-connected, and properly funded. His work on powered flight had clear expectations: demonstrate progress, hit milestones, and deliver a machine that could justify continued investment. In modern terms, Langley optimized for outputs. He needed visible artifacts, demonstrable activity, and proof that resources were being converted into something tangible.

At the same time, two bicycle mechanics from Dayton, Ohio, the Wright brothers, were running a very different kind of operation. They had no government sponsorship, no institutional prestige, and no expectation that flight was even commercially viable. What they did have was an obsession with outcomes. They weren’t asking, “Can we build a flying machine?” They were asking, “Can we control one?” Every glide, every crash, every failed experiment existed to answer that single question.

Langley’s Aerodrome was launched twice in 1903. Both times it flew briefly and then collapsed into the Potomac River. The public failures ended the program. The outputs were impressive; the outcomes were nonexistent. Nine days later, at Kitty Hawk, the Wright brothers flew successfully. More importantly, they had solved the underlying problem of controlled flight. They didn’t just produce an artifact. They produced understanding.

This distinction, outputs versus outcomes, is where most modern product organizations quietly lose their way.

In technology, we like to believe we are disciplined. We track spend. We forecast ROI. We demand business cases. We talk about accountability. All of that feels responsible, even virtuous. But when those tools are applied too early, to the wrong questions, they don’t create discipline. They create distortion.

Modern product development, such as done with the product operating model, draws a clean line. Outputs vs. outcome. Outputs are what teams produce, such as features. Outcomes are the measurable improvements in customer behavior or experience.

Experiments exist to answer the question: will this solve the customer’s problem?

Financials exist to answer a different question: will the business make money if we do this?

Both questions matter. They just don’t matter at the same time.

One of the most common failure modes I see is treating financial validation as a prerequisite for learning. Teams are asked to justify investment before they’ve had a chance to discover whether the problem is real, whether the solution is viable, or whether the customer even cares. The result is predictable. Experiments get shaped to fit spreadsheets instead of customer reality. Risk is hidden behind false precision. And bold ideas quietly die, not because they’re bad, but because they can’t survive premature accounting.

This isn’t an argument for ignoring costs or abandoning rigor. It’s an argument for sequencing. Financial discipline applied at the wrong moment doesn’t reduce risk; it increases it. It gives leadership the comforting illusion of control while starving teams of the freedom required to learn.

Experiments are not free, but they are not investments either.

That framing is subtle but critical. Investments assume known returns. Experiments exist precisely because returns are unknown. When we demand ROI from discovery work, we are asking teams to pretend certainty exists where it does not. The spreadsheet gets filled in, the narrative gets polished, and everyone involved understands, quietly, that the numbers are fiction.

Good product teams track experiments obsessively, but not for the dollars. They track the learning. They track how quickly assumptions are invalidated. They track whether customer behavior changes, whether friction is reduced, whether the experience actually improves in ways users can articulate and feel. These are outcome signals. They tell you whether you are moving closer to solving a real problem.

Financials, by contrast, are lagging indicators. They tell you what happened after adoption, after scale, after repeat behavior. They are essential for operating a business, but terrible for discovering what that business should become. When financials are allowed to dominate discovery, teams learn the wrong lesson: that safety lies in optimization rather than exploration.

This is how organizations slowly drift into a state of permanent short-termism. Roadmaps fill with “sure things.” Incremental improvements crowd out meaningful bets. Teams get very good at shipping outputs and very bad at producing outcomes that matter. From the outside, everything looks healthy. Inside, innovation quietly atrophies.

Return on investment is particularly dangerous because it feels objective. Numbers look clean. Models look rigorous. But ROI calculations embed assumptions about demand, behavior, and value that are rarely examined. They assume linearity in systems that are anything but. They assume customers behave rationally, consistently, and predictably. Anyone who has spent time actually watching users knows how fragile those assumptions are.

ROI Is a Terrible Product Manager

When ROI becomes the primary lens, it starts acting like a product manager. And it is a terrible one. It favors features over systems, local optimization over global coherence, and short-term wins over long-term leverage. It cannot see second-order effects. It cannot account for trust, habit formation, or emotional resonance. Yet we routinely allow it to veto ideas whose value can’t be neatly expressed in a cell.

Over time, this shapes culture. Teams stop asking what could be possible and start asking what can be defended. Strategy becomes backlog grooming. Discovery becomes theater. The organization confuses activity with progress and output with impact. And because the numbers look good, until they don’t, the warning signs are easy to ignore.

Steve Jobs told his CFO, Joe Graziano, as reported in the book Supporting Steve Jobs by Joe Mandato, “If we make great products, the profits will come.” This quote is easily misunderstood. It is not a rejection of financial reality. It’s a statement about order of operations. Jobs was not anti-business or anti-profit. He was anti-”premature certainty”. Apple cared deeply about money, but it understood that profits are harvested, not engineered directly. They are the byproduct of solving problems so well that customers reward you for it.

Great products create optionality. They open doors you didn’t know existed. Financials tell you how well you’re walking through doors you’ve already chosen. Confusing those roles leads to organizations that are very efficient at extracting value from yesterday’s ideas and very poor at inventing tomorrow’s.

The practical question, then, is not whether to track financials, but when to let them lead. Early in a product’s life, financials should function as guardrails, not goals. They exist to prevent recklessness, not to dictate direction. As confidence grows, as outcomes become repeatable, as customer value becomes clear, financial considerations naturally earn a larger voice. Eventually, optimization is not just appropriate, it’s necessary. The mistake is skipping straight to the end of that journey.

Leadership plays an outsized role here. Protecting outcome-driven discovery from output-driven accounting is not a process problem; it’s a leadership responsibility and a culture. It requires resisting the comfort of false precision and being willing to say, “We don’t know yet, and that’s okay, as long as we’re learning.” It requires trusting teams to pursue truth over theatrics, even when the answers are uncomfortable.

Conclusion

Langley failed not because he lacked intelligence, resources, or ambition. He failed because his system rewarded visible progress over meaningful understanding. The Wright brothers succeeded because they were allowed, and willing, to be wrong repeatedly, cheaply, and intelligently. They optimized for outcomes long before anyone could model the economics of aviation.

Modern product teams face the same choice. You can optimize for outputs, generate impressive artifacts, and produce spreadsheets that inspire confidence. Or you can optimize for outcomes, accept ambiguity, and do the slower, harder work of learning what actually matters to customers.

The future tends to belong to the latter. Not because they ignore financial reality, but because they understand that great businesses are discovered before they are optimized.