What You Won’t Do Defines You

We often define ourselves by what we strive to build, the markets we want to enter, the customers we want to serve, and the visions we want to pursue. These are of course necessary, but they are not defining. The deeper source of identity is not what an organization chooses to do. It is what it chooses not to do.

This is uncomfortable because possibility feels like power. A capable team can always imagine another feature, another market, another customer segment, another partnership, another product line. The temptation is especially strong for talented founders because talent creates options, and options create the illusion of progress. The more a team believes it can do, the more vulnerable it becomes to doing too much.

But strategy is not the accumulation of possibility. Strategy is the disciplined rejection of most possibilities.

A company does not become distinct merely by having ambition. Ambition is abundant. What makes a company distinct is the courage to refuse attractive alternatives. The refusal to venture off into yet another direction is what gives a company its shape. It tells the team what matters, tells customers what to expect, and tells the market what the company is willing to sacrifice in order to become itself.

Artist are seen as those that are free to chase their every imagination, but making a 2 hour movie work is painstakingly an act of constraint and commitment. Imagine the push back that comes from wanting to represent a seen so badly that you push the a $10M shot that lasts 10 seconds. Could you commit to it when everything inside and outside your world is saying it is falling apart? What makes art such an inspiring form of achievement is the commitment to see a singular vision though to the end for – well – what some would call “just a little piece of expression”.

Apple is known for going big on marketing and charging a lot for their products. What most don’t see is Apple is a hallmark of restraint. Apple is not simply Apple because it builds computers, phones, operating systems, or services. Anyone can have a vision for a great computer or experience. Apple is Apple because it has historically chosen control over ubiquity. Upgrades over legacy. It has preferred integrated experience over maximum openness. That choice requires saying no to many obvious opportunities: software for every device, infinite customization, broad compatibility at any cost, and the short-term revenue that comes from being everywhere. (In fact, their lack of constraint is what almost put them under early in their growth – but that is a story for others to tell. )

Those refusals are not incidental. They are central to the product. That isn’t to say their decisions are required for success, but making those decisions and sticking to their identity is.

Few would say Microsoft is not successful and they are a very different looking company. For most of its history they made an opposite choice. Its power came from not being tied primarily to its own hardware. Windows and Office became dominant because Microsoft chose scale, backwards compatibility, options via licensing and distribution across a vast ecosystem of machines it did not manufacture. That strategic refusal gave Microsoft its own identity. It was not Apple, and that was the point. Both companies are shaped more by what they refused as by what they pursued.

The same pattern appears in many industries.

A company making a fast car is not merely choosing speed. It is often giving up affordability, mass accessibility, or low-maintenance practicality. A luxury brand is not merely choosing premium materials or elevated design. It is refusing accommodate everyone’s requests – in fact – they hope they are not. A great restaurant is not merely choosing a menu. It is refusing to serve every taste, every trend, and every customer expectation. The strength of the experience comes from the boundaries around it.

Most people know it when they see it, but chaos, disorganization, and what can feel like a lack of brand identity is merely the manifestation of a lack of restraint. Picking your lane is not giving up on a grand vision, it is dedicating your time to a specific outcome; it is an example of discipline. It is the difference between a light and a laser. 

Even Costco, which appears on the surface to sell almost everything to everyone, is built on disciplined refusal. Its model depends on giving up selection of a myriad of options for the same product. It carries a limited number of SKUs, uses warehouse-like stores, bulks up on few variation of a product, and optimizes ruthlessly for efficiency and value. It will not take profits that don’t meet within these restraints.

This distinction matters because every “yes” has a cost beyond the immediate work required. Every yes changes the product. Every yes changes the company’s internal logic and dilutes identity.

Yes you can do anything, but no we can’t do everything.

How do we decide that line?

Proving ambition with breadth is how companies lose coherence. Rarely all at once. More often, they lose it through a series of individually reasonable expansions. One more feature. One more customer type. One more exception. One more “strategic” partnership. One more “why not?” One more compromise that seems harmless in isolation but slowly erodes the original center of gravity.

