Three Problems a Day

The most useful framework I've built didn't start as a framework. It started as a pile of problems.

On My First Million, Shaan Puri described a business owner who runs his company a simple way. Every day, he and his team solve three problems. Not big strategy. Problems: a customer issue, data that isn't stored right, a missing feature that's costing deals. Three a day is more than a thousand a year. The business is basically the sum of them.

It stuck with me, and this week I found out why.

I went back through every partnership thread from the last year: Slack, email, call notes, the decisions and the deals. I was looking for the method behind them, so I could write it down properly.

What I found wasn't a method. It was problems, each one solved in the moment.

A partner more than doubled the minimum commitment they wanted, late in the deal, before we had any usage of our own to justify it. That wasn't the only problem. The terms we'd need to offer it to our users didn't line up, and in testing, it couldn't do the thing we were buying it for inside our users' workflow. We walked away and built it ourselves.

Customers asked for a type of data we couldn't legally carry the way they wanted it. The demand was real. So was the exposure.

We launched integrations users had asked for, and almost nobody used them at first, because they asked people to start somewhere new instead of where they already work.

We set up shared trial credits so people could test partners for free, then realized one heavy account could drain the whole pool in minutes and leave everyone else hitting a wall.

None of these were in a plan. Each one surfaced while we were executing. We dealt with it and moved on.

But each one also left a rule behind. Pay as you go until usage proves a partner. Legal fit is part of fit. Put the data where users already work. No shared pool without a per-user limit.

The rules keep getting sharper, too. "Pay as you go" turned out to be one version of a bigger rule. Not every partner offers it, and sometimes the data is worth committing to. What I actually want in every deal is the shape Richard Branson used to start Virgin Atlantic.

In 1984, Branson was running a record label and wanted to start an airline. He didn't buy a fleet. He leased one second-hand jumbo jet from Boeing for a year, and negotiated for Boeing to take it back, and reimburse the original cost, if things didn't work out. He called it a clear escape route if it all failed. If the airline worked, he had an airline. If it didn't, he handed back the plane.

Mohnish Pabrai uses this story to make one point, and he's told it on My First Million too: heads, I win; tails, I don't lose much.

A data partnership can be built the same way. Our engineers, designers and marketers are already on the team. The integration work costs time we're already paying for. The real downside is the contract: a large commitment signed before a single user has touched the data.

So every new deal now starts with one question: what's our version of handing the plane back? And just as important, what's theirs? A partner takes a risk on us too: their team's time to support the integration, and a customer that might never ramp. The best structures protect both sides. Month-to-month instead of annual. A few months of pay-as-you-go before the annual decision, made on what users actually did. Credits that roll over instead of expiring, so neither side is betting on a forecast. If it works, we both scale up. If it doesn't, we've each lost a few weeks, not a year's budget.

It doesn't always land that cleanly. Some partners only sell annual contracts, and sometimes the data is worth committing to anyway. The terms change deal to deal. The question doesn't.

Lined up together, those rules are the framework I now use on every new data partnership. About two dozen of them, and every one has a real story behind it.

Here's what I think is going on

Playbooks and frameworks give you the start. They're worth having. But the edge comes from the problems that only show up once you're executing, because nobody else has your exact ones. You can't plan for all of them, and you don't need to. You need to recognize them when they surface, unblock them, and keep what they taught you.

That last part is where most of the value leaks. A problem solved and forgotten gets solved again next quarter, by someone else, from scratch.

The compounding isn't in the solving. It's in the rule you keep.

And in sharpening it every time a new problem tests it.

I see the same thing in training. I don't plan every session for the year. Each one tells me what to fix next: a weak point, a lift that stalled, a week I need to back off. One bad workout doesn't matter much, because I'm in the gym every week. What compounds is the adjustments I keep making from what each session showed me.

Two honest limits. First, three a day isn't a quota. Some days one real unblock is the whole job, and counting problems is not the point. Second, not every problem that lands on you is yours. Some belong to another team, and the most useful thing you can do is route them quickly to the person who owns them, not solve them yourself.

Here's the habit worth keeping.

At the end of each day, write three lines: What surfaced? What did I unblock? What rule does it leave?

Once a month, read the rules back. Keep the ones that keep showing up, and rewrite any that a new problem has proven wrong. That's your framework. You didn't have to invent it. You just had to keep it.

Marc

P.S. What's a problem you solved once that turned into a rule you still use? Tell me about it. I read every message.