Operating Philosophy
The operating principles behind the work: prioritization, accountability, and starting from the business instead of the backlog. 15 essays, from 25 years at the seam between the boardroom and the codebase. This is the thinking behind The Business-Down Method.
How to Say No to Feature Requests Without Killing Momentum
Focus doesn't mean rejecting bad ideas. Those reject themselves. Part 4 of my product design philosophy: kill projects that miss the bar, prototype with working software, and restart when it isn't right.
Read →Why Customer Research Fails for New Products
Customers describe their problems in the vocabulary of today's solutions. Part 3 of my product design philosophy: faster horses, seeing what others can't, and owning the parts of the stack that carry your vision.
Read →What Is Product Engineering? It Was Always One Job
We split "what to build" from "how to build it" because building was expensive. Now the split itself is the expensive part. Product engineering is what's left when you remove the seam.
Read →Product Maturity Model: Is Your Product Ready to Scale?
Feature flags, a real testing environment, an experimentation subsystem. The unglamorous infrastructure that decides whether your product can absorb more building, or just ship chaos faster.
Read →How to Work Backwards From the Customer Experience
Design is not how it looks, it's how it works. Part 2 of my product design philosophy: the best interface is no interface, and the parts users can't see should be as beautiful as the parts they can.
Read →Product Design Principles: If It Needs a Manual, It Failed
Simplicity is the ultimate sophistication. Part 1 of my product design philosophy: eliminate ruthlessly, question every assumption, and treat every "how do I…" as a bug report.
Read →How to Find the Bottleneck Before You Automate Anything
Automating around a constraint just moves it somewhere worse. Find the real bottleneck first, fix ownership, and most of the tooling you were about to buy turns out to be optional.
Read →How to Structure Customer Support: One System, Not Two Desks
Support isn't two help desks bolted to the side of the org, it's one feedback loop. Run it as a system, instrument the right KPIs, and it pays back in product and ops fixes, not faster ticket-closing.
Read →How to Align Technology With Business Strategy
The hardest part of a technology org isn't the code. It's keeping it pointed at what operations, product, and the business actually need.
Read →How to Protect Your Roadmap Without Being the Department of No
Staying responsive to the business without letting every urgent request shred the roadmap. How to say no without becoming the department of no.
Read →How to Prioritize a Roadmap: Decide What Not to Build
A technology leader's real work isn't deciding what to build. It's deciding what not to build, and holding that line against the pull of every loud request.
Read →How to Build Accountability Into an Engineering Team
Anyone can paint a future. The actual job is closing the gap between the vision and the shipped thing, then owning the result either way.
Read →How to Run Quarterly Tech Planning Without the Theater
Quarterly and annual planning is where most tech roadmaps quietly drift from what the business actually needs. Here's how I keep the plan honest, sequenced, and tied to the numbers leadership cares about.
Read →How to Build a Product Roadmap: Business Before Backlog
Most roadmaps are a pile of features looking for a reason. The fix is to start from the product and the P&L, then build the engineering to match.
Read →How to Evaluate a Codebase: Read the Thesis Before the Code
Good architecture only counts if it serves where the business is headed. So before I judge a system, I find out what the company is trying to become.
Read →