The problem is not that expansion is bad. Growth often requires expansion. The problem is having expansion without a theory of refusal. An investor without a thesis is throwing money around. Even if they make wins it is not a story they can sell, and without that sale there is no fund.

Without a clear understanding of what the company will not do, growth becomes drift. The company may get bigger, but it does not necessarily get stronger. It gains surface area while losing definition.

This is why the question “What are we building?” must be paired with a harder question: “What will we never build?”

What customer will we not serve?

What feature will we not add?

What revenue will we walk away from?

What behavior will we not reward?

What pressure will we not yield to, even when yielding would make the quarter easier?

What do we cut?

As the great quote says: I don’t sculpt stone into what it should look like, I chip away all the stone that isn’t. 

For founders, this discipline is especially important because early companies are fragile systems. A young company has limited time, limited attention, and limited resources. You are ALWAYS stealing from Peter to pay Paul – you can’t pay both.

With AI the lack of constraints required is the very dirt founder can now bury themselves in ten-times over. A product cannot afford to become many things at once – even if it is able to. The founder’s job is not merely to inspire motion. It is to protect the company from compounding motion it can not manage. By being weighed down by its options.

In this sense, refusal is not negativity. It is not small thinking. It is not fear. It is not the lack of vision. It is the architecture of commitment. Vision may be the destination, but focus is not blowing all your travel money on the first stop. It is not getting married on the first date.

To choose anything seriously you must give up many other things. The stronger the choice, the stronger the refusals required to preserve it. This is true for products, brands, companies, and creative lives. You do not become distinct by remaining available to every possibility. You become distinct by rejecting most of them with enough conviction that the few remaining possibilities can be pursued deeply.

The world does not suffer from a shortage of people willing to add more. It suffers from a shortage of people willing to define what must be left out. That is where real strategy begins.

Keep It Right-But-Light

A clearer standard for building well

Most builders have inherited a bad vocabulary for early product work.

We tell people to build an MVP, but the phrase has become so overused that it often clarifies less than it confuses. Some people hear “minimum” and interpret it as permission to ship something brittle, awkward, or barely usable. Others hear “viable” and inflate the work into a miniature production system, complete with abstractions, infrastructure, tests, edge-case handling, and design polish that may never matter.

To balance that out we encourage people to “just hack it together,” which pushes the pendulum into a different problem. Hacky can be useful when it means fast, practical, and unconcerned with unnecessary ceremony. But hacky too often becomes an excuse for bad work. It works in the narrowest technical sense, but some see it as license to create terrible unpleasant use, error laden, difficult to understand, and fragile the moment reality touches it.

This is the gap “right-but-light” is meant to name.

Right-but-light means building something correctly enough that it earns trust, while keeping it light enough that it remains easy to change. It is not about doing less work. It is about refusing to carry more weight than the moment requires. It isn’t minimal or maximal. It is that harmonious balance so many folks have trouble finding. We don’t hack down the scope to get away with a bad implementation, we do it so the one thing we choose to do is done well – while still not evergreen or perfect.

The “right” part matters because users do not experience your product through your intentions. They experience it through the surface area you give them. A button that is twice as large as it should be may not break the system, but it may still signal that your offering is dangerously unkempt. A workflow that technically completes the task but makes the user think too hard won’t get used – at all. A prototype that loses data, hides errors, or makes the user feel unsure doesn’t give you the real signals you are looking for. These things may be excusable in a throwaway 24-hour hack-a-thon demo, but they are not balanced for an initial product seedling. They train the builder, the user, and the team to tolerate roughness where clarity was needed.

The “light” part matters because early certainty is usually fake. At the beginning of a product, most of the important learning still has to happen. The shape of the problem will change. The user may care about a different part of the workflow than expected. The thing you thought was a feature may turn out to be a demo path. The thing you thought was temporary may become the center of the product. In that environment, heavy architecture is often a liability disguised as discipline and thoughfulness.

