The Product Wasn't the Business

The Product Wasn't the Business

I thought building a useful product was the hard part. Then I learned that usefulness alone does not tell you who should pay, why they should care, or whether the company can exist around it.

Overview

In the early years, I was focused almost entirely on making the product better. We improved the experience, added capabilities, listened to feedback, and assumed that if the product became useful enough, the business around it would naturally follow. It didn't happen that way. The harder lesson was understanding that a product can solve a real problem and still fail to create a business people are willing to support.

Category:

Reflections

Published:

Updated:

Publisher:

Philip Cross

Reading

5 min

Series

Learning

Updated:

Intoduction

Intoduction

I used to believe that the relationship between a good product and a good business was almost automatic.

If you solved an important problem, people would notice. If they noticed, they would use the product. If they used it, they would eventually pay for it.

It was a simple model. It was also wrong.

The mistake was not building something people wanted. We had evidence that the product was useful. The mistake was assuming that usefulness alone explained the business.

It took time to understand that customers do not buy products simply because those products are useful. They buy outcomes. They pay when the problem matters enough, the value is clear enough, and the cost of changing their behavior is lower than the cost of continuing without the product.

That sounds obvious now. It was not obvious when we were living through it.

Useful Isn't the Same as Valuable

Our earliest instinct was to keep improving the product. Someone requested a feature, so we considered building it. Someone encountered friction, so we removed it. Someone suggested a workflow, so we tried to accommodate it.

The product became more capable. It did not necessarily become more valuable.

That distinction took me longer to understand than it should have.

Capability is easy to see from inside a company. You can point at a feature and say what it does. You can compare version three with version one and demonstrate how much more sophisticated the product has become.

Value is harder. Value exists in the customer's world.

A feature matters because of what it changes. It saves time. It removes a risk. It creates revenue. It replaces something expensive. It makes a difficult process possible. It gives someone enough confidence to make a decision they otherwise would not make.

Once I started thinking about products in those terms, some of our assumptions became uncomfortable. We had been measuring how much we were building. We needed to understand what changed because we had built it.

The Customer Doesn't See Your Roadmap

One of the most useful lessons from this period was realizing how little customers care about the internal logic of a product. We knew why features existed. We knew what problems they were designed to solve. We knew how much work went into them. The customer knew none of that.

They saw a product, compared it with whatever they were doing before, and made a judgment. Sometimes that judgment was immediate. Sometimes it was indifference.

That forced us to become much more precise about the problem we were actually solving. Instead of asking what else we could add, we started asking what outcome the customer was trying to achieve.

The conversations became different.

We learned that some people loved the product but had no urgency to buy it. Others had an urgent problem but did not understand why our product was the right solution. Some wanted exactly what we had built but could not justify changing their existing process. And occasionally someone would pay almost immediately because the problem was painful enough that the product did not need to convince them.

That was the moment the relationship between product and business became clear to me.

A product can be good. The market can still be wrong for it. The timing can be wrong. The buyer can be wrong. The price can be wrong. The cost of switching can be wrong.

None of those things necessarily mean the product itself has failed. They mean the system around the product has not yet worked.

We Stopped Adding and Started Choosing

The next change was uncomfortable because it required us to say no more often.

When you are early, every request feels important. A customer asks for something and you immediately see the potential value. Another customer asks for something different and you see another opportunity. Soon the product becomes a collection of reasonable decisions that do not necessarily form a coherent whole.

We had reached that point. The answer was not to work harder. It was to become more selective.

We started asking whether a request strengthened the core reason someone would choose the product or simply made the product more accommodating. That distinction eliminated a surprising amount of work.

Some features were useful but distracting. Others were valuable only for a very narrow customer. Some solved problems that belonged to an entirely different product.

Saying no made the product smaller. It also made the value proposition clearer.

This was one of the first times I understood that product strategy is partly the discipline of refusing to turn every possible opportunity into a responsibility. A company has limited attention. Every feature consumes some of it. Every customer segment introduces complexity. Every exception creates another rule.

The goal is not to serve every possible use case. It is to become unusually valuable for a particular one. That sounds like focus. In practice, it is mostly subtraction.

The Business Had to Earn the Product

Eventually I stopped thinking of monetization as something that happened after product development. It was part of product development.

Pricing, positioning, distribution, customer behavior, retention, and willingness to pay were not external concerns that marketing would solve later. They were evidence about whether we had understood the problem correctly.

That changed the questions I asked.

Not: "How much should we charge?" But: "What is this worth if it works?"

Not: "How do we convince more people to use it?" But: "Who has the strongest reason to use it?"

Not: "Which features should we add?" But: "What would make this indispensable to the person we are actually building for?"

Those questions produced better answers. They also exposed problems earlier.

Sometimes the answer was that the product was valuable but difficult to explain. Sometimes the problem was important but infrequent. Sometimes the customer wanted the outcome but not the workflow required to get there. And sometimes we were simply solving a problem that mattered less than we had convinced ourselves it did.

Those were difficult discoveries. They were also the discoveries that made the company more real.

Conclusion

The biggest change was not that we learned how to sell the product. We learned to stop separating the product from the business around it.

A product exists in a context. Someone has to discover it. Someone has to understand it. Someone has to change their behavior for it. Someone has to decide that the outcome is worth paying for. And the company has to deliver that outcome repeatedly without destroying itself in the process.

I still care deeply about making products better. But I no longer use product quality as a substitute for business clarity.

A product can be elegant and commercially irrelevant. It can be technically impressive and strategically confused. It can have enthusiastic users and no sustainable business.

The real work is connecting those things.

The lesson stayed with me because it changed what I thought a founder was responsible for. I wasn't there simply to build something people liked. I was responsible for understanding why it mattered, who it mattered to, and whether we could build a company around that value.

That was the point when I stopped thinking of the product as the destination. It was the beginning of thinking about the company as the system around it.

Contact

Building thoughtful software, ventures and ideas.

pp
hh
ii
ll
ii
pp
@@
pp
hh
ii
ll
ii
pp
cc
rr
oo
ss
ss
..
cc
oo
mm
Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor ·
Philip Cross

Philip Crossโ„ข

|

ยฉ 2026 Philip Cross All rights reserved.

Designed by

Built proudly in

This digital product is sold by Caden Holt. Purchases, product support and refunds are governed by our Sales & Refunds Policy, License & Intellectual Property Terms and the specific Philip Cross Product Terms.

Contact

Building thoughtful software, ventures and ideas.

pp
hh
ii
ll
ii
pp
@@
pp
hh
ii
ll
ii
pp
cc
rr
oo
ss
ss
..
cc
oo
mm
Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor · Founder · Engineer · Builder · Writer · Speaker · Advisor · Investor · Mentor ·
Philip Cross

Philip Crossโ„ข

ยฉ 2026 Philip Cross All rights reserved.

Designed by

Built proudly in

This digital product is sold by Caden Holt. Purchases, product support and refunds are governed by our Sales & Refunds Policy, License & Intellectual Property Terms and the specific Philip Cross Product Terms.

Contact

Building thoughtful software, ventures and ideas.

pp
hh
ii
ll
ii
pp
@@
pp
hh
ii
ll
ii
pp
cc
rr
oo
ss
ss
..
cc
oo
mm
Philip Cross

Philip Crossโ„ข

ยฉ 2026 Philip Cross All rights reserved.

Designed by

Built proudly in

This digital product is sold by Caden Holt. Purchases, product support and refunds are governed by our Sales & Refunds Policy, License & Intellectual Property Terms and the specific Philip Cross Product Terms.

Create a free website with Framer, the website builder loved by startups, designers and agencies.