Asher's Blog

Building a product is not mainly the work of deciding what to add. It is the discipline of deciding what deserves to exist—and having the courage to leave everything else alone.

From the outside, product building can look like a visible sequence of ideas, designs, launches and announcements. People see what was released. They see the beautiful interface, the new feature and the story the company tells about it. What they do not see is the more difficult work behind the scenes: the hundreds of ideas that were discussed, the customer requests that were declined, the attractive opportunities that did not fit and the trade-offs that had to be made because time, money and engineering capacity were limited.

That is the real BTS—the behind the scenes—of a builder. Anyone can collect ideas; a good builder must develop judgement.

Decide What Not to Build

The first responsibility of a product builder is to determine, as early as possible, what not to build.

This matters because ideas multiply once a company begins interacting with customers. Customers request features. Competitors launch products. Employees see opportunities. Investors make suggestions. Technology makes something newly possible. Almost every idea can be made to sound sensible when discussed in isolation.

But products are not built in isolation. Every yes consumes engineering time, design attention, testing capacity, support resources and organisational focus that can no longer be spent elsewhere. A feature may be useful and still be the wrong thing to build now. It may even be useful and still be wrong for the company entirely.

This is why what not to build can be more important than what to build. The quality of a roadmap is partly determined by the quality of the ideas it excludes.

Paul Graham reduces the central task of a startup to a simple sentence: “Make something people want.” In his essay on mistakes that kill startups, he argues that nearly every form of startup failure eventually passes through the failure to make something users genuinely want. He also warns against building for a vague category called “users.” If you cannot identify specific people, speak with them and observe their response, you are building through assumption rather than evidence. Paul Graham develops this argument here.

So one of the filters I use is simple: are our customers actually expressing this need?

That does not mean a company should build every feature a customer requests. Customers are often excellent at describing their frustration but less reliable at designing the solution. A request for a particular button, report or workflow is evidence. The builder still has to investigate the underlying problem.

What is the customer trying to accomplish? How frequently does the problem occur? What do they do today when the feature is absent? What does that workaround cost them? Have several customers independently raised the same problem, or is one unusually vocal customer attempting to turn the company into a custom software provider? The goal is to listen deeply without surrendering product judgement.

Find the Customers Who Would Feel the Loss

Recently, I have been thinking about a company’s most important customers in a particular way: they are the people who would feel genuinely heartbroken if the business stopped operating today.

Not everyone who registers is an important customer. Not everyone who follows the brand is a customer. Even among paying customers, some may use the product because it is temporarily convenient, discounted or simply available. The most important customers have built part of their lives or businesses around the value you provide. Removing the product would create a real sense of loss.

This idea has a close parallel in Sean Ellis’s product-market-fit test. He proposed asking users how they would feel if they could no longer use the product and measuring the percentage who answer “very disappointed.” After benchmarking nearly 100 startups, Ellis observed that companies struggling to find growth were generally below 40 percent on this measure, while companies with strong traction generally exceeded it.

Rahul Vohra used the test while building Superhuman. At first, only 22 percent of surveyed users said they would be very disappointed if the product disappeared. The team identified the users who loved the product most, learnt what they valued and rebuilt the roadmap around strengthening that benefit while removing obstacles for similar users. Within three quarters, the score had risen to 58 percent. Vohra explains the complete process in First Round Review.

The precise percentage is not a law of nature, but the question is powerful because it separates mild approval from dependence. Many people may say that a product is good. Far fewer would care deeply if it disappeared.

Once you identify those people, study them carefully:

• What characteristics do they share?
• What job does the product perform for them?
• What part of the product would they miss most?
• What language do they use to describe the value?
• What prevents other customers with the same need from loving the product as much?
• How large is the market containing people like them?

Your best customers can show you both what to build and whom to build for.

Do Not Confuse Customer Listening With Customer Obedience

There is an important tension here. If customers are not expressing a problem, it is usually unwise to spend scarce resources solving it. But the fact that a customer requests something does not automatically mean it belongs on the roadmap.

Sometimes a requested feature would help only one customer while making the product more complicated for everyone else. Sometimes the real problem can be solved without adding a feature at all—through better onboarding, clearer language, improved reliability or a change to an existing workflow. Sometimes the request comes from a customer who is unlikely ever to become a strong fit for the product.

Superhuman’s experience is instructive. Vohra chose to pay the closest attention to two groups: customers who already said they would be very disappointed without the product, and customers who valued its central benefit but were still held back by specific limitations. He did not allow every piece of feedback to carry equal weight.

That is a critical product principle: all customers deserve respect, but not all customer requests deserve equal influence over the product.

The closer a customer is to the core problem you solve, the more valuable their feedback becomes. The further they are from it, the greater the risk that satisfying them will dilute the product for those who need it most.

Prioritise by Impact and Time

After deciding that a problem is real and belongs within the product’s purpose, the next question is priority.

My preferred starting point is to compare customer impact with time to deliver. These can be placed on two axes to create a simple decision matrix.

Short time to deliver

Long time to deliver

High customer impact

Build early: meaningful quick wins

Plan deliberately: strategic projects

Low customer impact

Do selectively: fillers or experiments

Usually decline or defer High-impact work that can be delivered quickly should normally move towards the front. It allows the company to improve the customer experience, learn from real usage and create momentum without consuming an entire planning cycle.

High-impact work that takes a long time should not be avoided simply because it is difficult. Some of the most important product investments—core infrastructure, compliance systems, major workflow redesigns or platform migrations—will never qualify as quick wins. They need deliberate planning, staged delivery and clear ownership.

Low-impact, long-duration work should face the hardest scrutiny. It may be technically interesting or visually impressive, but unless it produces strategic learning or enables something more important, it is usually where a team wastes the most time.

