Tools Solve Problems

Tools are just meant to solve problems—not the other way around

Austin Hay
The ultimate guide to Martech

Tools Solve Problems

"Tools are just meant to solve problems. And I tell that to every person I hire. I repeat it consistently at Ramp and all of my consulting gigs. And it's not just the words, it's the spirit of it." — Austin Hay

What It Is

This is the foundational philosophy for anyone managing technology systems, especially in marketing technology (MarTech). The principle states that tools should never be selected or implemented for their own sake—they exist only to solve specific business problems.

Most people approach technology decisions backwards: they start with a tool they know or like, then try to fit problems to it. This leads to bloated tech stacks, duplicative systems, and poor return on investment. The correct approach is to deeply understand the problem first, then find the right tool (or build one) to solve it.

This philosophy extends beyond just purchasing decisions. It means you don't have to buy a tool to solve every problem—sometimes the right answer is building something custom, or using a combination of existing tools, or even deciding the problem isn't worth solving yet.

How It Works

The Anti-Pattern (Tool-First Thinking):

  1. "I know Salesforce, so let's use Salesforce"
  2. "This vendor gave a great demo, let's implement it"
  3. "Our competitor uses this tool, so we should too"
  4. "I've used this before, it'll work here"

The Correct Pattern (Problem-First Thinking):

  1. What specific problem are we trying to solve?
  2. Who experiences this problem and how painful is it?
  3. What are all the ways we could solve this problem?
  4. Which solution (build, buy, or neither) best fits our context?

How to Apply It

  1. Start with the problem statement — Before any tool discussion, articulate the problem in specific terms. "Our email campaigns have low open rates" is better than "We need a new email tool."

  2. Resist tool bias — When evaluating solutions, explicitly acknowledge if you're gravitating toward something because you know it, not because it's best. Ask: "Would I recommend this if I had never used it before?"

  3. Question tool purchases — For every proposed tool, ask: "What problem does this solve? Can we solve it another way? What happens if we don't solve it at all?"

  4. Evaluate the full solution space — Consider building, buying, combining existing tools, or waiting. The right answer might be "not yet."

  5. Think ahead — When implementing tools, consider what happens in 1-2 years. Will this solution still fit the problem at that scale?

When to Use It

  • Vendor evaluations: Before meeting with vendors, clearly document the problem you're solving
  • Stack reviews: When auditing existing tools, ask if each one is actively solving a current problem
  • New requests: When stakeholders ask for a new tool, redirect to understanding the underlying problem
  • Hiring: Use this as a core interview signal—candidates who jump to tools without understanding problems may not be good systems thinkers

Source

  • Guest: Austin Hay
  • Episode: "The ultimate guide to Martech"
  • Key Discussion: (01:05:34) Austin describes this as the framework he repeats to every person he hires
  • YouTube: Watch on YouTube

Related Frameworks

  • PPS Framework — Problem, People, System approach to technology decisions
  • Build and Buy — Complementary philosophy for technology acquisition
Back to Execution