A right-but-light implementation avoids both forms of waste. It does not ignore usability in the name of speed, and it does not overbuild permanence into something that has not yet earned permanence.

This distinction has become more important with agents. Human teams already struggled with the nuance between fast and sloppy, or thoughtful and overbuilt. Agents amplify that ambiguity. Ask an agent to “build an MVP” and it may produce a sprawling approximation of a real application. Ask it to “make it hacky” and it may skip the very details that make the product usable. The instruction was vague, so the output becomes a coin flip between underbuilt and overbuilt.

“Keep it right-but-light” is a better constraint because it tells both the human and the agent what kind of tradeoff is being made. The work should be correct in the parts that matter. The interface should be understandable. The happy path should feel intentional. The data should not vanish. The user should not have to forgive the product in order to use it.

But the implementation should remain light. Maybe the data lives in a JSON file before it earns a database. Maybe the workflow is hardcoded before it earns configurability. Maybe the UI uses an existing design pattern rather than inventing a new system. Maybe the feature does not need role-based permissions, event streams, audit trails, background jobs, and a full settings page on day one. Maybe the right version is simply the smallest version that behaves with taste.

Right-but-light also gives teams a cleaner stopping rule. The question is not “is this complete?” because early products are almost never complete. The better question is: “Is this right enough to learn from, and light enough to change after we learn?”

That question changes the conversation. It moves the team away from false binaries. You are no longer choosing between a disposable hack and a production-grade system. You are choosing the minimum level of correctness required for meaningful use, and the minimum level of structure required for responsible iteration. Yes, that is what MVP and lean startup. It is just that I have tried for YEARS to explain that to people and it either doesn’t land or get me in to trouble with “you said to do the minimum!”

For example, a right-but-light onboarding flow may not need analytics dashboards, branching personalization, enterprise configuration, and a polished admin panel. But it probably does need clear copy, coherent visual hierarchy, a reset path for testing, and enough state handling that the user does not get trapped. A right-but-light internal tool may not need a formal database schema or complex permissions. But it probably does need predictable inputs, readable outputs, and error states that do not require the builder to stand nearby and explain what went wrong.

There are many great product folks out there building things you love, and I am sure you have used a product you loved and realized there was no delete button and wonders “WTF? Why can’t I delete?!”. If you get a req for your unaware peers in different departments they would have died on the sword to put the obviousl “delete” in on v1, but no feature is truly “simple” and without a time cost. So, that product manager says “they need to love what they create before they need to delete.” One less unit of time for one side of the product, one extra unit of time for another. No one has infinite time or infinite money. No one. 

So how do you chose? The point is not to lower standards. It is to place the standard in the right part of the work and be okay with walking away from the other.

Long-lasting applications deserve robustness, scalability, observability, automated tests, security reviews, edge-case handling, and design precision. But not every early feature has earned that full burden yet.

Premature permanence slows learning. It turns every change into a negotiation with yesterday’s assumptions.

Speed without standards is not iteration. It is motion. Wheels spinning fast in the mud.

It asks for seriousness without heaviness. It asks for speed without sloppiness. It asks for taste without vanity. It asks the builder to cut everything that is not required, while doing the remaining things with care.

That is the deeper meaning of the phrase.

Right-but-light is not another way to say MVP. It is a correction to what MVP has become. It restores the part people forgot when “agile” and “MVP” became a household term.

Can You, Did You, and Taste

Three stages separate ideas from products, and products from things people love.

The first stage is capability.

Can it be done? Can the software be written? Can the company be started? Can the product be built? Can the problem be solved?

These questions matter because capability is the foundation upon which everything else rests. Nothing can be executed, adopted, or admired until it is first plausible.

This is where most people rest comfortably.

The surprising thing about capability is that proving something can be done often provides many of the same emotional rewards as actually doing it. Once someone becomes convinced they could build the company, write the book, get in shape, learn the skill, or launch the product, the pressure largely disappears. Potential becomes a source of comfort.

