Constraints, not goals

I was watching David Epstein's video on why the smartest people he knows set constraints, not goals. His argument is that a goal is the outcome you want, while a constraint is how you're going to work. When the path isn't obvious, he thinks the constraint does more for you.

The example that stuck with me was Tony Fadell, the engineer behind the iPod at Apple, who later co-founded Nest, the smart thermostat company that Google bought for 3.2 billion dollars in 2014. Before the Nest team had a product, he made them prototype the packaging, the actual box the thermostat would ship in. His logic was that the box is small and can only hold so much, so whatever goes on it, the images, the words, the promises to the customer, is what actually matters, and if it can't fit on the box it's probably not essential. He tells founders the same thing in a different form: write the press release before writing any code. The box, or the press release, becomes the container for what actually ships. Once that's fixed, the team finds the best way to get the most out of it.

We've always been min-maxing

This sounded a lot like min-maxing to me. In games your character gets a fixed number of stat points, so you minimise the stats you don't need to maximise the ones you do. Min-maxing behaviour is a natural byproduct of people being placed in a constrained environment, where resources are finite.

At first I thought min-maxing was about efficiency, since you have a fixed set of resources and you want the most out of them. But I think it's more about focus, deciding which stats get your points in the first place. And I think every era has its own min-maxing. What changes is the constraint. The same goes for product engineering, where every era has had its own constraint, and right now the constraint is changing rapidly because of AI.

Before AI, building chose for us

Before AI, the min-maxing happened at the idea stage. The constraint was placed early in the build process, which made idea validation the bottleneck, because building was extremely costly.

Don't get me wrong, there was always a lot of emphasis on idea validation. You just have to watch any Y Combinator video from the past few years. But in an age where engineers are covering more ground of the product development lifecycle, it's a lot less obvious to us. We used to be handed product requirement specs on a silver platter. The high cost of building back then made idea validation a non-negotiable step, and engineers traditionally only showed up at the building stage.

After AI, we have to choose

With AI almost anything seems possible. There's an infinite amount of things you could be working on, and nothing stops you from starting all of them, which I think is where the decision paralysis comes from. It's also why people say that in the age of AI the problem is what to build, not how to build it.

I spent about a month building a co-pilot for litigators. The first feature was an affidavit binder builder. I'd heard that putting together a binder for the judge can sometimes take three days, so it seemed like a pain worth solving. The lawyers I pitched it to liked it, they all said it was a good idea, or "oh yeah, you should totally build it". But none of them said "I need this now, and I'll pay you for it", and that month of prompting Claude kind of went down the drain.

I think anyone who built software before AI would have shot this idea down at the validation stage, because the cost of building it was high enough that you checked who actually feels the pain first.

So we have to impose that constraint on ourselves, where the min-maxing moves up the value chain. If building is cheap, we should be spending more time on the direction instead, because nothing forces it on us anymore.

Frameworks are the constraint

The way I deal with that is frameworks. I think it's very important to have frameworks for brainstorming, coming up with ideas, validating them, and working out whether a pain point is relevant and worth working on.

One I came across recently is Rob Snyder's PULL framework, which tells you whether a product has pull: the person has a Project on their to-do list, it is Unavoidable right now, they have a List of options they would consider, and those options have Limitations. I like it because it's industry agnostic and easy to remember, especially when you're talking to a client on the spot. Constraining myself to ideas that pass it is how I stop drifting into things nobody will pay for, like the co-pilot for litigators.

So what went wrong with the co-pilot for litigators? It turns out the lawyers I pitched aren't usually the ones building the binder. They were once interns or junior lawyers (which were usually the ones that handled binders), and they felt the pain back then. But today they hand it to a secretary. So the pain used to be unavoidable for them and now it isn't. Their list of options is the secretary, and the secretary's only limitation is being a bit slow, which is not enough to make anyone pay.

A diagram

flowchart LR
  A[Draft in the repo] --> B[Paste into Hashnode]
  B --> C[Published post]

A code block

def greet(name: str) -> str:
    return f"Hello, {name}"

A smaller heading

That is the whole test.