Technical
The First Principles Question I Ask Before Any Feature
Year two of consulting sharpened one question to the point where I ask it on autopilot now: what would happen if we just did not build this? Half the time the answer is nothing bad. The question saves clients money and saves me time.
Why This Question Works
Every feature request carries an implicit assumption that the feature is necessary. The question surfaces the assumption and forces someone to defend it. Most assumptions cannot survive honest defense.
The Four Possible Answers
- Nothing bad happens: delete the feature from the plan
- A specific user gets frustrated: measure how many users and how often
- Revenue is affected: quantify the impact
- Compliance or security gap: build it, move it to the top
The first two answers end the conversation without code. The third needs math. The fourth gets prioritized.
The Feature Types That Die
Features that do not survive this question share patterns:
- Features added because a competitor has them
- Features added because an executive saw a demo
- Features added because they sound good in a meeting
- Features that duplicate existing platform behavior
Each of these is a feature in search of a user. Killing them is the service, not the sin.
A Concrete Example
A client recently asked for a dashboard showing their own usage stats. Sounds useful. I asked the question. The answer: nobody would notice if the dashboard did not exist. The stats were already available in the admin interface. I saved the client two weeks of work.
The Harder Version
For bigger features, the question becomes: what is the smallest version that does not harm? Not the full version, not zero, but the minimum acceptable. Almost every feature has a much smaller version that preserves the real value and skips the decoration.
Why Most Teams Do Not Do This
- It feels negative to the requester
- The work of asking is less visible than the work of building
- Consultants are rewarded for shipping, not for killing
- The question threatens someone's pet feature
All four are real. None are good reasons to stop asking.
The Long Term Effect
Clients who work with me for a year stop bringing me shallow requests. The feedback loop trains them to pre-filter. The ones who keep bringing shallow requests are not a good fit and churn naturally. Both outcomes are good.
What I Tell Other Consultants
Ask the question out loud in every scoping conversation. The muscle builds fast. Within three months your clients will be asking it themselves.
See Rich Hickey's simple made easy talk for the underlying thinking about unnecessary complexity.
RELATED READING
The Consulting Shift I Am Making In Year Two
After a year of writing and building, my consulting practice is changing shape. Shorter engagements. Sharper outcomes.
ReadThe Frontend Shift: Shipping Less JavaScript In Year Two
A year ago I reached for Next.js for everything. This year I often reach for nothing.
ReadThe Serverless Lesson I Would Write On A Sticky Note
After a year of shipping serverless projects, one rule explains most of the wins and all of the losses.
Read