The entrepreneur enjoys imagining the startup. The author enjoys discussing the book. The engineer enjoys architecting the system. The athlete enjoys knowing they could get serious whenever they decide the time is right. People tend to love their own brains and marvel at what it can achieve. Potential is attractive because it is free from accountability. It cannot fail because it does not yet exist.

Did you actually do it?

The second stage is execution. It only lives in the past tense. This is where the conversation changes. Ideas become products. Plans become companies. Discussions become outcomes. Concepts become features available for use and critique to the public domain. The world stops evaluating intentions and starts evaluating evidence.

A customer cannot buy potential. A user cannot interact with ambition. An investor cannot generate returns from possibility alone (though they push this rule as much as possible). The market, unlike our friends and colleagues, is remarkably indifferent to what could have happened. It only responds to what did happen.

People who reach this stage deserve significant credit. The distance between an idea and reality is far larger than most people appreciate. Building something that survives contact with the real world is difficult. Something complete, end-to-end. It accomplishes its intend (big or small) and no hand holding or excuses are needed for it to be used properly. Launching is difficult. Selling is difficult. Maintaining momentum is difficult.

Most people never get there. And I am being generous with “most”.

Yet many who do arrive at execution mistakenly believe they have reached the finish line. They assume that because something works, people will care. They assume that because a solution is objectively better, adoption will naturally follow. They assume that utility alone is enough. They believe a logical use case exists and therefore usage will follow. A good plan and execution is all that is needed.

History suggests otherwise.

The graveyard of technology is filled with products that worked. Many were faster than their competitors. Many were technically superior. Some were years ahead of their time. Their failure was not one of engineering. Their failure was assuming that human beings make decisions primarily through logic.

Taste.

Taste is one of the most misunderstood concepts in business because it is often reduced to aesthetics. People hear the word and think about typography, color palettes, industrial design, architecture, or fashion. Those things matter, but they are only symptoms of something deeper.

Taste is the ability to understand how another human being will experience what you have created.

It is the recognition that people do not merely consume functionality. They consume stories, emotions, identity, aspiration, status, trust, culture, and delight. A chair is not simply somewhere to sit. A restaurant is not merely a place to eat. A home is not simply shelter. A product is not just a collection of features. Even a purposefully poort taste for those that are tasteless is, in fact, a taste. The trickle down story line of decisions and focused intent lead to those that have the same test to become interested. Taste is not being fashionable, it is knowing people need clothes and certain groups of people like cheap clothes, some like expensive clothes, and some like expensive clothes that are on sale – but they know which group of tasters they want to have.

Every meaningful creation eventually becomes an experience.

This is why two products with nearly identical functionality can produce radically different outcomes. One becomes beloved while the other is forgotten. One creates a movement while the other creates a user base. One becomes part of a person’s identity while the other remains a tool.

The difference is often explained by taste.

The creators who understand taste recognize that presentation is part of the product. Storytelling is part of the product. Culture is part of the product. The emotional experience surrounding something is not separate from what is being built. It is one of the things being built.

Most people spend their lives asking whether something can be done. A much smaller group proves that it can. The rarest creators understand that neither capability nor execution guarantees significance.

The first stage asks whether something is possible.

The second proves that it is.

The third determines whether anyone cares.

Mountain West road trip 2026

Jackie and I have wanted to see Wyoming and Montana for a long time. As the saying goes, people often travel across the world while overlooking what is right in their own backyard. For us, this was finally the trip to change that.

Our goal was to see Jackson Hole, Big Sky, and Bozeman, with hopes of making it all the way to Glacier National Park. Unfortunately, Glacier did not make the cut because of time constraints.

We traveled during what they call the shoulder season. The upside was that everything felt quiet, calm, and untouched by the usual crowds of tourists. The tradeoff was that some roads, activities, and park areas were still closed for the season. It was not a major issue, but it was another reason Glacier eventually fell off the itinerary since parts of it were still inaccessible.

Thankfully, it ended up being a lighter snow season than expected. We had been warned about muddy roads, difficult trails, and constant wet conditions, but along our route, those issues were mostly nonexistent.