Low-impact, short-duration ideas can be deceptive. Because they are easy, teams keep accepting them. Over time, dozens of small additions make the product more complicated, increase maintenance costs and distract customers from the main value. “It will only take two days” is not, by itself, a product strategy.

Time is also not the only form of cost. A good prioritisation discussion should consider engineering effort, design complexity, security, regulatory exposure, operational burden, ongoing maintenance and the support questions the feature will create. A feature that takes one week to launch but creates years of exception handling is not genuinely a one-week project.

Vohra’s Superhuman team used a similar low-medium-high cost and impact analysis, starting with high-impact, low-cost improvements. The value of the method is not mathematical precision. It makes trade-offs visible and forces people to explain why an idea deserves scarce resources.

Ask What Advantage the Product Creates for the Business

Customer impact is essential, but a company must also ask what the thing it is building will do for the business itself.

What are we optimising for? Are we trying to improve activation, retention, revenue, gross margin, trust, speed, regulatory strength or distribution? Will this product decision make the company harder to replace? Will it lower the cost of serving each customer? Will it create proprietary data, deepen a network effect or make another important product easier to sell?

A feature can delight customers and still weaken the business if it costs more to provide than customers will ever pay, creates unlimited manual work or moves the company into an area it is not equipped to operate. Conversely, some investments that customers do not immediately notice—such as reconciliation, security, risk controls or internal automation—can create the reliability that preserves trust and makes future scale possible.

This is not an argument for extracting value from customers without serving them. Sustainable advantage should come from serving the right customer in a way that competitors find difficult to reproduce.

Hamilton Helmer describes durable competitive advantage in 7 Powers through mechanisms such as scale economies, network economies, switching costs, branding and process power. A builder does not need to force every feature into one of these categories. However, the larger roadmap should gradually make the company stronger, not merely larger.

The question should therefore be: If we build this well and customers adopt it, what becomes structurally better about our business?

If the answer is nothing—if the feature does not deepen customer value, strengthen retention, improve economics, create learning or reinforce an advantage—then the team should ask whether it deserves to exist.

Use Technology to Increase the Pace of Learning

The technology stack a team chooses can significantly affect how quickly it moves.

Builders sometimes treat technical choices as expressions of identity. They choose tools because they are fashionable, intellectually interesting or used by a famous company. But a technology stack should serve the product, the team and the stage of the business.

The right question is not, What is the most impressive technology available? It is, What allows this team to build, test, secure and maintain the right product responsibly?

Where reliable infrastructure already exists, use it. Do not build authentication, payments, messaging, analytics, hosting or internal tooling from first principles merely to prove that your engineers can. The company should reserve its deepest effort for the capabilities that create distinctive customer value or strategic advantage.

Modern cloud services, open-source frameworks, APIs, design systems, low-code tools and AI-assisted development can shorten the distance between an idea and a testable product. But acceleration without judgement simply helps a team build the wrong thing faster. Tools improve leverage; they do not choose the destination.

Technical speed must also include the ability to change safely. A stack that produces a quick first release but makes every later improvement fragile may slow the company over the full life of the product. Good builders consider reliability, security, maintainability, talent availability and cost alongside initial delivery speed.

The purpose of technology is not merely to increase output. It is to accelerate learning: release a useful version, observe customer behaviour, understand what worked and improve it.

Tell the World What You Are Building

A product does not create impact simply because it has been built. People need to understand what it does, why it matters and how it makes their lives better. This means storytelling is not an activity that begins after product development. It is part of building.

Tell the world about the problem. Show the cost of the old way. Explain the thought behind the new experience. Share customer outcomes, not only feature lists. Let people see the craft, the choices and the values behind the product.

The way you tell the story also tests whether the product is clear. If the team cannot explain the value in language a customer immediately understands, the problem may not be marketing alone. The product itself may be trying to do too many things.

Good storytelling creates a shared way of seeing. It helps customers recognise a problem they had accepted as normal. It gives employees language for why their work matters. It helps the market place the product in the right category and understand why it is different.

But the story must remain attached to the truth. Promotion cannot compensate permanently for a product that does not work. The strongest product stories are not inventions layered over weak performance; they reveal the meaning already present in a product that delivers.

The Builder’s Real Work

The visible part of building is what ships. The invisible part is the judgement that shaped it.

Behind every focused product should be a disciplined sequence of questions:

1. Who is our most important customer? Who would be genuinely distressed if this product disappeared?
2. What problem are they actually experiencing? What evidence shows that it is frequent, urgent and valuable enough to solve?
3. What should we refuse to build? Which ideas would distract us, complicate the product or pull us away from our strongest customers?
4. What creates the greatest impact in the least responsible amount of time? Which work is a quick win, which is a strategic investment and which should be declined?
5. What does this create for the business? Does it improve retention, economics, learning, trust or long-term advantage?
6. What technology will accelerate delivery and learning? What can we reuse, buy or integrate so that our effort remains concentrated on differentiated value?
7. How will we tell the story? How will the world understand the beauty, purpose and impact of what we have built?

Building correctly is not about producing the greatest number of features. It is about concentrating limited resources on the smallest set of decisions capable of creating the greatest customer value and the strongest business.

The best builders are not simply prolific; they are selective. They listen without becoming reactive; they move quickly without becoming careless. They use technology without becoming distracted by it. They care about customers without forgetting that the business must become stronger. And after building something valuable, they give the world language to understand it.

Anyone can fill a roadmap. The real work of a builder is to protect the product from everything it could become, so that it has a chance to become what it should be.

References

• Paul Graham, The 18 Mistakes That Kill Startups
• Rahul Vohra, How Superhuman Built an Engine to Find Product-Market Fit, First Round Review
• Hamilton Helmer, 7 Powers: The Foundations of Business Strategy