We decided to take the Rivian even though it meant more charging stops along the way. Honestly, it ended up being far less of a hassle than we expected. Fast chargers were usually spaced every 1.5 to 3 hours, and most charging stops only lasted around 15 minutes.

To be fair, about 80% of the time we were already stopping anyway to walk Rosie, use the restroom, or grab something to eat. In the end, charging rarely felt like an interruption.

Oddly enough, the EV changed the pace of the trip in a good way. Instead of falling into the classic “drive six hours straight and push as far as possible” mindset, we naturally slowed down a bit. Because of that, we actually enjoyed the scenery more and felt less exhausted overall. For a nature-focused road trip, it ended up feeling surprisingly relaxing, which was completely counterintuitive.

We also kept in mind that this was Rosie’s trip too. Everywhere we went, we made a point to find a local dog park, and honestly, it ended up adding just as much to our experience as the destinations themselves. Dog parks turned out to be an unexpectedly great way to meet locals. People are naturally more open and friendly when dogs are involved, so we ended up getting all kinds of recommendations and local tips we probably never would have found otherwise. The variety of parks was incredible too. One park in Montana felt like absolute dog heaven: 35 acres of fenced-in trails surrounded by stunning scenery with almost no visual obstruction anywhere around you. Rosie could run as far as she wanted while we wandered the trails ourselves without constantly worrying about where she was. It felt less like a dog park and more like a giant shared nature preserve for both people and dogs.

This was my first truly long road trip as an adult, and there was something incredibly freeing about it. Having Rosie with us made it even better. The whole trip developed this laid back rhythm of simply driving to wherever was next. We had a list of places we definitely wanted to see, but beyond that, everything stayed wonderfully flexible. Some towns pulled us in longer than expected, while others ended up being quick stops before moving on to the next stretch of road.

What surprised me most was how differently time works on a road trip like this. A “small detour” is rarely small. Once you factor in the drive out, the drive back, possible overnight stays, and the reality that you will probably discover more things nearby once you arrive, a side trip can quickly grow from a couple of hours into two full days. That was probably the hardest part of planning: estimating when we would actually return home. At some point, the trip stops feeling like a strict itinerary and starts feeling more like momentum. And honestly, that was part of what made it great.

Folks still wonder “why MCP?”. Here is a step-by-step comparison

Not much feels different. And that’s exactly why it confuses people. They expect magic.

I want a list of users. Here’s my pseudo-code way of sorting it out ways of doing it.

Traditional-coder scenario

Human: “I want user data from your system.”

Human goes to the docs
Finds the right endpoint
Sets up auth
Writes code: GET /users
Parses the response and uses it

The human is doing discovery, auth, integration, and parsing.

AI without MCP

Human Prompts: “List users from System X, using this doc [url]”
AI tries to reverse engineer endpoints and payloads
Maybe works, Maybe hallucinates
Human does not get coffee, they have to watch the AI progress and steer it.

The AI is the one reading the docs, but the developer is still doing work.

MCP scenario

Human: “List all users from in a Modal”

That’s it. Human goes to get coffee.

AI checks connected MCP servers
AI asks: “Do I have a tool for this?”
Finds a structured tool like list_users exposed by that service’s MCP server

That tool defines:

  • What it does
  • What inputs it needs
  • How auth works (handled server-side)

AI calls the tool through the MCP client
MCP server executes the call safely
Structured user data comes back
AI keeps going with real data

AI: “Modal with Users is ready for your review”

Human Browsing Web

Human says, “I want to get Users for the [service]”
Human opens Chrome and goes to https://%5Bservice%5D.com
Human click “Users” on the page.
They read list of Users on the page and spams them (or whatever else humans like to do these days.)

You don’t manually open a socket and craft packets. Your browser speaks a standard protocol and every website that follows it “just works.”

MCP is trying to be that layer, but for AI using software tools instead of humans using web pages. The key part is the contract. The AI is not inventing how to call your system. It is using a capability your system formally exposed over a shared protocol.